Le 18/09/2010 00:42, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c93e978.9010...@free.fr> you wrote:
>>
>>> u-boot.map for this board shows:
>>>
>>> ...
>>>arch/powerpc/lib/cache.o(.text)
>>>.text 0x40007c20 0x64 arch/powerpc/lib/cache.o
>>>
Le 17/09/2010 21:22, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c939add.5090...@free.fr> you wrote:
>>
> init_fnc_t *init_sequence[] = {
init_sequence is a constant, not an initialized variable, and thus
should have the 'const' qualifier.
>>>
>>> Actually
Dear Albert ARIBAUD,
In message <4c93e978.9010...@free.fr> you wrote:
>
> > u-boot.map for this board shows:
> >
> > ...
> > arch/powerpc/lib/cache.o(.text)
> > .text 0x40007c20 0x64 arch/powerpc/lib/cache.o
> > 0x40007c20flush_cache
> >
Le 17/09/2010 21:04, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>> Reminder: here we're talking about fitting a>64 KB u-boot in flash,
>> with _start at the reset vector (0x on orion5x), without wasting
>> the space above the reset vector (64 KB on orion5x) and with minimal
>> waste in
Dear John,
In message you
wrote:
>
> I noticed that when I wrote to ram in the range where u-boot runs
> before being relocated sometimes the board hangs. I then narrowed it
Stupid question: how did you write to that RAM location? And why?
The RAM is not supposed to be accessable before relo
This patch adds defines to set supported fields in System I/O
Configuration Registers High and Low on Freescale MPC8308 CPU.
Signed-off-by: Ilya Yanok
---
include/mpc83xx.h | 48
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/in
This patch provides support for MPC8308 P1M board with the following
set of features:
Dual UART is supported
NOR flash is supported
Both TSEC Ethernet controllers are supported
PCI Express initialization is supported
Both I2C controllers are supported
Signed-off-by: Ilya Yanok
---
MAINTAINE
This patch cleans up the Freescale MPC8308RDB Development board support.
Things fixed:
- Removed unused PCIE2 definitions from configuration
- SICR{L,H} defines used for System I/O Configuration Registers values
instead of hardcoding
- CONFIG_SYS_SCCR_PCIEXP1CM used to enable PCIE clock inste
This patch adds support for setting PCIE clocks in cpu_init.c by
providing CONFIG_SYS_SCCR_PCIEXP{1,2} in configuration.
Signed-off-by: Ilya Yanok
---
arch/powerpc/cpu/mpc83xx/cpu_init.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx
MPC8308 has only one PCIE host controller so we want it to compile
without CONFIG_SYS_PCIE2_CFG_{BASE,SIZE} defined.
Signed-off-by: Ilya Yanok
---
arch/powerpc/cpu/mpc83xx/pcie.c | 38 +-
1 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/
On Fri, Sep 17, 2010 at 5:10 AM, Heiko Schocher wrote:
> Change the implementation for ARM V7 to relocate the code to an
> arbitrary address in RAM.
>
> Adapt the Beagle board (Cortex A8) to test the changes.
>
Heiko,
I'm running -next on a Beagle board (first version of arm reloc not v2).
I no
Hi Kim,
On 17.09.2010 03:54, Kim Phillips wrote:
>> +#if defined(CONFIG_SYS_PCIE2_CFG_BASE)&& defined(CONFIG_SYS_PCIE2_SIZE)
>> #define PCIE_MAX_BUSES 2
>> +#else
>> +#define PCIE_MAX_BUSES 1
>> +#endif
>>
> Technically this should be an indirect function of MPC8308, but what's
> the prob
CONFIG_ENV_SIZE does not need block alignment.
Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
Signed-off-by: Scott Wood
---
CONFIG_ENV_SIZE doesn't even need page alignment.
README | 32 +++-
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/RE
On Fri, 17 Sep 2010 22:47:04 +0200
Wolfgang Denk wrote:
> For example, on NOR flash we might see an erase block size of 256 KiB
> (resulting in a "#define CONFIG_ENV_SECT_SIZE (256 << 10)" or
> similar). But normally we don't need so much space for the
> environment, so we set CONFIG_ENV_SIZE to
Dear Scott Wood,
In message <20100917194327.ga17...@udp111988uds.am.freescale.net> you wrote:
> CONFIG_ENV_SIZE only needs page alignment, not block
>
> Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
I appreciate your efforts, but I think we should also fix the code.
For me it seems impor
On Fri, Sep 17, 2010 at 3:43 PM, Scott Wood wrote:
> CONFIG_ENV_SIZE only needs page alignment, not block
>
> Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
>
> Signed-off-by: Scott Wood
> + - CONFIG_ENV_OFFSET_OOB (optional):
> +
> + Enables support for dynamically retrievin
CONFIG_ENV_SIZE only needs page alignment, not block
Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
Signed-off-by: Scott Wood
---
README | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/README b/README
index aa11c37..4d95a8b 100644
--- a/READM
Dear Albert ARIBAUD,
In message <4c939add.5090...@free.fr> you wrote:
>
> >>>init_fnc_t *init_sequence[] = {
> >>
> >> init_sequence is a constant, not an initialized variable, and thus
> >> should have the 'const' qualifier.
> >
> > Actually it _is_ an initialized variable (which still may ta
On Thu, 16 Sep 2010 19:51:33 -0700
Tabi Timur-B04825 wrote:
> Jaggi Manish-B10520 wrote:
> > Most of the read/write functions do this way
> > 0:+ int sw = set_mux_to_lbc();
> > 1:+
> > 2:+ ret = __raw_readl(addr);
> > 3:+ if (sw)
> > 4:+ set_mux_to_diu();
> >
> > c
Dear Albert ARIBAUD,
In message <4c9399a7.5020...@free.fr> you wrote:
>
> Depends on the processor I guess; but still, my point is that "start at
> any location" does not require that you detect whether you are fresh out
> of reset or not.
OK. I've repeated that often enough now, I will not ite
On Fri, Sep 10, 2010 at 03:42:32PM -0700, Ira W. Snyder wrote:
> Newer Linux kernels can overrun the initial memory window used for
> booting with their BSS area. When this happens, they overwrite the FDT
> and silently fail to boot.
>
> On e300 CPUs, the Linux kernel uses an initial BAT covering
On Fri, 17 Sep 2010 16:32:04 +0200
Wolfgang Denk wrote:
> Dear Reda MIMOUNE,
>
> In message <1918f436c366b34bb245dd28389e039453adfaa...@mars.easii.fr> you
> wrote:
> >
> > reading the README file, here is what I read:
> >
> > Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned
Hi Damien,
Thanks for the info. I will check it out.
I'm also not sure if the SAM9 USB device support is available.
I actually did some work a while ago to make USB work for the SAM9 but had to
leave it in non-working condition at the time. If SAM9 USB is not supported
yet, I guess I best fix m
Hi Brent,
On Friday 17 September 2010 16:40:13 Brent Bartson wrote:
> Does u-boot support "Numonyx StrataFlash (P30)" NOR flash devices? I
> understand it supports NOR flash but does that imply **all** NOR flash?
Yes, U-Boot supports the StrataFlash chips via the common CFI flash driver.
Many bo
I've configured my device (a Seagate DockStar) with just two NAND
flash partitions -- one for u-boot and one for the Linux rootfs.
This has some nice advantages: it maximizes the available flash space,
and allows the Linux distribution's own tools to install new kernel
and initramfs files without
Le 17/09/2010 16:54, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c936823.1060...@free.fr> you wrote:
>>
>>>init_fnc_t *init_sequence[] = {
>>
>> init_sequence is a constant, not an initialized variable, and thus
>> should have the 'const' qualifier.
>
> Actually it _is_ an i
Le 17/09/2010 16:52, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c9365e7.50...@free.fr> you wrote:
>>
>>> - You need a way to detect if you are running on a virgin CPU fresh
>>> out of reset or on a pre-initialized system.
>>> - You need to isolate parts in the initializatio
Dear Reda MIMOUNE,
In message <1918f436c366b34bb245dd28389e039453ade8b...@mars.easii.fr> you wrote:
>
> No Davinci did not mess it up. I read 0x4000 (16KB) instead of 0x4
> (256KB).
Actually I do think Davinci is messed up.
Many boards define CONFIG_ENV_SIZE as 256 or 128 KiB, which makes n
Dear Albert ARIBAUD,
In message <4c936823.1060...@free.fr> you wrote:
>
> > init_fnc_t *init_sequence[] = {
>
> init_sequence is a constant, not an initialized variable, and thus
> should have the 'const' qualifier.
Actually it _is_ an initialized variable (which still may take a
const).
Best
Dear Albert ARIBAUD,
In message <4c9365e7.50...@free.fr> you wrote:
>
> > - You need a way to detect if you are running on a virgin CPU fresh
> >out of reset or on a pre-initialized system.
> > - You need to isolate parts in the initialization sequence that must
> >not be repeated.
> > - Y
Thank you
No Davinci did not mess it up. I read 0x4000 (16KB) instead of 0x4 (256KB).
So if I understand you I can swap the values in my first email:
CONFIG_ENV_SECT_SIZE= 128KB
CFG_ENV_SIZE= 16KB
Thanks for help.
Cordialement,
Reda MIMOUNE
Reda MIMOUNE
Ingénieur Software S
Hello,
Does u-boot support "Numonyx StrataFlash (P30)" NOR flash devices? I understand
it supports NOR flash but does that imply **all** NOR flash?
Regards,
Brent Bartson
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5458 (20100917) _
Dear Reda MIMOUNE,
In message <1918f436c366b34bb245dd28389e039453adfaa...@mars.easii.fr> you wrote:
>
> reading the README file, here is what I read:
>
> Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned
> to a block boundary, and CFG_ENV_SIZE must be a multiple of
>
Hi Heiko,
Le 17/09/2010 13:10, Heiko Schocher a écrit :
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 54519b0..88c6427 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -234,6 +246,7 @@ typedef int (init_fnc_t) (void);
>
> int print_cpuinfo (void);
>
>
Le 17/09/2010 13:05, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c9307c4.40...@free.fr> you wrote:
>>
>> Things do change indeed, hence my attempt à 1) making sure I detect the
>> change, 2) design things so that they are as resilient to change as
>> possible. One example of suc
Hello Wolfgang
Thanks for answering.
Good to see that mkimage would be ok with both versions.
What do I fear ? I traditionnaly saw many problems of version coherence
between binaries and tools generating them.
Now I prefer to ask.
Concerning the #define, I made a mistake when recopying.
this s
Dear Reda MIMOUNE,
In message <1918f436c366b34bb245dd28389e039453adfaa...@mars.easii.fr> you wrote:
>
> Have a question about it, if I upgrade to a new version of uBoot. Is it
> guaranteed that mkimage
> will wrap the uboot binary the same way. Is mkimage the same version ?
Of course mkimage is
!! This breaks support for all arm boards !!
To compile in old style, you must define
CONFIG_SYS_ARM_WITHOUT_RELOC or you can compile
with "CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board"
!! This define will be removed soon, so convert your
board to use relocation support
Portions of this work w
Change the implementation for ARM V7 to relocate the code to an
arbitrary address in RAM.
Adapt the Beagle board (Cortex A8) to test the changes.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/armv7/mx51/u-boot.lds | 14
Change the implementation for arm926 to relocate the code to
an arbitrary address in RAM.
Adapt the TX25 (i.MX25), magnesium board to test the changes.
On the tx25 board TEXT_BASE is set to the final relocation
address to prevent one more copying of u-boot code
when relocating. More info see:
doc
Change the implementation for arm925 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm925t/start.S| 204 ++-
arch/arm/cpu/arm92
Change the implementation for ixp to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/ixp/start.S| 280 +++
arch/arm/cpu/ixp/u-bo
This patch series add full relocation and cache support for arm
based boards. I test this for arm1136, arm_cortexa8 and arm926ejs
based boards.
Relocation support:
!! This change is not compatible to old code !!
If you want to compile in old style, you can set
CONFIG_SYS_ARM_WITHOUT_RELOC
but
Change the implementation for arm_intcm to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm_intcm/start.S| 166 +
arch/arm/cpu/ar
Change the implementation for arm946 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm946es/start.S| 168 +-
arch/arm/cpu/arm94
Change the implementation for ARM11 to relocate the code to an
arbitrary address in RAM.
Tested on the qong board.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm1136/start.S| 201 +
Change the implementation for pxa to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/pxa/start.S| 168 +++
arch/arm/cpu/pxa/u-bo
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
disk/part.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 3ba88c7..8bcf2f8 100644
--- a/disk/part.c
+++ b/disk/part.c
@@
Change the implementation for arm720t to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm720t/start.S| 170 +++
arch/arm/cpu/arm7
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
common/cmd_i2c.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 1283c82..a7b65ed 100644
--- a/common/cmd_i2c.c
+++ b/co
This has been tested on at91sam9263 and STN8815.
Again, I didn't check if it has bad effects
on non-arm926 cores.
Initially I had a "done" bit to only set up page tables
at the beginning. However, since the aligmnent requirement
was for the whole object file, this extra integer tool 16kB
in BSS, s
bi_env is nowhere used, so delete it!
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
similar patch posted from Dirk Behme Tue Jul 27 18:36:09 CEST 2010
http://lists.denx.de/pipermail/u-boot/2010-July/074542.html
so this patch maybe obsole
Change the implementation for s3c44b0 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/s3c44b0/start.S| 174 +++
arch/arm/cpu/s3c4
Change the implementation for arm1176 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm1176/start.S| 286 +++
arch/arm/cpu/arm1
Change the implementation for lh7a40x to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/lh7a40x/start.S| 187 ++-
arch/arm/cpu/lh7a
Change the implementation for arm920 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/arm920t/start.S| 225 ++-
arch/arm/cpu/arm92
fixup_cmdtable() did all work for fixing up the cmdtable,
if CONFIG_RELOC_FIXUP_WORKS is not defined.
CONFIG_RELOC_FIXUP_WORKS is missing for i386! I talked
with Graeme Russ, and he will fix this soon.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko
Change the implementation for sa1100 to relocate the code to
an arbitrary address in RAM.
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/arm/cpu/sa1100/start.S| 162
arch/arm/cpu/sa110
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
drivers/i2c/omap24xx_i2c.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index a7c4e69..3febd1f 100644
With -fPIC enabled, this variable needs an entry in the GOT, which
causes the image size to exceed 2 KiB which is the maximum allowed for
some systems. Making it a "static const" avoids the GOT entry and thus
reduces the image size to < 2 KiB.
Portions of this work were supported by funding from
t
Add data cache support for ARM V7 systems. Used cache flush
functions from linux:arch/arm/mm/cache-v7.S developed from
Catalin Marinas.
Enable "cache" command on Beagle board and test performance.
Test 1: Loading 127 MB of data from NAND flash into RAM:
Instr. Cacheoff on
Add data cache support for arm1136 systems.
Enable "cache" command on Qong board and test performance.
Test 1: Loading 127 MB of data from NAND flash into RAM:
Instr. Cacheoff on on
Data Cacheoff off on
--
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher
---
arch/m68k/lib/board.c|8
arch/mips/lib/board.c|8
arch/powerpc/lib/board.c | 10 --
include/common.h |9 +
4 files changed, 9
Enable "cache" command on tx25 and magnesium board and test performance.
Test 1: Loading 127 MB of data from NAND flash into RAM:
Instr. Cacheoff on on
Data Cacheoff off on
--
magnesium
Dear Albert ARIBAUD,
In message <4c9307c4.40...@free.fr> you wrote:
>
> Things do change indeed, hence my attempt à 1) making sure I detect the
> change, 2) design things so that they are as resilient to change as
> possible. One example of such a resilience is making sure the u-boot
> code des
> -Original Message-
> From: Mike Frysinger [mailto:vap...@gentoo.org]
> Sent: Friday, September 17, 2010 12:02 AM
> To: u-boot@lists.denx.de
> Cc: Premi, Sanjeev; Kyungmin Park; Stefan Roese; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-boot source
>
> On Thurs
> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Thursday, September 16, 2010 11:30 PM
> To: Premi, Sanjeev
> Cc: Kyungmin Park; Stefan Roese; u-boot@lists.denx.de; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-boot source
>
> On T
> It look same as other PQ2/3 which using BR0/OR0 to set boot vecror
base address.
>
> just confirm, do you know CPU will read RCW data before it jump to
0x_FFFC?
Yes. CPU reset module must fetch RCW and configure CPU itself.
then reset to 0x_FFFC, it is also same as PQ3.
Thanks,
Dave
Liu Dave-R63238 freescale.com> writes:
>
> > For that reset address question, I think because p4080ds's FPGA can do
> this address
> > decode and map 0xefff to 0x setting by SW7, is it right?
>
> No. FPGA doesn't matter with it.
>
> The e500mc core boot start address(0x_FFFC) w
Hi Scott;
Again thank you for the answer.
>My expense request for a time machine was denied, so we can't go back
>and put new features in old versions. :-)
>Please upgrade, or backport the features yourself.
Have a question about it, if I upgrade to a new version of uBoot. Is it
guaranteed that
70 matches
Mail list logo
