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
next 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.