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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox