All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@de.bosch.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?
Date: Fri, 3 Feb 2012 08:25:05 +0100	[thread overview]
Message-ID: <4F2B8BD1.2030009@de.bosch.com> (raw)

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 tried it, but for (1) it might help to not jump to clear_bss, 
but instead jumping to the 'fix .rel.dyn relocations' section. Just 
avoiding the extra copy.

For (2) I don't have an idea how to solve this cleanly.


Do I have missed anything? Is there a clean way to skip the extra copy 
from RAM -> RAM in this case? Any idea or opinions?

Many thanks and best regards

Dirk

[1]

arch/arm/cpu/armv7/start.S:

relocate_code:
	mov	r4, r0	/* save addr_sp */
	mov	r5, r1	/* save addr of gd */
	mov	r6, r2	/* save addr of destination */

	/* Set up the stack						    */
stack_setup:
	mov	sp, r4

	adr	r0, _start
	cmp	r0, r6
	moveq	r9, #0		/* no relocation. relocation offset(r9) = 0 */
	beq	clear_bss		/* skip relocation */
	mov	r1, r6			/* r1 <- scratch for copy_loop */
	ldr	r3, _image_copy_end_ofs
	add	r2, r0, r3		/* r2 <- source end address	    */

copy_loop:
	ldmia	r0!, {r9-r10}		/* copy from source address [r0]    */
	stmia	r1!, {r9-r10}		/* copy to   target address [r1]    */
	cmp	r0, r2			/* until source end address [r2]    */
	blo	copy_loop

#ifndef CONFIG_SPL_BUILD
	/*
	 * fix .rel.dyn relocations
	 */
	ldr	r0, _TEXT_BASE		/* r0 <- Text base */
	sub	r9, r6, r0		/* r9 <- relocation offset */
	ldr	r10, _dynsym_start_ofs	/* r10 <- sym table ofs */
	add	r10, r10, r0		/* r10 <- sym table in FLASH */
	ldr	r2, _rel_dyn_start_ofs	/* r2 <- rel dyn start ofs */
	add	r2, r2, r0		/* r2 <- rel dyn start in FLASH */
	ldr	r3, _rel_dyn_end_ofs	/* r3 <- rel dyn end ofs */
	add	r3, r3, r0		/* r3 <- rel dyn end in FLASH */
fixloop:
	ldr	r0, [r2]		/* r0 <- location to fix up, IN FLASH! */
	add	r0, r0, r9		/* r0 <- location to fix up in RAM */
	ldr	r1, [r2, #4]
	and	r7, r1, #0xff
	cmp	r7, #23			/* relative fixup? */
	beq	fixrel
	cmp	r7, #2			/* absolute fixup? */
	beq	fixabs
	/* ignore unknown type of fixup */
	b	fixnext
fixabs:
	/* absolute fix: set location to (offset) symbol value */
	mov	r1, r1, LSR #4		/* r1 <- symbol index in .dynsym */
	add	r1, r10, r1		/* r1 <- address of symbol in table */
	ldr	r1, [r1, #4]		/* r1 <- symbol value */
	add	r1, r1, r9		/* r1 <- relocated sym addr */
	b	fixnext
fixrel:
	/* relative fix: increase location by offset */
	ldr	r1, [r0]
	add	r1, r1, r9
fixnext:
	str	r1, [r0]
	add	r2, r2, #8		/* each rel.dyn entry is 8 bytes */
	cmp	r2, r3
	blo	fixloop
	b	clear_bss
_rel_dyn_start_ofs:
	.word __rel_dyn_start - _start
_rel_dyn_end_ofs:
	.word __rel_dyn_end - _start
_dynsym_start_ofs:
	.word __dynsym_start - _start

#endif	/* #ifndef CONFIG_SPL_BUILD */

clear_bss:
	ldr	r0, _bss_start_ofs
	ldr	r1, _bss_end_ofs
	mov	r4, r6			/* reloc addr */
	add	r0, r0, r4
	add	r1, r1, r4
	mov	r2, #0x00000000		/* clear	

             reply	other threads:[~2012-02-03  7:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-03  7:25 Dirk Behme [this message]
2012-02-03  8:51 ` [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? Stefano Babic
2012-02-03 10:18   ` Dirk Behme
2012-02-03 11:00     ` Stefano Babic
2012-02-03 11:19       ` Mike Frysinger
2012-02-04  8:38       ` [U-Boot] i.MX5/6 U-Boot: Cache enabling (was: Re: Skipping relocation RAM to RAM, esp. on i.MX6?) Dirk Behme
2012-02-04  9:18         ` [U-Boot] i.MX5/6 U-Boot: Cache enabling Aneesh V
2012-02-04 10:18         ` [U-Boot] i.MX5/6 U-Boot: Cache enabling (was: Re: Skipping relocation RAM to RAM, esp. on i.MX6?) Marek Vasut
2012-02-08 13:37           ` [U-Boot] i.MX5/6 U-Boot: Cache enabling Dirk Behme
2012-02-09  7:06             ` Marek Vasut
2012-02-04  9:15 ` [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? Aneesh V
2012-02-04 11:00   ` Albert ARIBAUD
2012-02-04 11:14     ` Aneesh V
2012-02-04 11:37       ` Albert ARIBAUD
2012-02-06 14:34     ` Tom Rini
2012-02-06 21:21       ` Albert ARIBAUD
2012-02-06 22:27         ` Wolfgang Denk
2012-02-06 22:41           ` Graeme Russ
2012-02-07  7:19             ` Aneesh V
2012-02-07 23:26               ` Wolfgang Denk
2012-02-08  6:43                 ` Aneesh V
2012-02-08 13:58                   ` Wolfgang Denk
2012-02-08 14:48                     ` Aneesh V
2012-02-08 16:23                       ` Wolfgang Denk
2012-02-09  6:01                         ` Aneesh V
2012-02-09 11:44                           ` Wolfgang Denk
2012-02-09 13:43                             ` Aneesh V
2012-02-05  6:19   ` Simon Glass
2012-02-06 14:19     ` Aneesh V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2B8BD1.2030009@de.bosch.com \
    --to=dirk.behme@de.bosch.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.