-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/17/12 10:48, Marek Vasut wrote:
Dear Tom Rini,
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
Dear Tom Rini,
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
Dear Jos? Miguel Gon?alves,
On 09/16/2012 11:06 AM, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>> Dear Jos? Miguel Gon?alves, >>> >>>> Jumping to board_init_r is not performed due to a >>>> bug on address computation. >>> >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? >>> I don't detect any misbehavior on my arm926 >>> boards. >> >> Maybe because you are not using it to build an SPL? > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > >> Please check the same chunk of code in other start.S >> for arm1176 and armv7. They have the same code that I >> put for arm926ejs. > > Please wait and please first explain what is the > issue.
The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway ..
Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be
board_init_f calls
memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ?
I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people).
How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted to C. Then if we made it generic enough, those MANUAL_RELOC platforms could simply adopt the C code.
Yes, one of the platforms that already has C code for ELF relocation (x86, iirc) could be made more generic and I think someone (Graeme?) already started this a long time ago as part of making a generic set of functions for board_init_{f,r}. Just can't make it for all platforms until everyone has ELF is the point I was poorly making.
- -- Tom