From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Sat, 04 Feb 2012 14:45:43 +0530 Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? In-Reply-To: <4F2B8BD1.2030009@de.bosch.com> References: <4F2B8BD1.2030009@de.bosch.com> Message-ID: <4F2CF73F.2090407@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 br, Aneesh