Hi Tom,
Le 06/02/2012 15:34, Tom Rini a écrit :
On Sat, Feb 4, 2012 at 4:00 AM, Albert ARIBAUD
<albert.u.b...@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.
That's for a given platform *and* a given U-Boot build, since the U-Boot
location is computed from top of DDR down, so if U-Boot grows or
shrinks, its base address will change.
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot