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:
- 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.
- 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.
br, Aneesh