Le 16/09/2010 23:26, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c927c0c.1080...@free.fr you wrote:
I did not write 'the goal of using fPIC in u-boot', I wrote 'the goal of
fPIC', and as such, I think I read it right. I do agree though (and I
think I made it clear further in my
Whether the latest u-boot supports BCM8727 10GbE SFI-to-XAUI PHY.
--
View this message in context:
http://old.nabble.com/BCM-8727-tp29735532p29735532.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
Hello,
On Thursday 16 September 2010, 19:44:20 you wrote:
This patch fixes lib_arm/board.c build errors.
The combination of weak alias and inline attributes
lead to a compile time error when using gcc version 4.4 and above.
Signed-off-by: Stanislav O. Bezzubtsev
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
Liu Dave-R63238 r63238 at 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)
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
-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 Thu, 16
-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 Thursday,
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 designed
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
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher h...@denx.de
---
arch/m68k/lib/board.c|8
arch/mips/lib/board.c|8
arch/powerpc/lib/board.c | 10 --
include/common.h |9 +
4
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
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
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
the
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher h...@denx.de
---
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
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 h...@denx.de
---
arch/arm/cpu/sa1100/start.S| 162
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 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 h...@denx.de
---
arch/arm/cpu/arm920t/start.S| 225 ++-
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 h...@denx.de
---
arch/arm/cpu/lh7a40x/start.S| 187 ++-
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 h...@denx.de
---
arch/arm/cpu/arm1176/start.S| 286 +++
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 h...@denx.de
---
arch/arm/cpu/s3c44b0/start.S| 174 +++
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 h...@denx.de
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
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, so
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher h...@denx.de
---
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
---
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 h...@denx.de
---
arch/arm/cpu/arm720t/start.S| 170 +++
Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: Heiko Schocher h...@denx.de
---
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
+++
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 h...@denx.de
---
arch/arm/cpu/pxa/start.S| 168 +++
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 h...@denx.de
---
arch/arm/cpu/arm1136/start.S| 201
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 h...@denx.de
---
arch/arm/cpu/arm946es/start.S| 168 +-
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 h...@denx.de
---
arch/arm/cpu/arm_intcm/start.S| 166 +
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 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 h...@denx.de
---
arch/arm/cpu/ixp/start.S| 280 +++
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 h...@denx.de
---
arch/arm/cpu/arm925t/start.S| 204 ++-
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 h...@denx.de
---
!! 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
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 not
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
Le 17/09/2010 13:05, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c9307c4.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
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);
+#if
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
the
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
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
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.
- You must make
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 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 no
Le 17/09/2010 16:52, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c9365e7.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
Le 17/09/2010 16:54, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c936823.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
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
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
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
On Fri, 17 Sep 2010 16:32:04 +0200
Wolfgang Denk w...@denx.de 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
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 the
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 iterate
On Thu, 16 Sep 2010 19:51:33 -0700
Tabi Timur-B04825 b04...@freescale.com 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();
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 take a
const).
CONFIG_ENV_SIZE only needs page alignment, not block
Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
Signed-off-by: Scott Wood scottw...@freescale.com
---
README | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/README b/README
index
On Fri, Sep 17, 2010 at 3:43 PM, Scott Wood scottw...@freescale.com wrote:
CONFIG_ENV_SIZE only needs page alignment, not block
Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
Signed-off-by: Scott Wood scottw...@freescale.com
+ - CONFIG_ENV_OFFSET_OOB (optional):
+
+
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 important
On Fri, 17 Sep 2010 22:47:04 +0200
Wolfgang Denk w...@denx.de 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 does not need block alignment.
Document CONFIG_ENV_RANGE and CONFIG_ENV_OFFSET_OOB.
Signed-off-by: Scott Wood scottw...@freescale.com
---
CONFIG_ENV_SIZE doesn't even need page alignment.
README | 32 +++-
1 files changed, 23 insertions(+), 9
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 problem with
On Fri, Sep 17, 2010 at 5:10 AM, Heiko Schocher h...@denx.de 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
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 ya...@emcraft.com
---
arch/powerpc/cpu/mpc83xx/pcie.c | 38 +-
1 files changed, 25 insertions(+), 13 deletions(-)
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 ya...@emcraft.com
---
arch/powerpc/cpu/mpc83xx/cpu_init.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git
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
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
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 ya...@emcraft.com
---
include/mpc83xx.h | 48
1 files changed, 48 insertions(+), 0
Dear John,
In message aanlktims+909jaf1ho41+wazbh1qmondg8aohpm04...@mail.gmail.com 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
Le 17/09/2010 21:04, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
Reminder: here we're talking about fitting a64 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 the rest
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:22, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c939add.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
Le 18/09/2010 00:42, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4c93e978.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
0x40007c20
72 matches
Mail list logo
