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. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot