From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 06 Feb 2012 22:21:39 +0100 Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? In-Reply-To: References: <4F2B8BD1.2030009@de.bosch.com> <4F2CF73F.2090407@ti.com> <4F2D0FE7.8020107@aribaud.net> Message-ID: <4F304463.1050901@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, Le 06/02/2012 15:34, Tom Rini a ?crit : > On Sat, Feb 4, 2012 at 4:00 AM, 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: >>>> >>>> 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 >> . >> >> 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.