Dear Reinhard, Wolfgang,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Reinhard Meyer Sent: Tuesday, November 02, 2010 3:04 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de; hs@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