[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Reinhard, Wolfgang, 

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Reinhard Meyer
> Sent: Tuesday, November 02, 2010 3:04 PM
> To: Albert ARIBAUD
> Cc: u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Dear Albert ARIBAUD,
> > Le 02/11/2010 09:57, Reinhard Meyer a écrit :
> >> Dear Heiko Schocher,
> >>> But there is a possibility to prevent one copy, if TEXT_BASE =
> >>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
> >>>
> >>> In this case nand_spl code copies u-boot from nand to
> >>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation
> address,
> >>> no need to copy code in relocate_code().
> >>>
> >>> But as codesize changes (and with it relocation address) this
> >>> is not a perfect solution.
> >>
> >> Worse: it would certainly crash since the original and relocated
> memory
> >> areas must not overlap - they sure would with even the slightest
> size
> >> change.
> >
> > I'm not sure I get you there. If u-boot was linked for a given
> address
> > and happends to be loaded at that same address, then there is no
> need to
> > relocate, right?
> 
> *if* the code size changes, "need" for relocation would arise...
> 
> >> I would recommend that we add code to check for overlapping
> relocation
> >> into
> >> board.c and print a panic message if an overlap is detected.
> >
> > I *think* overlap would be correctly handled if we modify the copy
> code
> > to copy from top to bottom, because we know that the destination
> is
> > higher than the source.
> 
> No, in above case the (new) destination could be lower than the
> loaded
> address (e.g. code size increased).
> 
> In any case it is not worth the effort to plan for overlapping
> relocations.
> We can always load u-boot to a very low address of SDRAM and let it
> relocate.
> 
> > The only tricky case would be when the target address is right in
> the
> > middle of the source relocation code, because then the last
> iteratons of
> > the copy code would corrupt this code; that can be avoided by
> making
> > sure the SPL loads u-boot low enough in RAM.
> 
> Exactly.
> 
> My original message was: "please to not give people the idea that
> they can
> avoid relocation by loading u-boot at the exact address the
> relocation would
> calculate. That is bound to *really* break at the slightest change
> to u-boot."

Shouldn't we provide a CONFIG option by which users can disable
Elf relocation? 

On production systems you know exactly how much memory you have.
Relocation may not be very useful. On the other hand faster boot is a 
bigger concern. Shouldn't we support this case?

Best regards,
Aneesh