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