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

[Tom Rini]

On Sat, Feb 4, 2012 at 4:00 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> 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?

In my experience, the offset is consistent on a given platform so once
you do the dance once to figure out where it'll be placed you can just
start off debugging post-relocation.

-- 
Tom