From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 08 Jul 2010 08:54:07 +0200 Subject: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client In-Reply-To: References: <4C335AA1.2090803@free.fr> <4C34602C.8030601@free.fr> <4C3489AB.1060308@free.fr> Message-ID: <4C35760F.5010509@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 08/07/2010 08:09, Prafulla Wadaskar a ?crit : > > >> -----Original Message----- >> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] >> Sent: Wednesday, July 07, 2010 7:36 PM >> To: Prafulla Wadaskar >> Cc: u-boot at lists.denx.de; kalyan karnati >> Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for >> OpenRD client >> >> Le 07/07/2010 13:44, Prafulla Wadaskar a ?crit : >> >>> you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE) >> >> That's what I do, either through JTAG or by tftp/go in >> resident u-boot. >> >>> for boot from RAM, you must need at least SDRAM configured, >> so JTAG is the way >> >> JTAG does work indeed. Howvever, when: >> >> - I power up the board; >> - ROM boot loads u-boot from NAND and starts it; >> - I stop u-boot and get to the prompt; >> - I 'tftp' an u-boot.bin image into RAM at 1000000; >> - I 'go' to 1000000 >> >> ... the tftp'ed image fails to boot although SDRAM is >> obviously already >> configured. > > This is obvious, since u-boot being copied is not created with TEXT BASE=0x100000, is it? > And I don?t know how "go TEXT BASE" responds to u-boot binary itself, I have never tested this use case. Well, it isn't so obvious, as normally one should be able to start u-boot from any address, as the first thing u-boot does is relocate itself back to its TEXT_BASE (see arch/arm/cpu/arm926ejs/start.S). This feature is precisely there to allow chaining one u-boot in RAM from another one. This relocation feature is compiled in by default; one must define CONFIG_SKIP_RELOCATE_UBOOT, to explicitely forbid u-boot from doing so. >> OTOH, openOCD boots the RAM image fine, so I guess OpenOCD does some >> inits that the boot rom plus resident u-boot don't. > > Openocd configures RAM before loading u-boot.bin > U-boot.kwb does the same but internal bootROM does this instead of openOCD in case of boot from NAND > U-boot.bin anyway needs SDRAM configurations to be done by someone else before starting execution. I don't mean SDRAM is not initialized; obviously it is. However, something else prevents the kirkwood u-boot to chain from itself. I'd thought an initialization is missing, but actually it could be something about the relocation. > Regards.. > Prafulla . . Amicalement, -- Albert.