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

Albert ARIBAUD
2010-11-01T19:53:09Z

Le 01/11/2010 20:44, Graeme Russ a ?crit :
> On Tuesday, November 2, 2010, Albert ARIBAUD<albert.aribaud@free.fr> wrote:
>> Le 01/11/2010 20:23, Wolfgang Denk a ?crit :
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4CCEF2E4.5080003@free.fr> you wrote:
>>>>
>>>> Also, I understand why the second RFC change I did was harmful to tx25.
>>>> Contrary to u-boot itself, u-boot-spl is not compiled to be position
>>>> independent; it actually loads at a given address then copies itself,
>>>> without relocating, to its home location.
>>>
>>> It copies _itself_? Not the U-Boot payload?
>>>
>>> Heiko, is this intentional? Do we really first load the whole image,
>>> then copy the U-Boot payload to some other address, then relocate it
>>> to yet another one?
>>
>> I haven't been clear.
>>
>> The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and
>> jumps to it.
>>
>> u-boot-spl copies itself at its intended location if not already there,
>> and jumps to tiself at that new location.
>>
>> u-boot-spl loads u-boot at a fixed location and jumps to it.
>>
>> u-boot relocates (copies and fixes up) itself at top of ram if not
>> already there, and jumps to itself at that new location.
>>
>
> Wow, what a terrible waste!
>
> Why does u-boot-spl need to relocate?

As I said, u-boot-spl does not relocate, it only copies itself to its
link-time location and jumps there, and it does this only if loaded
somewhere else to boot (if I may say so). *Usually* it will be loaded at
the right place and thus won't copy itself and jump to itself.

It still takes up some space, though. The copy and jump could actually
be #ifdef's on CONFIG_NAND_SPL if everyone thinks it is safe -- please
comment quickly as I'm preparing a patch set and that could go in it if
agreed to.

> Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have
> tight space constraints?

It has; it comes from a (usually small) NAND page.

> Regards
>
> Graeme

Amicalement,
--
Albert.