[U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations

[Albert ARIBAUD]

Le 05/10/2010 07:42, Graeme Russ a écrit :
> On Tue, Oct 5, 2010 at 4:40 PM, Graeme Russ<graeme.russ at gmail.com>  wrote:
>> On Tue, Oct 5, 2010 at 4:34 PM, Wolfgang Denk<wd at denx.de>  wrote:
>>> Dear Graeme Russ,
>>>
>>> In message<AANLkTikqE0_DEqHs-tX3A4XuEXJhM0CYW_+j6izhmktw at mail.gmail.com>  you wrote:
>>>>
>>>> Can NAND SPL initialise and size memory before loading U-Boot into RAM?
>>>
>>> It has to. You cannot load into and run from uninitialized RAM ;-)
>>>
>>>> If so, could the relocation code be added to NAND SPL so only one copy
>>>> operation is performed?
>>>
>>> I'm afraid it cannot, due to size limitations. The NAND loader often
>>> hast to fit into as little a 2 or 4 KiB...
>>>
>>
>> For x86, the actual relocation calculations can be done in a probably a
>> few dozen bytes of code. It contains:
>>
>>   - One offset calculation
>>   - A single tight loop
>>   - Two comparisons (probably not needed in the generic case as they are used
>>    to filter out x86 specific code outside .text)
>>   - An offset addition
>>
>> If the only constraint is space then it _may_ be possible in some scenarios
>> (although I do acknowledge that previous trival changes have caused the
>> size constaint to be violated)
>>
>
> Another alternative is to load into upper memory and have the relocation
> code detect that U-Boot is already there and skip the copy operation

The loader would have to know something about the way u-boot relocates 
itself, and this may change based on configuration.

For instance, on ARM, if either icache or dcache are configured, u-boot 
will reserve the upper 64 KB for TLB and thus relocate 64 KB lower than 
if neither icache nor dcache are configured. Ditto for VFD, LCD 
framebuffer, etc. Only after these allocations, and thus below them, is 
u-boot finally relocated.

An independent loader would thus have to figure all this out in order to 
know how exactly where u-boot expects to relocate, otherwise it may put 
u-boot at a location which would be almost, but not quite, entirely 
unlike the intended one -- and that's the worst possible choice, as we 
now hit the dreaded 'relocate over oneself' issue.

OTOH, the u-boot board.c may possibly be modified so that the the final 
location of the u-boot code only depend on its code size, not its 
configuration options. Something like, in descending order: u-boot code, 
data and bss; TLBs, VFDs, framebuffers, etc; malloc arena; and stack.

> Regards,
>
> Graeme

Amicalement,
-- 
Albert.