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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
