[U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Albert ARIBAUD]

Le 04/02/2012 10:15, Aneesh V a écrit :
> Hi Dirk,
>
> On Friday 03 February 2012 12:55 PM, Dirk Behme wrote:
>> Hi,
>>
>> on i.MX6 devices, e.g. ARM2 or SabreLite, the ROM boot loader copies the
>> U-Boot image from the boot device, e.g. the SD card, to the main memory.
>> This does mean that U-Boot is started in RAM.
>>
>> With this, one might wonder why any relocation RAM -> RAM is done anyway
>> and if this could be skipped?
>>
>> Looking into the details shows that board_init_f() in
>> arch/arm/lib/board.c and relocate_code() in arch/arm/cpu/armv7/start.S
>> [1] are involved in this.
>>
>> In board_init_f() the relocation destination address 'addr' is
>> calculated. This is basically at the end of the available RAM (- some
>> space for various stuff like TLB tables etc.). At SabreLite this results
>> in 0x4FF8D000.
>>
>> By the boot loader, the U-Boot is loaded to
>>
>> CONFIG_SYS_TEXT_BASE 0x17800000
>>
>> This results in relocate_code() copying U-Boot from RAM 0x17800000 to
>> RAM 0x4FF8D000.
>>
>> Setting CONFIG_SYS_TEXT_BASE to the relocation destination address
>> 0x4FF8D000 does avoid the (unnecessary?) copy by
>>
>> cmp r0, r6
>> moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
>> beq clear_bss /* skip relocation */
>>
>> in relocate_code().
>>
>> But:
>>
>> 1) The resulting image still runs without the relocation
>> (CONFIG_SYS_TEXT_BASE 0x4FF8D000). But e.g. the U-Boot command line
>> doesn't work properly any more. Most probably this is because not only
>> the copy is skipped by the 'beq clear_bss', but the whole 'fix .rel.dyn
>> relocations' is skipped too.
>>
>> 2) It's hard to set CONFIG_SYS_TEXT_BASE at compile time to the
>> relocation address calculated at runtime in board_init_f() due to the
>> amount of #ifdef and runtime calculation done there. So finding a
>> generic approach which could easily defined in the config files to avoid
>> the relocation seems difficult.
>
> I haven't really completely read your mail. But here is an
> implementation I had provided long time back for ARM. But Wolfgang
> didn't want to take it. You can see the patch and the following
> discussion in this thread:
>
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/96352

Recently there was an reminder by Wolfgang that debugging can be done 
even with relocation, provided the symbols are dropped and reloaded in 
gdb upon hitting the end of the relocate loop where the jump to (the new 
location of) board_init_f happens --see 
<http://www.denx.de/wiki/view/DULG/WrongDebugSymbolsAfterRelocation>.

I am not a specialist of gdb but I think it might be automated, too, so 
that if you want to debug u-boot past relocation then you would just 
have to enter a single command in gdb, or a script name when invoking 
gdb, to load u-boot in low RAM , set a breakpoint at the pivot point 
after relocation, run to that breakpoint, drop current symbols and 
reload symbols with the adequate offset, possibly computed from some 
accessible global.

Anyone itching enough to do some research and experiments on this?

> br,
> Aneesh

Amicalement,
-- 
Albert.