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

[Albert ARIBAUD]

Le 04/02/2012 12:14, Aneesh V a écrit :
> On Saturday 04 February 2012 04:30 PM, Albert ARIBAUD wrote:
>> 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?
>
> I employ a different method using my JTAG debugger.
>
> 1. Look at the content of gd using the address from r8. Lauterbach
> allows you to cast that address to a (struct global_data *) and view
> the contents.
>
> 2. Get reloc_off from gd and use that to relocate the symbols in
> Trace32.
>
> The advantage is that I can do all this after booting completely. No
> breakpoint needed.

Indeed, assuming you only want to debug post-relocation you can use this 
technique -- I guess it is applicable to GDB as well.

> br,
> Aneesh

Amicalement,
-- 
Albert.