We appear to have different refclk's on the different corenet DS boards
so move the define out of the common header.
Signed-off-by: Kumar Gala
---
include/configs/P4080DS.h|2 ++
include/configs/corenet_ds.h |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include
CONFIG_SYS_TEXT_BASE setting is common across the 'corenet_ds' board
family so move it out of P4080DS.h and into corenet_ds.h
Signed-off-by: Kumar Gala
---
include/configs/P4080DS.h|4
include/configs/corenet_ds.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff -
Signed-off-by: Kumar Gala
---
include/configs/corenet_ds.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 7ad9c69..454a30a 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -4
Dear Prabhakar,
In message <1289451431-22179-1-git-send-email-prabha...@freescale.com> you
wrote:
> nic and hw structures are allocated via malloc i.e. return memory
> is not zero initialized. Because of this few structure member like
> "function pointers" are initialized with garbage values.
>
Le 10/11/2010 15:20, Eric Cooper a écrit :
> On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
>> Can you make the ELF images available? I'll do the readlf/objdump
>> analysis and feed back on what I find.
>
> I've uploaded them here:
> http://www.cs.cmu.edu/~ecc/u-boot.{good,bad
Dear Xiangfu Liu,
In message <1289446657-12499-4-git-send-email-xian...@openmobilefree.net> you
wrote:
> From: Xiangfu Liu
>
> Signed-off-by: Xiangfu Liu
> ---
> nand_spl/board/xburst/nanonote/Makefile | 96 +++
> nand_spl/board/xburst/nanonote/u-boot.lds | 63 +
> nand_spl/nand
Dear Xiangfu Liu,
In message <1289446657-12499-2-git-send-email-xian...@openmobilefree.net> you
wrote:
> From: Xiangfu Liu
Please use a more descriptive subject.
Explain what jz4740 is; also explain what xburst is. Whos is be=hind
it, what it's used for, etc.
> diff --git a/arch/mips/cpu/xbu
The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-marvell
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx.git master
Haiying Wang (3):
powerpc/85xx: Fix lds
On Nov 10, 2010, at 8:09 AM, Kumar Gala wrote:
> When P2020DS DDR2 was merged it was merged incorrectly and propogated to
> boards.cfg. Fix this by moving DDR2 config to be associated with
> P2020DS and not P1_P2_RDB.
>
> Signed-off-by: Kumar Gala
> ---
> boards.cfg |2 +-
> 1 files changed
On Nov 10, 2010, at 4:10 PM, Kumar Gala wrote:
> Signed-off-by: Kumar Gala
> ---
> * fix typo in defind -> define
>
> include/configs/MPC8569MDS.h |1 +
> include/configs/MPC8572DS.h |1 +
> include/configs/P1022DS.h|1 +
> 3 files changed, 3 insertions(+), 0 deletions(-)
applied
On Nov 10, 2010, at 2:37 PM,
wrote:
> From: Haiying Wang
>
> Signed-off-by: Haiying Wang
> ---
> v3 change: %s/CONFIG_SYS_TEXT_BASE/CONFIG_SYS_MONITOR_BASE/g
>
> arch/powerpc/cpu/mpc85xx/start.S | 18 +-
> include/configs/MPC8536DS.h |8 +++
On Nov 10, 2010, at 1:32 PM,
wrote:
> From: Haiying Wang
>
> Fix u-boot-nand.lds and u-boot-nand_spl.lds according to:
>
> Author: Peter Tyser
> Date: Wed Sep 29 14:05:56 2010 -0500
> commit fbe53f59bd40b3b1ab66dc98859e26589d64d1b7
>85xx: Use gc-sections to reduce image size
>
> Sig
Hi,
Now I'm trying to use the NEON instruction at u-boot. but it's failed
and got the data abort.
Are there any way to use the NEON instruction at u-boot?
The main purpose is to use the neon memcpy as below.
bge 1f
// copies 4 bytes, destination 32-bits aligned
vl
nic and hw structures are allocated via malloc i.e. return memory
is not zero initialized. Because of this few structure member like
"function pointers" are initialized with garbage values.
It may cause problem. for eg. during eth_initialize, dev->write_hwaddr
is used.
Signed-off-by: Prabhakar
-
From: Xiangfu Liu
Signed-off-by: Xiangfu Liu
---
board/xburst/nanonote/Makefile| 45
board/xburst/nanonote/config.mk | 31 ++
board/xburst/nanonote/nanonote.c | 124 ++
board/xburst/nanonote/u-boot-nand.lds | 63 +++
include/con
From: Xiangfu Liu
Signed-off-by: Xiangfu Liu
---
drivers/mtd/nand/jz4740_nand.c | 250
1 files changed, 250 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/jz4740_nand.c
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/
From: Xiangfu Liu
Signed-off-by: Xiangfu Liu
---
nand_spl/board/xburst/nanonote/Makefile | 96 +++
nand_spl/board/xburst/nanonote/u-boot.lds | 63 +
nand_spl/nand_boot_jz4740.c | 395 +
3 files changed, 554 insertions(+), 0 deletions(-)
From: Xiangfu Liu
Signed-off-by: Xiangfu Liu
---
arch/mips/cpu/xburst/Makefile | 50 +++
arch/mips/cpu/xburst/config.mk| 33 ++
arch/mips/cpu/xburst/cpu.c| 158 +++
arch/mips/cpu/xburst/interrupts.c | 33 ++
arch/mips/cpu/xburst/jz4740.c | 257 +++
arch/m
Hi Shinya
very thanks for your feed pack, and I am really sorry for so later
reply.
the "[PATCH 1/5] those files are jz4740 base files" is patch v2 of
"[PATCH] [MIPS] those files are jz4740 base files"
I have try to fix all your comments. only one thing, I am not very
understand the "fla
On Wednesday, November 10, 2010 17:29:52 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > so do what i said -- set the HOSTCC to the host you want the tools to run
> > on. this will work for *all* tools instead of arbitrarily picking some
> > to use HOSTCC while picking others to use CROSS.
>
> Wh
On Wednesday, November 10, 2010 17:25:31 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > IIRC, HOSTCC refers to the C compiler on the and for the build host,
> > > i. e. when running on a x86 system it will create x86 code. This is
> > > obviously wrong when we try to build fw_printenv for, say
Dear Mike Frysinger,
In message <201011101711.17574.vap...@gentoo.org> you wrote:
>
> so do what i said -- set the HOSTCC to the host you want the tools to run on.
>
> this will work for *all* tools instead of arbitrarily picking some to use
> HOSTCC while picking others to use CROSS.
Why are
Dear Mike Frysinger,
In message <201011101706.17988.vap...@gentoo.org> you wrote:
>
> based on your based comments, i'm really not surprised. you constantly
> prefer
> to ignore reality and the state of GNU toolchains. plus, you ignore other
I'm a software developer. If tool chains are broke
On Wed, 10 Nov 2010 22:28:29 +0100
Wolfgang Denk wrote:
> Well, see above. You are argumenting from a low-level, implementation
> point of view. For the end user this is not transparent at all. He
> just runs a single "make foo_config" and a single "make all". The end
> user sees and thinks
On 2010-11-10, Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <201011100423.13449.vap...@gentoo.org> you wrote:
>>
>> > - use the cross compiler again (fw_printenv is intended for a
>> > hosted environment on the target).
>>
>> the cross-compiler used to create u-boot has no guarant
On Wednesday, November 10, 2010 14:54:17 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > Mike, what _exactly_ was the reason to drop cross compilation?
> >
> > nothing was "dropped". you need to set your HOSTCC correctly for the
> > host on which you want tools to compile.
>
> But it is WRONG
Signed-off-by: Kumar Gala
---
* fix typo in defind -> define
include/configs/MPC8569MDS.h |1 +
include/configs/MPC8572DS.h |1 +
include/configs/P1022DS.h|1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569M
On Wednesday, November 10, 2010 06:58:51 Daniel Hobi wrote:
> On 10.11.2010 10:23, Mike Frysinger wrote:
> > On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
> >> - use the cross compiler again (fw_printenv is intended for a
> >>
> >> hosted environment on the target).
> >
> > the cross-
On Wednesday, November 10, 2010 15:00:48 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > - use the cross compiler again (fw_printenv is intended for a
> > >
> > > hosted environment on the target).
> >
> > the cross-compiler used to create u-boot has no guarantee that it'll
> > produce execu
On Wed, 10 Nov 2010 22:30:07 +0100
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20101110151241.49d68...@udp111988uds.am.freescale.net> you wrote:
> >
> > > Would that hurt? I though Linux does it's own initialization of the
> > > PCI system anyway, so does it matter what we did in U-
Dear Timur Tabi,
In message <4cdb0b65.8090...@freescale.com> you wrote:
>
> I guess you don't know about the U-Boot patch submission drinking game?
>
> :-)
May I consider this an invitation?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
Dear Scott Wood,
In message <20101110151241.49d68...@udp111988uds.am.freescale.net> you wrote:
>
> > Would that hurt? I though Linux does it's own initialization of the
> > PCI system anyway, so does it matter what we did in U-Boot?
>
> It's caused us problems in the past on 83xx. I think it st
Dear Scott Wood,
In message <20101110150307.279a5...@udp111988uds.am.freescale.net> you wrote:
>
> I was just looking for some consistency so I could figure out what is
> being objected to. When something is rejected for specific reasons,
> questioning whether those reasons actually imply the con
Wolfgang Denk wrote:
> Definitely not. I'm afraid you'd never be sober again, and while this
> might deem a desirable state to you I would not want to see you
> submitting U-Boot patches then :-)
I guess you don't know about the U-Boot patch submission drinking game?
:-)
--
Timur Tabi
Linux ke
Dear Timur Tabi,
In message <4cdb0686@freescale.com> you wrote:
>
> Well, I really do think it should be done at every boot by default, but I
> would
> be willing to consider an "fdt verify" command. Would you be willing to buy
> me
> a beer every time someone forgets to run "fdt verify" an
On Wed, 10 Nov 2010 21:34:51 +0100
Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <4cdafc37.40...@freescale.com> you wrote:
> >
> > It's more than that. Any mismatch in the CCSR base address, serial device
> > offsets, or PCI addresses will be caught. For instance, if you put the
> >
On Wednesday, November 10, 2010 07:24:51 Sebastien Carlier wrote:
> I was wondering whether config.mk is the right place for this function;
> would it be better in rules.mk instead? Both config.mk and rules.mk end
> up being included in all Makefile's.
for now, keep it with the other compiler tar
On Tue, 9 Nov 2010 23:22:26 +0100
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20101109155225.183a3...@udp111988uds.am.freescale.net> you wrote:
> >
> > What, semantically, is the difference between the CONFIG_SYS_TEXT_BASE
> > and CONFIG_SYS_MONITOR_BASE? Just that one is used from
Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <4cdafc37.40...@freescale.com> you wrote:
>>
>> It's more than that. Any mismatch in the CCSR base address, serial device
>> offsets, or PCI addresses will be caught. For instance, if you put the PCIE1
>> memory range at ff80 in the devi
From: Haiying Wang
Signed-off-by: Haiying Wang
---
v3 change: %s/CONFIG_SYS_TEXT_BASE/CONFIG_SYS_MONITOR_BASE/g
arch/powerpc/cpu/mpc85xx/start.S | 18 +-
include/configs/MPC8536DS.h |8 ++--
include/configs/MPC8569MDS.h |
Dear Timur Tabi,
In message <4cdafc37.40...@freescale.com> you wrote:
>
> It's more than that. Any mismatch in the CCSR base address, serial device
> offsets, or PCI addresses will be caught. For instance, if you put the PCIE1
> memory range at ff80 in the device tree, but ff600 in U-Bo
On Wed, 10 Nov 2010 15:21:27 -0500
haiying.w...@freescale.com wrote:
> From: Haiying Wang
>
> Signed-off-by: Haiying Wang
> ---
> v2 change: remove 8569 CONFIG_MMC change which should not be in this patch.
>
> arch/powerpc/cpu/mpc85xx/start.S | 12
> include/configs
Wolfgang Denk wrote:
> I understand that you can reasonably check these addresses only in
> this specific case (i. e. a 36 bit DT and a 32 bit U-Boot) ?
That was just an example, albeit a very common one. This code can check for any
mismatch in CCSR device physical addresses between the U-Boot c
From: Haiying Wang
Signed-off-by: Haiying Wang
---
v2 change: remove 8569 CONFIG_MMC change which should not be in this patch.
arch/powerpc/cpu/mpc85xx/start.S | 12
include/configs/MPC8536DS.h |8 ++--
include/configs/MPC8569MDS.h
Dear Heiko Schocher,
In message <4cdacc7c.3040...@denx.de> you wrote:
>
> looked in the generation of GENERATED_GBL_DATA_SIZE:
>
> ./lib/asm-offsets.c
>
> /* Round up to make sure size gives nice stack alignment */
> DEFINE(GENERATED_GBL_DATA_SIZE,
> (sizeof(stru
Dear Heiko Schocher,
In message <4cdabcf8@denx.de> you wrote:
>
> Then we should add this alignment into the generation of
> GENERATED_GBL_DATA_SIZE.
No. GENERATED_GBL_DATA_SIZE is just a size. As you don't really know
the alignment of the base address that GENERATED_GBL_DATA_SIZE is
added
Dear "Asokan, Shyama Trikkadeeri",
In message
<575ed9d63b7e244bbb3786a299acbba08af...@ie10ev813.global.ds.honeywell.com> you
wrote:
>
> It looks like there has been a mail chain regarding this compile error
> and it has also been fixed. Can someone let me know which uboot version
> has this fixe
Dear Mike Frysinger,
In message <201011100423.13449.vap...@gentoo.org> you wrote:
>
> > - use the cross compiler again (fw_printenv is intended for a
> > hosted environment on the target).
>
> the cross-compiler used to create u-boot has no guarantee that it'll produce
> executables useful for
Dear Mike Frysinger,
In message <201011100419.10315.vap...@gentoo.org> you wrote:
>
> > Mike, what _exactly_ was the reason to drop cross compilation?
>
> nothing was "dropped". you need to set your HOSTCC correctly for the host on
> which you want tools to compile.
But it is WRONG to use HOST
Dear Timur Tabi,
In message <1289343709-11793-1-git-send-email-ti...@freescale.com> you wrote:
> U-Boot uses macros to determine where devices should be located in physical
> memory, and Linux uses the device tree to determine where the devices are
> actually located. However, U-Boot does not upd
From: Haiying Wang
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc85xx/start.S | 12
include/configs/MPC8536DS.h |8 ++--
include/configs/MPC8569MDS.h | 10 +++---
include/configs/P1_P2_RDB.h |8
From: Haiying Wang
Fix u-boot-nand.lds and u-boot-nand_spl.lds according to:
Author: Peter Tyser
Date: Wed Sep 29 14:05:56 2010 -0500
commit fbe53f59bd40b3b1ab66dc98859e26589d64d1b7
85xx: Use gc-sections to reduce image size
Signed-off-by: Haiying Wang
---
arch/powerpc/cpu/mpc85xx/u-bo
On Thu, 2010-11-04 at 14:22 -0400, Haiying Wang wrote:
> On Thu, 2010-11-04 at 09:36 -0700, Peter Tyser wrote:
> > Glad to hear. I'll submit an official patch shortly. Just to make
> > sure, have you tried running one of the nand-spl images after the
> > patch
> > I sent yesterday? It'd be good
Hi Albert and Heiko,
On 10.11.2010 17:46, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> Why not add alignment to start.S?
>>
>> /* Set stackpointer in internal RAM to call board_init_f */
>> call_board_init_f:
>> ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
>> +bic sp, sp, #7
>
> Hmm.. b
Hello Daniel,
Daniel Hobi wrote:
> On 10.11.2010 16:40, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> But you also added assembly code to setup the initial stack pointer in
>>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>>
>>> /* Set stackpointer in internal RAM to c
Le 10/11/2010 16:46, Daniel Hobi a écrit :
> Hi Heiko,
>
> On 10.11.2010 16:40, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> But you also added assembly code to setup the initial stack pointer in
>>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>>
>>> /* Set stackpoint
On Wed, Nov 10, 2010 at 8:09 AM, Kumar Gala wrote:
> Signed-off-by: Kumar Gala
> ---
> include/configs/MPC8569MDS.h | 1 +
> include/configs/MPC8572DS.h | 1 +
> include/configs/P1022DS.h | 1 +
There's nothing wrong with the on-board Ethernet of the P1022DS, so
why are you enabling
whN Vk6AES 9Pd zgXZi pjv
Hi Sir and Madam,
We are currently having a special offer on the newest designed "Trendy Duffle".
Please kindly see the flyer
and the quotation below.
Item: Trendy Duffle(#4650-25)
Price: FOB Xiamen, China. US$2.10/pc for 3,000 pcs
FOB Xiamen, Chi
Hi Heiko,
On 10.11.2010 16:40, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> But you also added assembly code to setup the initial stack pointer in
>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>
>> /* Set stackpointer in internal RAM to call board_init_f */
>> call_bo
Hello Daniel,
Daniel Hobi wrote:
> On 10.11.2010 16:02, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> Reading your patch, I noticed that we don't align the early stack
>>> pointer to an 8-byte boundary which may lead to the problem described here:
>>>
>>> http://article.gmane.org/gmane.comp.boot
Hi Kumar,
--- On Wed, 11/10/10, Kumar Gala wrote:
> From: Kumar Gala
> Subject: [U-Boot] [PATCH] powerpc/8xxx: Enable e1000 driver on some FSL boards
> To: u-boot@lists.denx.de
> Date: Wednesday, November 10, 2010, 12:09 PM
> Signed-off-by: Kumar Gala
> ---
> include/configs/MPC8569MDS.h |
Hi Heiko,
On 10.11.2010 16:02, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> Reading your patch, I noticed that we don't align the early stack
>> pointer to an 8-byte boundary which may lead to the problem described here:
>>
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/69342
>
> Thi
IT Service,
You have exceeded the limit of your mailbox set by your IT service provider,
you will be unable to receive new emails. Just before this message was sent,
you are Currently running on 91624 KB, You have has exceeded the storage limit
which is 20GB. To prevent this, please click to res
Hello Daniel,
Daniel Hobi wrote:
> Hi Heiko,
>
> On 10.11.2010 15:15, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> @Heiko: include/configs/km_arm.h may have the same problem.
>> I made a patch for this, see:
>>
>> http://lists.denx.de/pipermail/u-boot/2010-November/081275.html
>
> Reading you
Hi Heiko,
On 10.11.2010 15:15, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> @Heiko: include/configs/km_arm.h may have the same problem.
>
> I made a patch for this, see:
>
> http://lists.denx.de/pipermail/u-boot/2010-November/081275.html
Reading your patch, I noticed that we don't align the ea
On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
> Can you make the ELF images available? I'll do the readlf/objdump
> analysis and feed back on what I find.
I've uploaded them here:
http://www.cs.cmu.edu/~ecc/u-boot.{good,bad}
Thanks.
--
Eric Cooper e c c @ c m u
Hello Daniel,
Daniel Hobi wrote:
> In commit 0b20ed76 (Kirkwood: Changes specific to ARM relocation
> support), you set CONFIG_SYS_INIT_SP_ADDR to 0xC8012000 which is
> supposed to lie within the internal Security SRAM.
>
> However, the Kirkwood Functional Specification (chapter 2.13 Default
> Ad
When P2020DS DDR2 was merged it was merged incorrectly and propogated to
boards.cfg. Fix this by moving DDR2 config to be associated with
P2020DS and not P1_P2_RDB.
Signed-off-by: Kumar Gala
---
boards.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/boards.cfg b/bo
Signed-off-by: Kumar Gala
---
include/configs/MPC8569MDS.h |1 +
include/configs/MPC8572DS.h |1 +
include/configs/P1022DS.h|1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index 6a15da5..8f7c90a 1006
Hi Prafulla,
In commit 0b20ed76 (Kirkwood: Changes specific to ARM relocation
support), you set CONFIG_SYS_INIT_SP_ADDR to 0xC8012000 which is
supposed to lie within the internal Security SRAM.
However, the Kirkwood Functional Specification (chapter 2.13 Default
Address Map) and arch/arm/include/
On 10.11.2010 13:48, Albert ARIBAUD wrote:
> Le 10/11/2010 13:31, Daniel Hobi a écrit :
But shouldn't this change be applied to all ARM linker scripts, ie
arch/arm/cpu/*/u-boot.lds?
>>>
>>> Yes, it should. :)
>>
>> Can you please provide such a patch?
>
> I could, but I tend to provide p
Dear Claudio,
> Dear Reinhard
> thank you for your review. I know that post the patches on an
> webserver isn't the common path but this time this was really a wip
> work...
>>> 0003-AT91-fix-compile-error-after-f5571dc9.patch
>> [at91sam9260_devices.c]
>>
>> That include can not be necessary for y
This patch makes tools/env/Makefile more similar to tools/imls:
- define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
- include U-Boot headers using -idirafter to prevent picking up
u-boot/include/errno.h.
- use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
In order
Dear concerned,
> - Move static variables to struct global_data, so they can be used
>before relocation. Used by AT91 timers and proposed for A320 and
>S3C64xx in:
>
>http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095
>http://article.gmane.org/gmane.comp.boot-loaders.u
Le 10/11/2010 13:31, Daniel Hobi a écrit :
> Since all ARM boards are broken when using a recent toolchain, the patch
> should go in as fast as possible.
>
>>> But shouldn't this change be applied to all ARM linker scripts, ie
>>> arch/arm/cpu/*/u-boot.lds?
>>
>> Yes, it should. :)
>
> Can you ple
Ping?
>
> The fixup procedure just stored a constant value in the
> fixup table rather than just adjusting the table.
> Although that doesn't seem to do any harm, it prevents
> relocation more that once.
>
> Signed-off-by: Joakim Tjernlund
> ---
> arch/powerpc/cpu/74xx_7xx/start.S |2 +-
> a
On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
> On 2010-11-10 01:57:30, Mike Frysinger wrote:
> > the config.mk looks weird:
> > +cmd_link_o_target = $(if $(strip $1),\
> > + $(LD) -r -o $@ $1 ,\
> > + rm -f $@; $(AR) rcs $@ )
> >
> > w
>
> Timur Tabi wrote:
> > Wood Scott-B07421 wrote:
> > > To be totally safe, we probably want to do a readback plus twi (to turn
> > > a data dependency into a flow dependency) before the isync.
> >
> > twi == trap word immediate?
>
> Yes.
>
> > If so, I don't see how that will turn a data dependen
On Monday, November 08, 2010 13:15:38 Detlev Zundel wrote:
> > Mike Frysinger wrote:
> >> Convert the tools/env/Makefile to use the same host tool syntax as the
> >> other tool subdirs.
> >
> > Applied to "next" branch. Thanks
>
> It just occurred to me that this will no longer cross compile the
On 2010-11-10 03:55:21, Mike Frysinger wrote:
> On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
> > On 2010-11-10 01:57:30, Mike Frysinger wrote:
> > > the config.mk looks weird:
> > > +cmd_link_o_target = $(if $(strip $1),\
> > > + $(LD) -r -o $@ $1 ,\
> > >
Hi Mike,
On 10.11.2010 10:23, Mike Frysinger wrote:
> On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
>> - use the cross compiler again (fw_printenv is intended for a
>> hosted environment on the target).
>
> the cross-compiler used to create u-boot has no guarantee that it'll produce
Hi,
I have been trying to build Uboot for an at91sam9263ek board and been
observing the following error while building the uboot code( using the
UBOOT version: u-boot-2009.11.1.tar.bz2)
/home/wd/git/u-boot/work/lib_generic/crc32.c:157: error: conflicting
types for 'crc32'
/home/wd/git/u-b
Dear Reinhard
thank you for your review. I know that post the patches on an
webserver isn't the common path but this time this was really a wip
work...
2010/11/9 Reinhard Meyer :
> Dear Claudio,
>>
>> 2010/11/8 Andreas Bießmann:
>>>
>>> There where some major changes regarding arm relocation. Some
Hi Albert,
On 09.11.2010 19:47, Albert ARIBAUD wrote:
> Le 09/11/2010 19:24, Daniel Hobi a écrit :
>> Thank you. This patch is required to get Kirkwood-based boards working
>> again when using the CodeSourcery 2009q3 toolchain.
>
> (can't find the 2010q3 Lite toolchain on CodeSourcery's site, lat
The following changes since commit 0c0892be0d93a5a892b93739c5eb3bf692fed4ff:
Merge branch 'master' of git://git.denx.de/u-boot-marvell (2010-10-29
22:03:00 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git sf
Reinhard Meyer (1):
sf: ramtron: new
On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
> This patch makes tools/env/Makefile more similar to tools/imls:
> - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
> - include U-Boot headers using -idirafter to prevent picking up
> u-boot/include/errno.h.
these thin
Scott,
>> looks like I made a mistake on current MPC8377 NAND wiring.
>>
>> Nand-Flash "write enable" is wired to LFWE1 ... I connected each WE to
>> its corresponding CS, i.e. :
>>
>> - CS0/WE0 -> Nor Flash
>> - CS1/WE1 -> Nand Flash
>> - CS2/WE2 -> MRAM
>>
>> Am I assuming right that FCM can
Sebastien,
>> I also don't understand why ftd.c is not depending on CONFIG_QE.
>> That's another question ... but leads to error having your patch applied.
>>
> Right, fdt.c should not be included in the build unless both CONFIG_QE
> and CONFIG_OF_LIBFDT are defined. Previously this issue wa
Dear Mike,
On 2010-11-10 01:57:30, Mike Frysinger wrote:
>
> On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> > This commit changes all Makefiles to use partial linking (ld -r) instead of
> > creating library archives, which forces all symbols to participate in
> > linking, allowi
Dear Mike Frysinger,
Am 10.11.2010 07:57, schrieb Mike Frysinger:
> On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> the config.mk looks weird:
> +cmd_link_o_target = $(if $(strip $1),\
> + $(LD) -r -o $@ $1 ,\
> + rm -f $@; $(AR) rcs $@ )
90 matches
Mail list logo