* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:31 [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations Albert Aribaud
@ 2010-10-05 6:45 ` Wolfgang Denk
2010-10-05 7:05 ` Reinhard Meyer
2010-10-05 7:07 ` Wolfgang Denk
2010-10-05 7:40 ` Heiko Schocher
` (3 subsequent siblings)
4 siblings, 2 replies; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 6:45 UTC (permalink / raw)
To: u-boot
Dear Albert Aribaud,
In message <1286260287-1571-1-git-send-email-albert.aribaud@free.fr> you wrote:
> HISTORY:
>
> V1 Initial patch
> V2 Rebased on latest mainline master
>
> This patch is *not* a submission for master!
With the following additional patches I got the code working on the
Qong board (i.MX31 = arm1136):
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 8b63192..40962a5 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -89,48 +89,35 @@ _end_vect:
_TEXT_BASE:
.word TEXT_BASE
-#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-.globl _armboot_start
-_armboot_start:
- .word _start
-#endif
-
/*
* These are defined in the board-specific linker script.
+ * Subtracting _start from them lets the linker put their
+ * relative position in the executable instead of leaving
+ * them null.
*/
-.globl _bss_start
-_bss_start:
- .word __bss_start
-
-.globl _bss_end
-_bss_end:
- .word _end
-
-#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-.globl _datarel_start
-_datarel_start:
- .word __datarel_start
+.globl _bss_start_ofs
+_bss_start_ofs:
+ .word __bss_start - _start
-.globl _datarelrolocal_start
-_datarelrolocal_start:
- .word __datarelrolocal_start
+.globl _bss_end_ofs
+_bss_end_ofs:
+ .word _end - _start
-.globl _datarellocal_start
-_datarellocal_start:
- .word __datarellocal_start
+.globl _datarel_start_ofs
+_datarel_start_ofs:
+ .word __datarel_start - _start
-.globl _datarelro_start
-_datarelro_start:
- .word __datarelro_start
+.globl _datarelrolocal_start_ofs
+_datarelrolocal_start_ofs:
+ .word __datarelrolocal_start - _start
-.globl _got_start
-_got_start:
- .word __got_start
+.globl _datarellocal_start_ofs
+_datarellocal_start_ofs:
+ .word __datarellocal_start - _start
-.globl _got_end
-_got_end:
- .word __got_end
-#endif
+.globl _datarelro_start_ofs
+_datarelro_start_ofs:
+ .word __datarelro_start - _start
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
@@ -225,9 +212,8 @@ stack_setup:
adr r0, _start
ldr r2, _TEXT_BASE
- ldr r3, _bss_start
- sub r2, r3, r2 /* r2 <- size of armboot */
- add r2, r0, r2 /* r2 <- source end address */
+ ldr r3, _bss_start_ofs
+ add r2, r0, r3 /* r2 <- source end address */
cmp r0, r6
beq clear_bss
@@ -239,36 +225,54 @@ copy_loop:
ble copy_loop
#ifndef CONFIG_PRELOADER
- /* fix got entries */
- ldr r1, _TEXT_BASE
- mov r0, r7 /* reloc addr */
- ldr r2, _got_start /* addr in Flash */
- ldr r3, _got_end /* addr in Flash */
- sub r3, r3, r1
- add r3, r3, r0
- sub r2, r2, r1
- add r2, r2, r0
-
+ /*
+ * fix .rel.dyn relocations
+ */
+ ldr r0, _TEXT_BASE /* r0 <- Text base */
+ sub r9, r7, 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 r4, [r2]
- sub r4, r4, r1
- add r4, r4, r0
- str r4, [r2]
- add r2, r2, #4
+ ldr r0, [r2] /* r0 <- location to fix up, IN FLASH! */
+ add r0, r9 /* r0 <- location to fix up in RAM */
+ ldr r1, [r2, #4]
+ and r8, r1, #0xff
+ cmp r8, #23 /* relative fixup? */
+ beq fixrel
+ cmp r8, #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, 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
- bne fixloop
+ ble fixloop
#endif
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
clear_bss:
#ifndef CONFIG_PRELOADER
- ldr r0, _bss_start
- ldr r1, _bss_end
+ ldr r0, _bss_start_ofs
+ ldr r1, _bss_end_ofs
ldr r3, _TEXT_BASE /* Text base */
mov r4, r7 /* reloc addr */
- sub r0, r0, r3
add r0, r0, r4
- sub r1, r1, r3
add r1, r1, r4
mov r2, #0x00000000 /* clear */
@@ -283,24 +287,34 @@ clbss_l:str r2, [r0] /* clear loop... */
* initialization, now running from RAM.
*/
#ifdef CONFIG_NAND_SPL
- ldr pc, _nand_boot
-
-_nand_boot: .word nand_boot
+ ldr r0, _nand_boot_ofs
+ adr r1, _start
+ add pc, r0, r1
+_nand_boot_ofs
+ : .word nand_boot - _start
#else
jump_2_ram:
- ldr r0, _TEXT_BASE
- ldr r2, _board_init_r
- sub r2, r2, r0
- add r2, r2, r7 /* position from board_init_r in RAM */
+ ldr r0, _board_init_r_ofs
+ adr r1, _start
+ add r0, r0, r1
+ add lr, r0, r9
/* setup parameters for board_init_r */
mov r0, r5 /* gd_t */
mov r1, r7 /* dest_addr */
/* jump to it ... */
- mov lr, r2
mov pc, lr
-_board_init_r: .word board_init_r
+_board_init_r_ofs:
+ .word board_init_r - _start
#endif
+
+_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
+
#else /* #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) */
/*
* the actual reset code
@@ -375,8 +389,11 @@ stack_setup:
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
clear_bss:
- ldr r0, _bss_start /* find start of bss segment */
- ldr r1, _bss_end /* stop here */
+ adr r2, _start
+ ldr r0, _bss_start_ofs /* find start of bss segment */
+ add r0, r0, r2
+ ldr r1, _bss_end_ofs /* stop here */
+ add r1, r1, r2
mov r2, #0x00000000 /* clear */
#ifndef CONFIG_PRELOADER
@@ -386,15 +403,19 @@ clbss_l:str r2, [r0] /* clear loop... */
bne clbss_l
#endif
- ldr pc, _start_armboot
+ ldr r0, _start_armboot_ofs
+ adr r1, _start
+ add r0, r0, r1
+ ldr pc, r0
+_start_armboot_ofs:
#ifdef CONFIG_NAND_SPL
-_start_armboot: .word nand_boot
+ .word nand_boot - _start
#else
#ifdef CONFIG_ONENAND_IPL
-_start_armboot: .word start_oneboot
+ .word start_oneboot - _start
#else
-_start_armboot: .word start_armboot
+ .word start_armboot - _start
#endif /* CONFIG_ONENAND_IPL */
#endif /* CONFIG_NAND_SPL */
@@ -487,7 +508,7 @@ cpu_init_crit:
#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
ldr r2, IRQ_STACK_START_IN @ set base 2 words into abort stack
#else
- ldr r2, _armboot_start
+ adr r2, _start
sub r2, r2, #(CONFIG_SYS_MALLOC_LEN)
sub r2, r2, #(CONFIG_SYS_GBL_DATA_SIZE+8) @ set base 2 words into abort stack
#endif
@@ -524,8 +545,8 @@ cpu_init_crit:
#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
ldr r13, IRQ_STACK_START_IN @ setup our mode stack (enter in banked mode)
#else
- ldr r13, _armboot_start @ setup our mode stack (enter in banked mode)
- sub r13, r13, #(CONFIG_SYS_MALLOC_LEN) @ move past malloc pool
+ adr r13, _start @ setup our mode stack (enter in banked mode)
+ sub r13, r13, #(CONFIG_STACKSIZE+CONFIG_SYS_MALLOC_LEN) @ move past malloc pool
sub r13, r13, #(CONFIG_SYS_GBL_DATA_SIZE+8) @ move to reserved a couple spots for abort stack
#endif
diff --git a/arch/arm/cpu/arm1136/u-boot.lds b/arch/arm/cpu/arm1136/u-boot.lds
index 1db4b49..99bd6d5 100644
--- a/arch/arm/cpu/arm1136/u-boot.lds
+++ b/arch/arm/cpu/arm1136/u-boot.lds
@@ -59,6 +59,14 @@ SECTIONS
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ .rel.dyn : { *(.rel.dyn) }
+ __rel_dyn_end = .;
+
+ __dynsym_start = .;
+ .dynsym : { *(.dynsym) }
+
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
diff --git a/include/configs/qong.h b/include/configs/qong.h
index 7a68b7b..03ed1b0 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -283,7 +283,7 @@ extern int qong_nand_rdy(void *chip);
"128k(env2),2432k(kernel),13m(ramdisk),-(user)"
/* additions for new relocation code, must added to all boards */
-#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE 0x80000000
#define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR
#define CONFIG_SYS_INIT_RAM_END IRAM_SIZE
Thanks a lot!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The use of COBOL cripples the mind; its teaching should, therefore,
be regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
^ permalink raw reply related [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:45 ` Wolfgang Denk
@ 2010-10-05 7:05 ` Reinhard Meyer
2010-10-05 7:23 ` Reinhard Meyer
2010-10-05 8:27 ` Wolfgang Denk
2010-10-05 7:07 ` Wolfgang Denk
1 sibling, 2 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 7:05 UTC (permalink / raw)
To: u-boot
Dear Wolfgang Denk, dear Albert Aribaud,
Initial Test reports:
File Size with Heiko's patch: 244k
U-Boot works.
File size with Albert's V2 patch: 255k
U-Boot stops at:
U-Boot 2010.09-00113-g3c5eeb8-dirty (Oct 05 2010 - 10:04:25)
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock : 198.656 MHz
Master clock : 99.328 MHz
I2C: ready
DRAM: 64 MiB
<dead here>
File size with Wolfgang's patch: 244k (strange!)
U-Boot stops at:
U-Boot 2010.09-00114-g1b05d80 (Oct 05 2010 - 10:14:32)
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock : 198.656 MHz
Master clock : 99.328 MHz
I2C: ready
DRAM: 64 MiB
FLASH: 512 KiB
NAND: 256 MiB
<dead here>
I only added #define CONFIG_RELOC_FIXUP_WORKS to my board config
(compared to the Heiko-version).
Did I miss to change anything else.
I find it strange that the file size shrinks back to the
Heiko version size when Wolfgang's patch variant is used.
Later I might have more time to investigate.
Best Regards,
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:05 ` Reinhard Meyer
@ 2010-10-05 7:23 ` Reinhard Meyer
2010-10-05 7:52 ` Reinhard Meyer
2010-10-05 8:27 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 7:23 UTC (permalink / raw)
To: u-boot
Dear Wolfgang Denk, dear Albert Aribaud,
>
> Initial Test reports:
>
> File Size with Heiko's patch: 244k
> U-Boot works.
>
> File size with Albert's V2 patch: 255k
> U-Boot stops at:
> U-Boot 2010.09-00113-g3c5eeb8-dirty (Oct 05 2010 - 10:04:25)
>
> CPU: AT91SAM9XE
> Crystal frequency: 18.432 MHz
> CPU clock : 198.656 MHz
> Master clock : 99.328 MHz
> I2C: ready
> DRAM: 64 MiB
> <dead here>
>
> File size with Wolfgang's patch: 244k (strange!)
<brown paper bag>
Sorry, I did not look close enough to see that Wolfgang's
Patch does not add anything for ARM926!
</brown paper bag>
Remains the fact that Albert's V2 dies after printing the DRAM -
that is probably during relocation :)
> I only added #define CONFIG_RELOC_FIXUP_WORKS to my board config
> (compared to the Heiko-version).
> Did I miss to change anything else.
Best Regards,
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:23 ` Reinhard Meyer
@ 2010-10-05 7:52 ` Reinhard Meyer
2010-10-05 8:33 ` Heiko Schocher
2010-10-05 10:20 ` Albert ARIBAUD
0 siblings, 2 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 7:52 UTC (permalink / raw)
To: u-boot
I _think_ the linker file needs a .align there:
(.data ends with a non-aligned address!)
Why do I happen to have all the luck when testing ;)
.data 0x21f37f54 0x0 drivers/spi/libspi.a(atmel_spi.o)
.data 0x21f37f54 0x0 drivers/rtc/librtc.a(at91sam9_rtt.o)
.data 0x21f37f54 0x30 drivers/rtc/librtc.a(date.o)
.data 0x21f37f84 0x4b drivers/usb/host/libusb_host.a(ohci-hcd.o)
.data 0x21f37fcf 0x0 drivers/usb/host/libusb_host.a(ohci-at91.o)
.data 0x21f37fcf 0x0 common/libcommon.a(memsize.o)
.data 0x21f37fcf 0x0 board/emk/top9000/libtop9000.a(spi.o)
.data 0x21f37fcf 0x0 lib/libgeneric.a(strmhz.o)
.data 0x21f37fcf 0x0 arch/arm/cpu/arm926ejs/libarm926ejs.a(cpu.o)
.data 0x21f37fcf 0x0 arch/arm/lib/libarm.a(cache-cp15.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/u-boot/arch/arm/lib/eabi_compat.o
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_udivsi3.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_divsi3.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_lshrdi3.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_ashrdi3.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_ashldi3.o)
.data 0x21f37fcf 0x0 /home/reinhard/embedded/buildroot-v23434/build_arm/staging_dir/usr/bin-ccache/../lib/gcc/arm-linux-uclibcgnueabi/4.2.4/libgcc.a(_dvmd_lnx.o)
0x21f37fcf __datarel_start = .
*(.data.rel)
0x21f37fcf __datarelrolocal_start = .
*(.data.rel.ro.local)
0x21f37fcf __datarellocal_start = .
*(.data.rel.local)
0x21f37fcf __datarelro_start = .
*(.data.rel.ro)
.dynamic 0x21f37fd0 0x80
.dynamic 0x21f37fd0 0x80 arch/arm/cpu/arm926ejs/start.o
0x21f37fd0 _DYNAMIC
.got.plt 0x21f38050 0xc
.got.plt 0x21f38050 0xc arch/arm/cpu/arm926ejs/start.o
0x21f38050 _GLOBAL_OFFSET_TABLE_
0x21f3805c . = ALIGN (0x4)
0x21f3805c __rel_dyn_start = .
.rel.dyn 0x21f3805c 0x6470
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:52 ` Reinhard Meyer
@ 2010-10-05 8:33 ` Heiko Schocher
2010-10-05 8:41 ` Albert ARIBAUD
2010-10-05 10:20 ` Albert ARIBAUD
1 sibling, 1 reply; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 8:33 UTC (permalink / raw)
To: u-boot
Hello Reinhard,
Reinhard Meyer wrote:
> I _think_ the linker file needs a .align there:
>
> (.data ends with a non-aligned address!)
actually trying on the tx25 board, and I see a hang after
the dram output too:
DRAM: 32 MiB
I inserted a breakpoint in start.S at clear_bss, never reached...
Maybe the fixloop
start.S:
[...]
fixnext:
str r1, [r0]
add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
ble fixloop
#endif
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
clear_bss:
never reaches a end ... but just debugging it ...
register dump in fixloop:
TX25>ti;r
Core number : 0
Core state : debug mode (ARM)
Debug entry cause : Single Step
Current PC : 0x812000d8
Current CPSR : 0x800000d3 (Supervisor)
GPR00: 81fbe020 81fbe1a0 81224364 812285cc
GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000
GPR08: 00000017 00dbe000 812285cc 00000000
GPR12: 00000000 81ebdf88 812006f4 812000d8
PC : 812000d8 CPSR: 800000d3
TX25>
r2 and r3 are a multiple of 8, so this must end, but never
see it ending ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 8:33 ` Heiko Schocher
@ 2010-10-05 8:41 ` Albert ARIBAUD
2010-10-05 9:00 ` Heiko Schocher
0 siblings, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 8:41 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 10:33, Heiko Schocher a ?crit :
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> I _think_ the linker file needs a .align there:
>>
>> (.data ends with a non-aligned address!)
>
> actually trying on the tx25 board, and I see a hang after
> the dram output too:
>
> DRAM: 32 MiB
>
> I inserted a breakpoint in start.S at clear_bss, never reached...
>
> Maybe the fixloop
>
> start.S:
> [...]
> fixnext:
> str r1, [r0]
> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> cmp r2, r3
> ble fixloop
> #endif
> #endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
>
> clear_bss:
>
> never reaches a end ... but just debugging it ...
>
> register dump in fixloop:
>
> TX25>ti;r
> Core number : 0
> Core state : debug mode (ARM)
> Debug entry cause : Single Step
> Current PC : 0x812000d8
> Current CPSR : 0x800000d3 (Supervisor)
> GPR00: 81fbe020 81fbe1a0 81224364 812285cc
> GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000
> GPR08: 00000017 00dbe000 812285cc 00000000
> GPR12: 00000000 81ebdf88 812006f4 812000d8
> PC : 812000d8 CPSR: 800000d3
> TX25>
>
> r2 and r3 are a multiple of 8, so this must end, but never
> see it ending ...
Ihe loop exit test is a ble, not a bne, so even if r2 or r3 were not
properly aligned, this should still exit eventually.
A reason why it would not, though, is if the loop trashes the code in
RAM. That can happen if e.g. TEXT_BASE is wrong (my bad). In two hour's
time I will build (not test) for tx25 and then do a quick check on the
content of .rel.dyn and .dynsym in the resulting u-boot.
> bye,
> Heiko
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 8:41 ` Albert ARIBAUD
@ 2010-10-05 9:00 ` Heiko Schocher
2010-10-05 9:10 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 9:00 UTC (permalink / raw)
To: u-boot
Hello Albert,
Albert ARIBAUD wrote:
> Le 05/10/2010 10:33, Heiko Schocher a ?crit :
>> Hello Reinhard,
>>
>> Reinhard Meyer wrote:
>>> I _think_ the linker file needs a .align there:
>>>
>>> (.data ends with a non-aligned address!)
>>
>> actually trying on the tx25 board, and I see a hang after
>> the dram output too:
>>
>> DRAM: 32 MiB
>>
>> I inserted a breakpoint in start.S at clear_bss, never reached...
>>
>> Maybe the fixloop
>>
>> start.S:
>> [...]
>> fixnext:
>> str r1, [r0]
>> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
>> cmp r2, r3
>> ble fixloop
>> #endif
>> #endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
>>
>> clear_bss:
>>
>> never reaches a end ... but just debugging it ...
>>
>> register dump in fixloop:
>>
>> TX25>ti;r
>> Core number : 0
>> Core state : debug mode (ARM)
>> Debug entry cause : Single Step
>> Current PC : 0x812000d8
>> Current CPSR : 0x800000d3 (Supervisor)
>> GPR00: 81fbe020 81fbe1a0 81224364 812285cc
>> GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000
>> GPR08: 00000017 00dbe000 812285cc 00000000
>> GPR12: 00000000 81ebdf88 812006f4 812000d8
>> PC : 812000d8 CPSR: 800000d3
>> TX25>
>>
>> r2 and r3 are a multiple of 8, so this must end, but never
>> see it ending ...
>
> Ihe loop exit test is a ble, not a bne, so even if r2 or r3 were not
> properly aligned, this should still exit eventually.
But in my case this looks good.
> A reason why it would not, though, is if the loop trashes the code in
> RAM. That can happen if e.g. TEXT_BASE is wrong (my bad). In two hour's
> time I will build (not test) for tx25 and then do a quick check on the
> content of .rel.dyn and .dynsym in the resulting u-boot.
TX25>ti;r
Core number : 0
Core state : debug mode (ARM)
Debug entry cause : Single Step
Current PC : 0x812000e4
Current CPSR : 0x200000d3 (Supervisor)
GPR00: 81fbe020 00000017 8122435c 812285cc
GPR04: 81ebdf88 81ebdf8c 81fe6ac8 81fbe000
GPR08: 80000f80 00dbe000 812285cc 00000000
GPR12: 00000000 81ebdf88 812006f4 812000e4
PC : 812000e4 CPSR: 200000d3
Looking at the last entry @812285cc.
TX25>md 0x812285cc
812285cc : 00000000 00000000 00000000 00000000 ................
812285dc : 00000000 81200000 00000000 00010003 ...... .........
812285ec : 0000004f 8122435c 00000000 fff10010 O...\C".........
812285fc : 00000092 812286bc 00000000 fff10010 ......".........
8122860c : 00000028 812242d0 00000000 00060010 (....B".........
now looking what did fixloop with this:
fixloop:
ldr r0, [r2] /* r0 <- location to fix up, IN FLASH! */
add r0, r9 /* r0 <- location to fix up in RAM */
so after this r0 would be 0x00dbe000
so, later in code:
fixrel:
/* relative fix: increase location by offset */
ldr r1, [r0]
add r1, r1, r9
fixnext:
str r1, [r0]
this stores @00dbe000 will fail ... no idea why I have here @812285cc
just 00000000
Hah... with this patch it works:
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 5a7ae7e..cf3a59f 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -266,7 +266,7 @@ fixnext:
str r1, [r0]
add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
- ble fixloop
+ bne fixloop
#endif
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
@@ -297,8 +297,9 @@ clbss_l:str r2, [r0] /* clear loop... */
ldr r0, _nand_boot_ofs
adr r1, _start
add pc, r0, r1
-_nand_boot_ofs
- : .word nand_boot - _start
+
+_nand_boot_ofs:
+ .word nand_boot - _start
#else
ldr r0, _board_init_r_ofs
adr r1, _start
Ok, we could not ignore the last entry ...
Hmm.. any idea why I have such a buggy last entry in __rel_dyn_start ?
(I have to admit, that I didn;t tried to start from nand with nand_spl
code, I just load u-boot with the bdi in ram (such as the nand_spl code
this did ... now I have to try to boot from nand)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:00 ` Heiko Schocher
@ 2010-10-05 9:10 ` Reinhard Meyer
2010-10-05 9:15 ` Heiko Schocher
0 siblings, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 9:10 UTC (permalink / raw)
To: u-boot
Dear ALL,
> Hah... with this patch it works:
>
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index 5a7ae7e..cf3a59f 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -266,7 +266,7 @@ fixnext:
> str r1, [r0]
> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> cmp r2, r3
> - ble fixloop
> + bne fixloop
Indeed, with this single change (not using NAND options here)
it works, too, and data gets properly relocated, since "sf probe"
works, too (it does not do so with Heiko's relocation)
Hurray!!!!
U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 12:25:06)
U-Boot code: 21F00000 -> 21F3EBA0 BSS: -> 21F80100
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock : 198.656 MHz
Master clock : 99.328 MHz
I2C: ready
monitor len: 00080100
ramsize: 04000000
Top of RAM usable for U-Boot at: 24000000
Reserving 512k for U-Boot at: 23f7f000
Reserving 143k for malloc() at: 23f5b100
Reserving 24 Bytes for Board Info at: 23f5b0e8
Reserving 136 Bytes for Global Data at: 23f5b060
New Stack Pointer is: 23f5b058
RAM Configuration:
Bank #0: 20000000 64 MiB
relocation Offset is: 0207f000
calling relocate_code(addr_sp=23f5b058, id=23f5b060, addr=23f7f000)
monitor flash len: 0003EBA0
Now running in RAM - U-Boot at: 23f7f000
FLASH: 512 KiB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
MMC: mci: 0
Net: macb0, enc1.0, enc1.1, enc1.2
Reset Ethernet PHY
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Press SPACE to abort autoboot in 1 seconds
TOP9000> sf probe 0:0
SF: Detected FM25H20 with size 256 KiB
256 KiB FM25H20 at 0:0 is now current device
Many thanks!!!!
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:10 ` Reinhard Meyer
@ 2010-10-05 9:15 ` Heiko Schocher
2010-10-05 9:19 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 9:15 UTC (permalink / raw)
To: u-boot
Hello Reinhard,
Reinhard Meyer wrote:
> Dear ALL,
>> Hah... with this patch it works:
>>
>> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
>> index 5a7ae7e..cf3a59f 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> @@ -266,7 +266,7 @@ fixnext:
>> str r1, [r0]
>> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
>> cmp r2, r3
>> - ble fixloop
>> + bne fixloop
>
> Indeed, with this single change (not using NAND options here)
> it works, too, and data gets properly relocated, since "sf probe"
> works, too (it does not do so with Heiko's relocation)
Great!
> Hurray!!!!
... but I don;t know if this is the right change! Better would
be to know, why the last entry in __rel_dyn_start is filled with
00000000 ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:15 ` Heiko Schocher
@ 2010-10-05 9:19 ` Reinhard Meyer
2010-10-05 9:29 ` Heiko Schocher
0 siblings, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 9:19 UTC (permalink / raw)
To: u-boot
Dear Heiko Schocher,
> ... but I don;t know if this is the right change! Better would
> be to know, why the last entry in __rel_dyn_start is filled with
> 00000000 ...
As an EOF marker, maybe?
Maybe the loop should be left by ble and a test for zero of an entry?
Umm "ble" seems wrong to me anyway:
start = first entry, end = address AFTER last entry,
so it should be "blt", or?
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:19 ` Reinhard Meyer
@ 2010-10-05 9:29 ` Heiko Schocher
2010-10-05 9:33 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 9:29 UTC (permalink / raw)
To: u-boot
Hello Reinhard,
Reinhard Meyer wrote:
> Dear Heiko Schocher,
>
>> ... but I don;t know if this is the right change! Better would
>> be to know, why the last entry in __rel_dyn_start is filled with
>> 00000000 ...
>
> As an EOF marker, maybe?
Hmm... don;t know, but I didn;t see this for example on the
magnesium board ...
> Maybe the loop should be left by ble and a test for zero of an entry?
Maybe yes.
> Umm "ble" seems wrong to me anyway:
Yep, as I said, it is just a fast fix ...
> start = first entry, end = address AFTER last entry,
> so it should be "blt", or?
Yep. But I think, ble is right ... we should know, why this
entry is filled with 00000000
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:29 ` Heiko Schocher
@ 2010-10-05 9:33 ` Reinhard Meyer
2010-10-05 9:39 ` Reinhard Meyer
2010-10-05 10:33 ` Albert ARIBAUD
0 siblings, 2 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 9:33 UTC (permalink / raw)
To: u-boot
Dear Heiko Schocher,
>> start = first entry, end = address AFTER last entry,
>> so it should be "blt", or?
>
> Yep. But I think, ble is right ... we should know, why this
> entry is filled with 00000000
No, we want a loop through all entries:
start: 1st entry
2nd entry
...
last entry
end:
so it must be:
for (p = start; p < end; p += 8)
work;
and not
for (p = start; p <= end; p += 8)
work;
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:33 ` Reinhard Meyer
@ 2010-10-05 9:39 ` Reinhard Meyer
2010-10-05 10:11 ` Albert ARIBAUD
2010-10-05 10:33 ` Albert ARIBAUD
1 sibling, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 9:39 UTC (permalink / raw)
To: u-boot
> for (p = start; p < end; p += 8)
> work;
> and not
Give me some time, and I will complete this loop to do
relocation in "C".
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:39 ` Reinhard Meyer
@ 2010-10-05 10:11 ` Albert ARIBAUD
2010-10-05 10:36 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 10:11 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 11:39, Reinhard Meyer a ?crit :
>> for (p = start; p< end; p += 8)
>> work;
>> and not
>
> Give me some time, and I will complete this loop to do
> relocation in "C".
>
> Reinhard
Be careful, though, that you need a way to obtain the 'source' address
of the .rel.dyn start and end and of the .dynsym start, plus the offset
from 'source' to 'target'; these may not be easy to compute in C
I think the right balance might be to have an ASM framework to prepare
these four values and pass them to the C relocation routine.
Note that you may also have to make sure the routine itself is
insensitive to relocation too.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 10:11 ` Albert ARIBAUD
@ 2010-10-05 10:36 ` Reinhard Meyer
2010-10-05 10:49 ` Graeme Russ
0 siblings, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 10:36 UTC (permalink / raw)
To: u-boot
Albert ARIBAUD schrieb:
> Le 05/10/2010 11:39, Reinhard Meyer a ?crit :
>>> for (p = start; p< end; p += 8)
>>> work;
>>> and not
>>
>> Give me some time, and I will complete this loop to do
>> relocation in "C".
Almost finished with it :)
>> Reinhard
>
> Be careful, though, that you need a way to obtain the 'source' address
> of the .rel.dyn start and end and of the .dynsym start, plus the offset
> from 'source' to 'target'; these may not be easy to compute in C
No problem, the statements
.globl _rel_dyn_start_ofs
_rel_dyn_start_ofs:
.word __rel_dyn_start - _start
.globl _rel_dyn_end_ofs
_rel_dyn_end_ofs:
.word __rel_dyn_end - _start
.globl _dynsym_start_ofs
_dynsym_start_ofs:
.word __dynsym_start - _start
get the values to "C".
>
> I think the right balance might be to have an ASM framework to prepare
> these four values and pass them to the C relocation routine.
see above.
>
> Note that you may also have to make sure the routine itself is
> insensitive to relocation too.
Why? It runs while code is at the right TEXT_BASE. If that shall
be weakened, I am not sure it can be done in "C".
I am troubled by your following statements in assembly:
Note: my u-boot has only one type "2" relocation:
patch 21f151fc : 00000302
fixabs:
/* absolute fix: set location to (offset) symbol value */
r1=00000302
mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
r1=00000030
add r1, r10, r1 /* r1 <- address of symbol in table */
r1=00000030+_dynsym_start_ofs
ldr r1, [r1, #4] /* r1 <- symbol value */
r1=r1[4]
add r1, r9 /* r1 <- relocated sym addr */
b fixnext
Is an entry in _dynsym really 16 bytes long?
Best Regards,
Reinhard
PS: I am about there:
#ifdef CONFIG_USE_C_RELOCATION
/* TODO: check for identical source and destination */
/* TODO: check for overlapping */
/* copy image, including initialized data */
debug ("memcpy(%08lx,%08lx,%ld)\n",
addr, _TEXT_BASE, _bss_start_ofs);
memcpy (addr, _TEXT_BASE, _bss_start_ofs);
/* now fix the code */
debug ("_dynsym_start_ofs=%08lx _rel_dyn_start_ofs=%08lx _rel_dyn_end_ofs=%08lx\n",
_dynsym_start_ofs, _rel_dyn_start_ofs, _rel_dyn_end_ofs);
for (dyn_ptr = (ulong *)(_TEXT_BASE + _rel_dyn_start_ofs);
dyn_ptr < (ulong *)(_TEXT_BASE + _rel_dyn_end_ofs);
dyn_ptr += 8) {
ulong *patchaddr = (ulong *) dyn_ptr[0] + addr;
debug ("patch %08lx : %08lx\n",
patchaddr, dyn_ptr[1]);
switch (dyn_ptr[1] & 0xff) {
case 23: /* rel fixup */
*patchaddr += addr;
break;
case 2: /* abs fixup */
break;
default: /* unhandled fixup */
break;
}
}
Beautifying comes later ;)
^ permalink raw reply [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 10:36 ` Reinhard Meyer
@ 2010-10-05 10:49 ` Graeme Russ
2010-10-05 11:01 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Graeme Russ @ 2010-10-05 10:49 UTC (permalink / raw)
To: u-boot
On 05/10/10 21:36, Reinhard Meyer wrote:
> Albert ARIBAUD schrieb:
>> Le 05/10/2010 11:39, Reinhard Meyer a ?crit :
>>>> for (p = start; p< end; p += 8)
>>>> work;
>>>> and not
>>>
>>> Give me some time, and I will complete this loop to do
>>> relocation in "C".
>
> Almost finished with it :)
>
>>> Reinhard
>>
>> Be careful, though, that you need a way to obtain the 'source' address
>> of the .rel.dyn start and end and of the .dynsym start, plus the offset
>> from 'source' to 'target'; these may not be easy to compute in C
>
> No problem, the statements
>
> .globl _rel_dyn_start_ofs
> _rel_dyn_start_ofs:
> .word __rel_dyn_start - _start
> .globl _rel_dyn_end_ofs
> _rel_dyn_end_ofs:
> .word __rel_dyn_end - _start
> .globl _dynsym_start_ofs
> _dynsym_start_ofs:
> .word __dynsym_start - _start
>
> get the values to "C".
Odd, is x86 different:
extern ulong _i386boot_rel_dyn_start;
extern ulong _i386boot_rel_dyn_end;
void board_init_f (ulong stack_limit)
{
...
Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&_i386boot_rel_dyn_start;
Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&_i386boot_rel_dyn_end;
...
>>
>> I think the right balance might be to have an ASM framework to prepare
>> these four values and pass them to the C relocation routine.
>
> see above.
>
>>
>> Note that you may also have to make sure the routine itself is
>> insensitive to relocation too.
>
> Why? It runs while code is at the right TEXT_BASE. If that shall
> be weakened, I am not sure it can be done in "C".
Provided you only use local variables (i.e. stored on the stack) the code
might be relocatable anyway (the jump from asm to C will hopefully be
relative). If you run the code at another address you will need to
calculate the load offset and adjust rel_dyn_start and rel_dyn_end
accordingly (see recent x86 patch series)
[snip]
> Is an entry in _dynsym really 16 bytes long?
Yes, it is an Elf32_Rel struct - see include/elf.h in the U-Boot tree
typedef struct
{
Elf32_Addr r_offset; /* offset of relocation */
Elf32_Word r_info; /* symbol table index and type */
} Elf32_Rel;
> PS: I am about there:
>
> #ifdef CONFIG_USE_C_RELOCATION
> /* TODO: check for identical source and destination */
> /* TODO: check for overlapping */
> /* copy image, including initialized data */
> debug ("memcpy(%08lx,%08lx,%ld)\n",
> addr, _TEXT_BASE, _bss_start_ofs);
> memcpy (addr, _TEXT_BASE, _bss_start_ofs);
> /* now fix the code */
> debug ("_dynsym_start_ofs=%08lx _rel_dyn_start_ofs=%08lx _rel_dyn_end_ofs=%08lx\n",
> _dynsym_start_ofs, _rel_dyn_start_ofs, _rel_dyn_end_ofs);
> for (dyn_ptr = (ulong *)(_TEXT_BASE + _rel_dyn_start_ofs);
> dyn_ptr < (ulong *)(_TEXT_BASE + _rel_dyn_end_ofs);
> dyn_ptr += 8) {
I too use a for loop, but now use a do loop:
extern ulong __rel_dyn_start;
extern ulong __rel_dyn_end;
void board_init_f (ulong gdp)
{
...
void *rel_dyn_start = &__rel_dyn_start;
void *rel_dyn_end = &__rel_dyn_end;
...
/* Perform relocation adjustments */
re_src = (Elf32_Rel *)(rel_dyn_start + ((gd_t *)gdp)->load_off);
re_end = (Elf32_Rel *)(rel_dyn_end + ((gd_t *)gdp)->load_off);
do {
if (re_src->r_offset >= TEXT_BASE)
if (*(Elf32_Addr *)(re_src->r_offset - rel_offset) >= TEXT_BASE)
*(Elf32_Addr *)(re_src->r_offset - rel_offset) -= rel_offset;
} while (re_src++ < re_end);
I pass in a pointer to the global data structure which has had load_off
(the difference between TEXT_BASE and the load address) pre-calculated in asm
> ulong *patchaddr = (ulong *) dyn_ptr[0] + addr;
> debug ("patch %08lx : %08lx\n",
> patchaddr, dyn_ptr[1]);
> switch (dyn_ptr[1] & 0xff) {
Use Elf32_Rel
> case 23: /* rel fixup */
> *patchaddr += addr;
> break;
> case 2: /* abs fixup */
> break;
> default: /* unhandled fixup */
> break;
> }
> }
Regards,
Graeme
^ permalink raw reply [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 10:49 ` Graeme Russ
@ 2010-10-05 11:01 ` Reinhard Meyer
2010-10-05 11:18 ` Albert ARIBAUD
0 siblings, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 11:01 UTC (permalink / raw)
To: u-boot
Dear Graeme Russ,
>> .globl _rel_dyn_start_ofs
>> _rel_dyn_start_ofs:
>> .word __rel_dyn_start - _start
>> .globl _rel_dyn_end_ofs
>> _rel_dyn_end_ofs:
>> .word __rel_dyn_end - _start
>> .globl _dynsym_start_ofs
>> _dynsym_start_ofs:
>> .word __dynsym_start - _start
>>
>> get the values to "C".
>
> Odd, is x86 different:
>
> extern ulong _i386boot_rel_dyn_start;
> extern ulong _i386boot_rel_dyn_end;
>
> void board_init_f (ulong stack_limit)
> {
> ...
> Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&_i386boot_rel_dyn_start;
> Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&_i386boot_rel_dyn_end;
> ...
It can be done that way, too! But above assembly code provides
relative offsets already, in "C" it would turn a bit uglier ;)
(TODO later)
> Provided you only use local variables (i.e. stored on the stack) the code
> might be relocatable anyway (the jump from asm to C will hopefully be
> relative). If you run the code at another address you will need to
> calculate the load offset and adjust rel_dyn_start and rel_dyn_end
> accordingly (see recent x86 patch series)
Probably. That adjustment is inherent, since offsets are used!
>
> [snip]
>
>> Is an entry in _dynsym really 16 bytes long?
My Questions was that Albert shifts "r_info" 4 times (= divide by 16)
to index into the _dynsym table, implying dynsym has 16 byte entries.
I see that it has - in elf.h. OK
>
> Yes, it is an Elf32_Rel struct - see include/elf.h in the U-Boot tree
>
> typedef struct
> {
> Elf32_Addr r_offset; /* offset of relocation */
> Elf32_Word r_info; /* symbol table index and type */
> } Elf32_Rel;
I will use the struct now.
> /* Perform relocation adjustments */
> re_src = (Elf32_Rel *)(rel_dyn_start + ((gd_t *)gdp)->load_off);
> re_end = (Elf32_Rel *)(rel_dyn_end + ((gd_t *)gdp)->load_off);
Using relative offsets the loop is a bit different...
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 11:01 ` Reinhard Meyer
@ 2010-10-05 11:18 ` Albert ARIBAUD
0 siblings, 0 replies; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 11:18 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 13:01, Reinhard Meyer a ?crit :
> Dear Graeme Russ,
>>> .globl _rel_dyn_start_ofs
>>> _rel_dyn_start_ofs:
>>> .word __rel_dyn_start - _start
>>> .globl _rel_dyn_end_ofs
>>> _rel_dyn_end_ofs:
>>> .word __rel_dyn_end - _start
>>> .globl _dynsym_start_ofs
>>> _dynsym_start_ofs:
>>> .word __dynsym_start - _start
>>>
>>> get the values to "C".
>>
>> Odd, is x86 different:
>>
>> extern ulong _i386boot_rel_dyn_start;
>> extern ulong _i386boot_rel_dyn_end;
>>
>> void board_init_f (ulong stack_limit)
>> {
>> ...
>> Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&_i386boot_rel_dyn_start;
>> Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&_i386boot_rel_dyn_end;
>> ...
>
> It can be done that way, too! But above assembly code provides
> relative offsets already, in "C" it would turn a bit uglier ;)
> (TODO later)
For the _rel_dyn_* and _dyn_sym* literals, offsets are mandatory,
because their actual value would be always 0 at link time, and only
become correct after relocation, which creates a catch-22, since you
need these values for relocation.
Defining their value as relative to _start instead does not change their
relocation type, but it makes their link-time value already correct, and
thus makes relocation possible.
(/me thinks an update to doc/README.arm-relocation is in order)
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:33 ` Reinhard Meyer
2010-10-05 9:39 ` Reinhard Meyer
@ 2010-10-05 10:33 ` Albert ARIBAUD
2010-10-05 10:40 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 10:33 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 11:33, Reinhard Meyer a ?crit :
> Dear Heiko Schocher,
>>> start = first entry, end = address AFTER last entry,
>>> so it should be "blt", or?
>>
>> Yep. But I think, ble is right ... we should know, why this
>> entry is filled with 00000000
>
> No, we want a loop through all entries:
>
> start: 1st entry
> 2nd entry
> ...
> last entry
> end:
>
> so it must be:
>
> for (p = start; p< end; p += 8)
> work;
> and not
>
> for (p = start; p<= end; p += 8)
> work;
>
> Reinhard
Indeed, hence my post on 'blo' vs 'ble'. Note that the same erroneous
'ble' was used throughout start.S, for instance in the source-to-target
copy loop and in the bss clear loop, which means those two had a latent
bug since long ago.
It seems like fixing this 'ble' bug and adding Graeme's DISCARDs gives
us a pretty good candidate for actual patch submission. If no one finds
a serious blocker, I'll submit a patch set tonight french timezone.
As for splitting the thing into individual patches, I would like some
advice. Obviously a first patch could be the bugfix to the ble/blo
issuein existing start.S, and the last patch shall be the change to
edminiv2.
My problem is with the essential part: changing only the compile and
link options in arm, or changing only the start.S and u-boot.lds in
arm926, produces a nonworking, non-buildable, tree. So it would seem
that all of this should go in a single patch in order to remain bisectable.
However, changing arm without changing other cpus than arm926 would
break build on these, so a bisectable change would require a single
patch to arm and all its cpus. Seems a bit big for me.
Wolfgang, Heiko, your advice is sought.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 10:33 ` Albert ARIBAUD
@ 2010-10-05 10:40 ` Wolfgang Denk
2010-10-05 11:10 ` Albert ARIBAUD
0 siblings, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 10:40 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <4CAAFEDD.4060005@free.fr> you wrote:
>
> As for splitting the thing into individual patches, I would like some
> advice. Obviously a first patch could be the bugfix to the ble/blo
> issuein existing start.S, and the last patch shall be the change to
> edminiv2.
Correct.
> My problem is with the essential part: changing only the compile and
> link options in arm, or changing only the start.S and u-boot.lds in
> arm926, produces a nonworking, non-buildable, tree. So it would seem
> that all of this should go in a single patch in order to remain bisectable.
>
> However, changing arm without changing other cpus than arm926 would
> break build on these, so a bisectable change would require a single
> patch to arm and all its cpus. Seems a bit big for me.
Agreed.
Well, let's split development and testing from the final committing.
I suggest you provide what you can in single patch, and we put this
in a separate branch of the git repository. Heiko and me may then add
support for the precessors we used for testing, i. e. arm1136 and
armv7. Hopefully others will pick up from there for the remaining
processors.
When committing to mainline (or to u-boot-arm) I can sqash all the
processor related commits into a single one.
Umm... is my understanding correct that we can drop the whole
CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every revolutionary idea - in science, politics, art, or whatever -
evokes three stages of reaction in a hearer:
1. It is completely impossible - don't waste my time.
2. It is possible, but it is not worth doing.
3. I said it was a good idea all along.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 10:40 ` Wolfgang Denk
@ 2010-10-05 11:10 ` Albert ARIBAUD
2010-10-05 11:17 ` Reinhard Meyer
2010-10-05 11:43 ` Wolfgang Denk
0 siblings, 2 replies; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 11:10 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 12:40, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CAAFEDD.4060005@free.fr> you wrote:
>>
>> As for splitting the thing into individual patches, I would like some
>> advice. Obviously a first patch could be the bugfix to the ble/blo
>> issuein existing start.S, and the last patch shall be the change to
>> edminiv2.
>
> Correct.
>
>> My problem is with the essential part: changing only the compile and
>> link options in arm, or changing only the start.S and u-boot.lds in
>> arm926, produces a nonworking, non-buildable, tree. So it would seem
>> that all of this should go in a single patch in order to remain bisectable.
>>
>> However, changing arm without changing other cpus than arm926 would
>> break build on these, so a bisectable change would require a single
>> patch to arm and all its cpus. Seems a bit big for me.
>
> Agreed.
>
> Well, let's split development and testing from the final committing.
>
> I suggest you provide what you can in single patch, and we put this
> in a separate branch of the git repository. Heiko and me may then add
> support for the precessors we used for testing, i. e. arm1136 and
> armv7. Hopefully others will pick up from there for the remaining
> processors.
>
> When committing to mainline (or to u-boot-arm) I can sqash all the
> processor related commits into a single one.
Let me recap to make sure I got things right.
Rather than submitting a patch set for mainline, I'll submit a single
ELF patch that you will put on a specific branch (let's call it
elf_reloc here for the sake of clarity)
In order to keep elf_reloc devoted to elf relocation and make it simpler
for you to squash it back to main, elf_reloc should receive only changes
which are imperative for elf relocation support.
This means the ble bugfix (changing existing ble's into blo's in all ARM
start.S files) will be a separate patch to main, coming RSN.
Also, I won't submit changes to edminiv2 on elf_reloc either; that'll
come on main once elf_reloc is squashed back onto it.
> Umm... is my understanding correct that we can drop the whole
> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
I believe we're just changing the relocation solution, but we're not
changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 11:10 ` Albert ARIBAUD
@ 2010-10-05 11:17 ` Reinhard Meyer
2010-10-05 11:46 ` Albert ARIBAUD
2010-10-05 11:43 ` Wolfgang Denk
1 sibling, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 11:17 UTC (permalink / raw)
To: u-boot
Dear All ;)
>> Umm... is my understanding correct that we can drop the whole
>> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
>
> I believe we're just changing the relocation solution, but we're not
> changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
We should not forget that right now, the "ELF" method uses 8 byte entries
to relocate, compared to 4 byte entries with the "GOT" method. We
should not proceed too fast here, the "thought about" tool to squeeze down
the relocation information should not be completely forgotten...
Otherwise even more boards would need to change their mtd partitioning ;)
And I am not too happy if I cannot downgrade to the AT91SAM9XE256 anymore
(256K NOR) if the 512K version proves difficult to obtain ;)
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 11:17 ` Reinhard Meyer
@ 2010-10-05 11:46 ` Albert ARIBAUD
2010-10-05 13:18 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 11:46 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 13:17, Reinhard Meyer a ?crit :
> Dear All ;)
>>> Umm... is my understanding correct that we can drop the whole
>>> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
>>
>> I believe we're just changing the relocation solution, but we're not
>> changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
>
> We should not forget that right now, the "ELF" method uses 8 byte entries
> to relocate, compared to 4 byte entries with the "GOT" method. We
> should not proceed too fast here, the "thought about" tool to squeeze down
> the relocation information should not be completely forgotten...
>
> Otherwise even more boards would need to change their mtd partitioning ;)
>
> And I am not too happy if I cannot downgrade to the AT91SAM9XE256 anymore
> (256K NOR) if the 512K version proves difficult to obtain ;)
>
> Reinhard
I still think a configuration option to choose between relocation
formats would be useful. It could offer:
- pure ELF format (8 bytes per relocation plus .dynsym)
... already there, and then to be done:
- unified 32-bit format (half the size of pure ELF)
- unified 16-bit delta format (a fourth of the size of pure ELF)
Note these would probably be arch-specific; but maybe not.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 11:46 ` Albert ARIBAUD
@ 2010-10-05 13:18 ` Reinhard Meyer
2010-10-05 13:24 ` Graeme Russ
2010-10-05 13:36 ` Albert ARIBAUD
0 siblings, 2 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 13:18 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
> Le 05/10/2010 13:17, Reinhard Meyer a ?crit :
>> Dear All ;)
>>>> Umm... is my understanding correct that we can drop the whole
>>>> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
>>>
>>> I believe we're just changing the relocation solution, but we're not
>>> changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
>>
>> We should not forget that right now, the "ELF" method uses 8 byte entries
>> to relocate, compared to 4 byte entries with the "GOT" method. We
>> should not proceed too fast here, the "thought about" tool to squeeze
>> down
>> the relocation information should not be completely forgotten...
>>
>> Otherwise even more boards would need to change their mtd partitioning ;)
>>
>> And I am not too happy if I cannot downgrade to the AT91SAM9XE256 anymore
>> (256K NOR) if the 512K version proves difficult to obtain ;)
>>
>> Reinhard
>
> I still think a configuration option to choose between relocation
> formats would be useful. It could offer:
>
> - pure ELF format (8 bytes per relocation plus .dynsym)
>
> ... already there, and then to be done:
>
> - unified 32-bit format (half the size of pure ELF)
>
> - unified 16-bit delta format (a fourth of the size of pure ELF)
Even an 8-bit delta format is possible:
use the value of 0x00 to skip forward 256 addresses, other values to patch..
Assuming that all relocations must be on a 32 bit boundary, the delta values
could even be multiplied by 4 :)
Best Regards,
Reinhard
PS: I finished the "C" relocation, but it does not work :(
having problems with setting the stack or calling of board_init_r(),
I am not sure. Because of otther work I cannot continue there right now.
If you want to look at it, I can make a patch.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 13:18 ` Reinhard Meyer
@ 2010-10-05 13:24 ` Graeme Russ
2010-10-05 13:36 ` Albert ARIBAUD
1 sibling, 0 replies; 42+ messages in thread
From: Graeme Russ @ 2010-10-05 13:24 UTC (permalink / raw)
To: u-boot
On 06/10/10 00:18, Reinhard Meyer wrote:
> Dear Albert ARIBAUD,
[snip]
> PS: I finished the "C" relocation, but it does not work :(
> having problems with setting the stack or calling of board_init_r(),
> I am not sure. Because of otther work I cannot continue there right now.
> If you want to look at it, I can make a patch.
>
Please do - I'll compare it to my latest x86 implementation (but that will
have to wait, its midnight, time for bed ;)
Regards,
Graeme
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 13:18 ` Reinhard Meyer
2010-10-05 13:24 ` Graeme Russ
@ 2010-10-05 13:36 ` Albert ARIBAUD
2010-10-05 14:06 ` Reinhard Meyer
1 sibling, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 13:36 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 15:18, Reinhard Meyer a ?crit :
> Dear Albert ARIBAUD,
>> Le 05/10/2010 13:17, Reinhard Meyer a ?crit :
>>> Dear All ;)
>>>>> Umm... is my understanding correct that we can drop the whole
>>>>> CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
>>>>
>>>> I believe we're just changing the relocation solution, but we're not
>>>> changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
>>>
>>> We should not forget that right now, the "ELF" method uses 8 byte entries
>>> to relocate, compared to 4 byte entries with the "GOT" method. We
>>> should not proceed too fast here, the "thought about" tool to squeeze
>>> down
>>> the relocation information should not be completely forgotten...
>>>
>>> Otherwise even more boards would need to change their mtd partitioning ;)
>>>
>>> And I am not too happy if I cannot downgrade to the AT91SAM9XE256 anymore
>>> (256K NOR) if the 512K version proves difficult to obtain ;)
>>>
>>> Reinhard
>>
>> I still think a configuration option to choose between relocation
>> formats would be useful. It could offer:
>>
>> - pure ELF format (8 bytes per relocation plus .dynsym)
>>
>> ... already there, and then to be done:
>>
>> - unified 32-bit format (half the size of pure ELF)
>>
>> - unified 16-bit delta format (a fourth of the size of pure ELF)
>
> Even an 8-bit delta format is possible:
> use the value of 0x00 to skip forward 256 addresses, other values to patch..
> Assuming that all relocations must be on a 32 bit boundary, the delta values
> could even be multiplied by 4 :)
i can see ASN.1-style variable-length integer encoding creeping around,
just waiting to be invoked thrice. :)
> Best Regards,
> Reinhard
>
> PS: I finished the "C" relocation, but it does not work :(
> having problems with setting the stack or calling of board_init_r(),
> I am not sure. Because of otther work I cannot continue there right now.
> If you want to look at it, I can make a patch.
Please do !
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 13:36 ` Albert ARIBAUD
@ 2010-10-05 14:06 ` Reinhard Meyer
0 siblings, 0 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 14:06 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
>>> - pure ELF format (8 bytes per relocation plus .dynsym)
>>>
>>> ... already there, and then to be done:
>>>
>>> - unified 32-bit format (half the size of pure ELF)
>>>
>>> - unified 16-bit delta format (a fourth of the size of pure ELF)
>>
>> Even an 8-bit delta format is possible:
>> use the value of 0x00 to skip forward 256 addresses, other values to
>> patch..
>> Assuming that all relocations must be on a 32 bit boundary, the delta
>> values
>> could even be multiplied by 4 :)
>
> i can see ASN.1-style variable-length integer encoding creeping around,
> just waiting to be invoked thrice. :)
Hmm, maybe half bit 1/PI encryption?
Nah - we don't want the reloc algo to get larger than the u-boot
we want to relocate...
>> If you want to look at it, I can make a patch.
>
> Please do !
Is there under the nice subject "[PATCH] futile c relocation attempt" ;)
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 11:10 ` Albert ARIBAUD
2010-10-05 11:17 ` Reinhard Meyer
@ 2010-10-05 11:43 ` Wolfgang Denk
1 sibling, 0 replies; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 11:43 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <4CAB0793.4000300@free.fr> you wrote:
>
> Rather than submitting a patch set for mainline, I'll submit a single
> ELF patch that you will put on a specific branch (let's call it
> elf_reloc here for the sake of clarity)
Please submit 2 patches:
- ELF patch
- edminiv2 changes
> In order to keep elf_reloc devoted to elf relocation and make it simpler
> for you to squash it back to main, elf_reloc should receive only changes
> which are imperative for elf relocation support.
Right. Heiko and me will probably add fixes for armv7 and arm1136
(which later will be squashed into the ELF patch, like other patches
that need to be done for the remaining processors).
Heiko and me will also provide some patches for other boards, like
tx25, magnesium, qong, and beagle.
> This means the ble bugfix (changing existing ble's into blo's in all ARM
> start.S files) will be a separate patch to main, coming RSN.
Right.
> Also, I won't submit changes to edminiv2 on elf_reloc either; that'll
> come on main once elf_reloc is squashed back onto it.
No. Please submit it now. We can keep this in the elf_reloc branch. I
will just squash all "ELF patch" related commits before pulling into
mainline.
> > Umm... is my understanding correct that we can drop the whole
> > CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
>
> I believe we're just changing the relocation solution, but we're not
> changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
OK.
Thanks!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:52 ` Reinhard Meyer
2010-10-05 8:33 ` Heiko Schocher
@ 2010-10-05 10:20 ` Albert ARIBAUD
1 sibling, 0 replies; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 10:20 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 09:52, Reinhard Meyer a ?crit :
> I _think_ the linker file needs a .align there:
Hmm... Seems to me like there's no alignment problem. .data ends up not
a multiple of 4 bytes after ohci_hcd, but then subsequent .data input
sections are empty, and .dynmic is correctly aligned. Do I miss something?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:05 ` Reinhard Meyer
2010-10-05 7:23 ` Reinhard Meyer
@ 2010-10-05 8:27 ` Wolfgang Denk
2010-10-05 8:38 ` Reinhard Meyer
1 sibling, 1 reply; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 8:27 UTC (permalink / raw)
To: u-boot
Dear Reinhard Meyer,
In message <4CAACE47.5090105@emk-elektronik.de> you wrote:
>
> File size with Albert's V2 patch: 255k
> U-Boot stops at:
> U-Boot 2010.09-00113-g3c5eeb8-dirty (Oct 05 2010 - 10:04:25)
>
> CPU: AT91SAM9XE
> Crystal frequency: 18.432 MHz
> CPU clock : 198.656 MHz
> Master clock : 99.328 MHz
> I2C: ready
> DRAM: 64 MiB
> <dead here>
>
> File size with Wolfgang's patch: 244k (strange!)
Be careful! Both my and Heikos patches go _on_top_ of Albert's patch!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 8:27 ` Wolfgang Denk
@ 2010-10-05 8:38 ` Reinhard Meyer
2010-10-05 8:50 ` Albert ARIBAUD
0 siblings, 1 reply; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 8:38 UTC (permalink / raw)
To: u-boot
Dear Wolfgang Denk,
> Be careful! Both my and Heikos patches go _on_top_ of Albert's patch!
Just figured that out already:)
But for arm926 I don't need your patch, and Heikos' was adding
relocation fixup to env, which is not needed anymore, right?
It crashes during relocation, I am adding debug right now:
U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 11:46:07)
U-Boot code: 21F00000 -> 21F3EBA0 BSS: -> 21F80100
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock : 198.656 MHz
Master clock : 99.328 MHz
I2C: ready
monitor len: 00080100
ramsize: 04000000
Top of RAM usable for U-Boot at: 24000000
Reserving 512k for U-Boot at: 23f7f000
Reserving 143k for malloc() at: 23f5b100
Reserving 24 Bytes for Board Info at: 23f5b0e8
Reserving 136 Bytes for Global Data at: 23f5b060
New Stack Pointer is: 23f5b058
RAM Configuration:
Bank #0: 20000000 64 MiB
relocation Offset is: 0207f000
calling relocate_code(addr_sp=23f5b058, id=23f5b060, addr=23f7f000)
So far I cannot see any oddity in those numbers...
Do all other system boot from NOR? Mine boots from RAM, thats means
its loaded there by the initial boot into working SDRAM.
With Heikos' relocation that works since I fixed the last problem
yesterday. So its the change to Alberts' patch that breaks it.
Best Regards
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 8:38 ` Reinhard Meyer
@ 2010-10-05 8:50 ` Albert ARIBAUD
2010-10-05 8:59 ` Reinhard Meyer
0 siblings, 1 reply; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 8:50 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 10:38, Reinhard Meyer a ?crit :
> Dear Wolfgang Denk,
>> Be careful! Both my and Heikos patches go _on_top_ of Albert's patch!
>
> Just figured that out already:)
>
> But for arm926 I don't need your patch, and Heikos' was adding
> relocation fixup to env, which is not needed anymore, right?
>
> It crashes during relocation, I am adding debug right now:
>
> U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 11:46:07)
>
> U-Boot code: 21F00000 -> 21F3EBA0 BSS: -> 21F80100
> CPU: AT91SAM9XE
> Crystal frequency: 18.432 MHz
> CPU clock : 198.656 MHz
> Master clock : 99.328 MHz
> I2C: ready
> monitor len: 00080100
> ramsize: 04000000
> Top of RAM usable for U-Boot at: 24000000
> Reserving 512k for U-Boot at: 23f7f000
> Reserving 143k for malloc() at: 23f5b100
> Reserving 24 Bytes for Board Info at: 23f5b0e8
> Reserving 136 Bytes for Global Data at: 23f5b060
> New Stack Pointer is: 23f5b058
> RAM Configuration:
> Bank #0: 20000000 64 MiB
> relocation Offset is: 0207f000
> calling relocate_code(addr_sp=23f5b058, id=23f5b060, addr=23f7f000)
>
> So far I cannot see any oddity in those numbers...
>
> Do all other system boot from NOR? Mine boots from RAM, thats means
> its loaded there by the initial boot into working SDRAM.
> With Heikos' relocation that works since I fixed the last problem
> yesterday. So its the change to Alberts' patch that breaks it.
I'll try and build a RAM-based version for my board. Meanwhile, make
sure the IPL does not load u-boot in a location too near its final
destination, as this could result in u-boot overwriting itself at some
point -- I am not implying this is the case here; just don't tempt Fate.
> Best Regards
> Reinhard
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 8:50 ` Albert ARIBAUD
@ 2010-10-05 8:59 ` Reinhard Meyer
0 siblings, 0 replies; 42+ messages in thread
From: Reinhard Meyer @ 2010-10-05 8:59 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
>> U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 11:46:07)
>>
>> U-Boot code: 21F00000 -> 21F3EBA0 BSS: -> 21F80100
>> CPU: AT91SAM9XE
>> Crystal frequency: 18.432 MHz
>> CPU clock : 198.656 MHz
>> Master clock : 99.328 MHz
>> I2C: ready
>> monitor len: 00080100
>> ramsize: 04000000
>> Top of RAM usable for U-Boot at: 24000000
>> Reserving 512k for U-Boot at: 23f7f000
>> Reserving 143k for malloc() at: 23f5b100
>> Reserving 24 Bytes for Board Info at: 23f5b0e8
>> Reserving 136 Bytes for Global Data at: 23f5b060
>> New Stack Pointer is: 23f5b058
>> RAM Configuration:
>> Bank #0: 20000000 64 MiB
>> relocation Offset is: 0207f000
>> calling relocate_code(addr_sp=23f5b058, id=23f5b060, addr=23f7f000)
>>
>> So far I cannot see any oddity in those numbers...
>>
>> Do all other system boot from NOR? Mine boots from RAM, thats means
>> its loaded there by the initial boot into working SDRAM.
>> With Heikos' relocation that works since I fixed the last problem
>> yesterday. So its the change to Alberts' patch that breaks it.
>
> I'll try and build a RAM-based version for my board. Meanwhile, make
> sure the IPL does not load u-boot in a location too near its final
> destination, as this could result in u-boot overwriting itself at some
> point -- I am not implying this is the case here; just don't tempt Fate.
No,
TEXT_BASE=21f00000 destination is near 23f00000 (see above)
And.. with Heiko's relocation it works fine:)
May I send you my u-boot.map (privately, its too large for the list)
I see some strange entries under .got for example, maybe you can have
a glance at it?
Best Regards,
Reinhard
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:45 ` Wolfgang Denk
2010-10-05 7:05 ` Reinhard Meyer
@ 2010-10-05 7:07 ` Wolfgang Denk
1 sibling, 0 replies; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 7:07 UTC (permalink / raw)
To: u-boot
In message <20101005064516.AEA4C153A7E@gemini.denx.de> I wrote:
> Dear Albert Aribaud,
>
> In message <1286260287-1571-1-git-send-email-albert.aribaud@free.fr> you wrote:
> > HISTORY:
> >
> > V1 Initial patch
> > V2 Rebased on latest mainline master
> >
> > This patch is *not* a submission for master!
>
> With the following additional patches I got the code working on the
> Qong board (i.MX31 = arm1136):
Hm... note that I forgot to change TEXT_BASE to 0, i. e. I left it at
the original value of 0xa0000000
When I change it to 0, the board hangs (looping 0x00000008 ->
0x1fffffd4 -> 0x1fffffd8 -> 0x1fffffdc -> 0x00000008 ->).
Any idea what I might be missing?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have a very small mind and must live with it. -- Edsger Dijkstra
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:31 [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations Albert Aribaud
2010-10-05 6:45 ` Wolfgang Denk
@ 2010-10-05 7:40 ` Heiko Schocher
2010-10-05 8:32 ` Albert ARIBAUD
2010-10-05 8:02 ` Wolfgang Denk
` (2 subsequent siblings)
4 siblings, 1 reply; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 7:40 UTC (permalink / raw)
To: u-boot
Hello Albert,
Albert Aribaud wrote:
> HISTORY:
>
> V1 Initial patch
> V2 Rebased on latest mainline master
>
> This patch is *not* a submission for master!
>
> It is a proof of concept of ELF relocations for ARM, hastily done
> in a day's work time for people on the list to try and to comment.
> All comments are welcome, as several suggestions have been made
> today on the list that I did not have time to incorporate, such as
> rewriting the elf table fixup code in C.
>
> The basic idea of this patch is to replace the -fPIC compile-time
> option with the -pie link-time option. This removes the GOT but adds
> the .rel.dyn and .dynsym tables, which together allow fixing up code
> more completely than with -fPIC and the GOT; for instance, all pointers
> inside structures are fixed up with -pie, whereas they are not with GOT.
>
> Note that references to linker-file-generated symbols were also made
> relative to _start rather than absolute. This is not needed as such,
> but it will be useful when optimizing the relocation tables. Actually
> I should have separated this from the ELF relocation support per se.
>
> The edminiv2.h config file is there for reference only; this is the
> one I used for tests. Latest numbers are:
>
> With GOT relocs:
>
> text data bss dec hex filename .bin size
> 141376 4388 16640 162404 27a64 ./u-boot 145764
>
> With ELF relocs:
>
> text data bss dec hex filename .bin size
> 149677 3727 16636 170040 29838 ./u-boot 153408
>
> The size difference is essentially due to .rel.dyn not being optimal.
> As discussed, an added build step should allow reducing it by half and
> making ELF sizes roughly similar to GOT ones.
>
> Tests and comments not only welcome but also heartily called for.
Tested based on your patch on the magnesium board (ARM926ejs and
boots from NOR Flash). U-Boot works, with the following patch:
! I had to set TEXT_BASE to 0xc0000000 as u-boot starts from there,
a TEXT_BASE = 0 didn;t work for me!
diff --git a/board/logicpd/imx27lite/config.mk b/board/logicpd/imx27lite/config.mk
index 2f9c4e6..af1c82b 100644
--- a/board/logicpd/imx27lite/config.mk
+++ b/board/logicpd/imx27lite/config.mk
@@ -1 +1,4 @@
+# with relocation TEXT_BASE can be anything, and making it 0
+# makes relative and absolute relocation fixups interchangeable.
+#TEXT_BASE = 0
TEXT_BASE = 0xc0000000
diff --git a/include/configs/imx27lite-common.h b/include/configs/imx27lite-common.h
index 812e5f2..58f3c49 100644
--- a/include/configs/imx27lite-common.h
+++ b/include/configs/imx27lite-common.h
@@ -236,7 +236,8 @@
"mtdparts=" MTDPARTS_DEFAULT "\0" \
/* additions for new relocation code, must added to all boards */
-#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
+#undef CONFIG_SYS_ARM_WITHOUT_RELOC
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 - /* Fix this */ \
CONFIG_SYS_GBL_DATA_SIZE)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 7:40 ` Heiko Schocher
@ 2010-10-05 8:32 ` Albert ARIBAUD
0 siblings, 0 replies; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 8:32 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 09:40, Heiko Schocher a ?crit :
> Hello Albert,
>
> Albert Aribaud wrote:
>> HISTORY:
>>
>> V1 Initial patch
>> V2 Rebased on latest mainline master
>>
>> This patch is *not* a submission for master!
>>
>> It is a proof of concept of ELF relocations for ARM, hastily done
>> in a day's work time for people on the list to try and to comment.
>> All comments are welcome, as several suggestions have been made
>> today on the list that I did not have time to incorporate, such as
>> rewriting the elf table fixup code in C.
>>
>> The basic idea of this patch is to replace the -fPIC compile-time
>> option with the -pie link-time option. This removes the GOT but adds
>> the .rel.dyn and .dynsym tables, which together allow fixing up code
>> more completely than with -fPIC and the GOT; for instance, all pointers
>> inside structures are fixed up with -pie, whereas they are not with GOT.
>>
>> Note that references to linker-file-generated symbols were also made
>> relative to _start rather than absolute. This is not needed as such,
>> but it will be useful when optimizing the relocation tables. Actually
>> I should have separated this from the ELF relocation support per se.
>>
>> The edminiv2.h config file is there for reference only; this is the
>> one I used for tests. Latest numbers are:
>>
>> With GOT relocs:
>>
>> text data bss dec hex filename .bin size
>> 141376 4388 16640 162404 27a64 ./u-boot 145764
>>
>> With ELF relocs:
>>
>> text data bss dec hex filename .bin size
>> 149677 3727 16636 170040 29838 ./u-boot 153408
>>
>> The size difference is essentially due to .rel.dyn not being optimal.
>> As discussed, an added build step should allow reducing it by half and
>> making ELF sizes roughly similar to GOT ones.
>>
>> Tests and comments not only welcome but also heartily called for.
>
> Tested based on your patch on the magnesium board (ARM926ejs and
> boots from NOR Flash). U-Boot works, with the following patch:
>
> ! I had to set TEXT_BASE to 0xc0000000 as u-boot starts from there,
> a TEXT_BASE = 0 didn;t work for me!
Seems like an overlook from me, it should not be 0.
I'll change thant in the next version.
Thanks for testing!
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:31 [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations Albert Aribaud
2010-10-05 6:45 ` Wolfgang Denk
2010-10-05 7:40 ` Heiko Schocher
@ 2010-10-05 8:02 ` Wolfgang Denk
2010-10-05 9:25 ` Heiko Schocher
2010-10-05 12:52 ` Heiko Schocher
4 siblings, 0 replies; 42+ messages in thread
From: Wolfgang Denk @ 2010-10-05 8:02 UTC (permalink / raw)
To: u-boot
Dear Albert Aribaud,
In message <1286260287-1571-1-git-send-email-albert.aribaud@free.fr> you wrote:
> HISTORY:
>
> V1 Initial patch
> V2 Rebased on latest mainline master
>
> This patch is *not* a submission for master!
Tried with the following patch on armv7 (Beagle board):
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index f411c0f..f5cd2db 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -69,22 +69,12 @@ _end_vect:
_TEXT_BASE:
.word TEXT_BASE
-#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-.globl _armboot_start
-_armboot_start:
- .word _start
-#endif
-
/*
* These are defined in the board-specific linker script.
+ * Subtracting _start from them lets the linker put their
+ * relative position in the executable instead of leaving
+ * them null.
*/
-.globl _bss_start
-_bss_start:
- .word __bss_start
-
-.globl _bss_end
-_bss_end:
- .word _end
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
@@ -98,35 +88,34 @@ FIQ_STACK_START:
.word 0x0badc0de
#endif
-#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
/* IRQ stack memory (calculated at run-time) + 8 bytes */
.globl IRQ_STACK_START_IN
IRQ_STACK_START_IN:
.word 0x0badc0de
-.globl _datarel_start
-_datarel_start:
- .word __datarel_start
+.globl _bss_start_ofs
+_bss_start_ofs:
+ .word __bss_start - _start
-.globl _datarelrolocal_start
-_datarelrolocal_start:
- .word __datarelrolocal_start
+.globl _bss_end_ofs
+_bss_end_ofs:
+ .word _end - _start
-.globl _datarellocal_start
-_datarellocal_start:
- .word __datarellocal_start
+.globl _datarel_start_ofs
+_datarel_start_ofs:
+ .word __datarel_start - _start
-.globl _datarelro_start
-_datarelro_start:
- .word __datarelro_start
+.globl _datarelrolocal_start_ofs
+_datarelrolocal_start_ofs:
+ .word __datarelrolocal_start - _start
-.globl _got_start
-_got_start:
- .word __got_start
+.globl _datarellocal_start_ofs
+_datarellocal_start_ofs:
+ .word __datarellocal_start - _start
-.globl _got_end
-_got_end:
- .word __got_end
+.globl _datarelro_start_ofs
+_datarelro_start_ofs:
+ .word __datarelro_start - _start
/*
* the actual reset code
@@ -198,9 +187,8 @@ stack_setup:
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
adr r0, _start
ldr r2, _TEXT_BASE
- ldr r3, _bss_start
- sub r2, r3, r2 /* r2 <- size of armboot */
- add r2, r0, r2 /* r2 <- source end address */
+ ldr r3, _bss_start_ofs
+ add r2, r0, r3 /* r2 <- source end address */
cmp r0, r6
#ifndef CONFIG_PRELOADER
beq jump_2_ram
@@ -213,34 +201,51 @@ copy_loop:
ble copy_loop
#ifndef CONFIG_PRELOADER
- /* fix got entries */
- ldr r1, _TEXT_BASE
- mov r0, r7 /* reloc addr */
- ldr r2, _got_start /* addr in Flash */
- ldr r3, _got_end /* addr in Flash */
- sub r3, r3, r1
- add r3, r3, r0
- sub r2, r2, r1
- add r2, r2, r0
-
+ /*
+ * fix .rel.dyn relocations
+ */
+ ldr r0, _TEXT_BASE /* r0 <- Text base */
+ sub r9, r7, 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 r4, [r2]
- sub r4, r4, r1
- add r4, r4, r0
- str r4, [r2]
- add r2, r2, #4
+ ldr r0, [r2] /* r0 <- location to fix up, IN FLASH! */
+ add r0, r9 /* r0 <- location to fix up in RAM */
+ ldr r1, [r2, #4]
+ and r8, r1, #0xff
+ cmp r8, #23 /* relative fixup? */
+ beq fixrel
+ cmp r8, #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, 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
- bne fixloop
+ ble fixloop
clear_bss:
- ldr r0, _bss_start
- ldr r1, _bss_end
- ldr r3, _TEXT_BASE /* Text base */
- mov r4, r7 /* reloc addr */
- sub r0, r0, r3
- add r0, r0, r4
- sub r1, r1, r3
- add r1, r1, r4
+ adr r2, _start
+ ldr r0, _bss_start_ofs /* find start of bss segment */
+ add r0, r0, r2
+ ldr r1, _bss_end_ofs /* stop here */
+ add r1, r1, r2
mov r2, #0x00000000 /* clear */
clbss_l:str r2, [r0] /* clear loop... */
@@ -255,10 +260,10 @@ clbss_l:str r2, [r0] /* clear loop... */
* initialization, now running from RAM.
*/
jump_2_ram:
- ldr r0, _TEXT_BASE
- ldr r2, _board_init_r
- sub r2, r2, r0
- add r2, r2, r7 /* position from board_init_r in RAM */
+ ldr r0, _board_init_r_ofs
+ adr r1, _start
+ add r0, r0, r1
+ add lr, r0, r9
/* setup parameters for board_init_r */
mov r0, r5 /* gd_t */
mov r1, r7 /* dest_addr */
@@ -266,94 +271,15 @@ jump_2_ram:
mov lr, r2
mov pc, lr
-_board_init_r: .word board_init_r
-#else /* #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) */
-/*
- * the actual reset code
- */
-
-reset:
- /*
- * set the cpu to SVC32 mode
- */
- mrs r0, cpsr
- bic r0, r0, #0x1f
- orr r0, r0, #0xd3
- msr cpsr,r0
-
-#if (CONFIG_OMAP34XX)
- /* Copy vectors to mask ROM indirect addr */
- adr r0, _start @ r0 <- current position of code
- add r0, r0, #4 @ skip reset vector
- mov r2, #64 @ r2 <- size to copy
- add r2, r0, r2 @ r2 <- source end address
- mov r1, #SRAM_OFFSET0 @ build vect addr
- mov r3, #SRAM_OFFSET1
- add r1, r1, r3
- mov r3, #SRAM_OFFSET2
- add r1, r1, r3
-next:
- ldmia r0!, {r3 - r10} @ copy from source address [r0]
- stmia r1!, {r3 - r10} @ copy to target address [r1]
- cmp r0, r2 @ until source end address [r2]
- bne next @ loop until equal */
-#if !defined(CONFIG_SYS_NAND_BOOT) && !defined(CONFIG_SYS_ONENAND_BOOT)
- /* No need to copy/exec the clock code - DPLL adjust already done
- * in NAND/oneNAND Boot.
- */
- bl cpy_clk_code @ put dpll adjust code behind vectors
-#endif /* NAND Boot */
-#endif
- /* the mask ROM code should have PLL and others stable */
-#ifndef CONFIG_SKIP_LOWLEVEL_INIT
- bl cpu_init_crit
-#endif
-
-#ifndef CONFIG_SKIP_RELOCATE_UBOOT
-relocate: @ relocate U-Boot to RAM
- adr r0, _start @ r0 <- current position of code
- ldr r1, _TEXT_BASE @ test if we run from flash or RAM
- cmp r0, r1 @ don't reloc during debug
- beq stack_setup
-
- ldr r2, _armboot_start
- ldr r3, _bss_start
- sub r2, r3, r2 @ r2 <- size of armboot
- add r2, r0, r2 @ r2 <- source end address
-
-copy_loop: @ copy 32 bytes at a time
- ldmia r0!, {r3 - r10} @ copy from source address [r0]
- stmia r1!, {r3 - r10} @ copy to target address [r1]
- cmp r0, r2 @ until source end addreee [r2]
- ble copy_loop
-#endif /* CONFIG_SKIP_RELOCATE_UBOOT */
-
- /* Set up the stack */
-stack_setup:
- ldr r0, _TEXT_BASE @ upper 128 KiB: relocated uboot
- sub r0, r0, #CONFIG_SYS_MALLOC_LEN @ malloc area
- sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE @ bdinfo
-#ifdef CONFIG_USE_IRQ
- sub r0, r0, #(CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ)
-#endif
- sub sp, r0, #12 @ leave 3 words for abort-stack
- bic sp, sp, #7 @ 8-byte alignment for ABI compliance
-
- /* Clear BSS (if any). Is below tx (watch load addr - need space) */
-clear_bss:
- ldr r0, _bss_start @ find start of bss segment
- ldr r1, _bss_end @ stop here
- mov r2, #0x00000000 @ clear value
-clbss_l:
- str r2, [r0] @ clear BSS location
- cmp r0, r1 @ are we at the end yet
- add r0, r0, #4 @ increment clear index pointer
- bne clbss_l @ keep clearing till@end
-
- ldr pc, _start_armboot @ jump to C code
+_board_init_r_ofs:
+ .word board_init_r - _start
-_start_armboot: .word start_armboot
-#endif /* #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) */
+_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
/*************************************************************************
*
@@ -480,7 +406,6 @@ cpu_init_crit:
.macro get_bad_stack
#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
- ldr r13, _armboot_start @ setup our mode stack (enter
sub r13, r13, #(CONFIG_SYS_MALLOC_LEN) @ move past malloc pool
sub r13, r13, #(CONFIG_SYS_GBL_DATA_SIZE + 8) @ move to reserved a couple
#else
@@ -508,7 +433,7 @@ cpu_init_crit:
@ scratch reg.
str r0, [r13] @ save R0's value.
#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
- ldr r0, _armboot_start @ get data regions start
+ adr r0, _start @ get data regions start
sub r0, r0, #(CONFIG_SYS_MALLOC_LEN) @ move past malloc pool
sub r0, r0, #(CONFIG_SYS_GBL_DATA_SIZE + 8) @ move past gbl and a couple
#else
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index d4fd3fc..43abaf9 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -54,6 +54,14 @@ SECTIONS
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ .rel.dyn : { *(.rel.dyn) }
+ __rel_dyn_end = .;
+
+ __dynsym_start = .;
+ .dynsym : { *(.dynsym) }
+
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 2463be4..cf73f27 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -341,7 +341,7 @@ extern unsigned int boot_flash_type;
#endif
/* additions for new relocation code, must added to all boards */
-#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
The board hangs shortly after startup:
U-Boot 2010.09-00100-g2906eb5-dirty (Oct 05 2010 - 09:49:37)
OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C:
^ permalink raw reply related [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:31 [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations Albert Aribaud
` (2 preceding siblings ...)
2010-10-05 8:02 ` Wolfgang Denk
@ 2010-10-05 9:25 ` Heiko Schocher
2010-10-05 9:32 ` Albert ARIBAUD
2010-10-05 12:07 ` Heiko Schocher
2010-10-05 12:52 ` Heiko Schocher
4 siblings, 2 replies; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 9:25 UTC (permalink / raw)
To: u-boot
Hello Albert,
Albert Aribaud wrote:
> HISTORY:
>
> V1 Initial patch
> V2 Rebased on latest mainline master
>
> This patch is *not* a submission for master!
>
> It is a proof of concept of ELF relocations for ARM, hastily done
> in a day's work time for people on the list to try and to comment.
> All comments are welcome, as several suggestions have been made
> today on the list that I did not have time to incorporate, such as
> rewriting the elf table fixup code in C.
Following patch works on the tx25 with booting from nand:
remark !!!! :
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -266,7 +266,7 @@ fixnext:
str r1, [r0]
add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
- ble fixloop
+ bne fixloop
Must be discussed/changed, because this fixes just a bug. For this board
my last entry in __rel_dyn_start is filled with 00000000, which results
in crashing code ...
here now the patch, based on actaul mainline code and your patch:
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 5a7ae7e..cf3a59f 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -266,7 +266,7 @@ fixnext:
str r1, [r0]
add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
- ble fixloop
+ bne fixloop
#endif
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
@@ -297,8 +297,9 @@ clbss_l:str r2, [r0] /* clear loop... */
ldr r0, _nand_boot_ofs
adr r1, _start
add pc, r0, r1
-_nand_boot_ofs
- : .word nand_boot - _start
+
+_nand_boot_ofs:
+ .word nand_boot - _start
#else
ldr r0, _board_init_r_ofs
adr r1, _start
diff --git a/board/karo/tx25/config.mk b/board/karo/tx25/config.mk
index 51ca1ab..8be6466 100644
--- a/board/karo/tx25/config.mk
+++ b/board/karo/tx25/config.mk
@@ -1,5 +1,5 @@
ifdef CONFIG_NAND_SPL
TEXT_BASE = 0x810c0000
else
-TEXT_BASE = 0x81fc0000
+TEXT_BASE = 0x81200000
endif
diff --git a/include/configs/tx25.h b/include/configs/tx25.h
index c798570..2be3699 100644
--- a/include/configs/tx25.h
+++ b/include/configs/tx25.h
@@ -41,7 +41,7 @@
#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x800
#define CONFIG_SYS_NAND_U_BOOT_SIZE 0x30000
-#define CONFIG_SYS_NAND_U_BOOT_DST (0x81fc0000)
+#define CONFIG_SYS_NAND_U_BOOT_DST (0x81200000)
#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
@@ -178,6 +178,7 @@
/* additions for new relocation code, must added to all boards */
#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 - /* Fix this */ \
CONFIG_SYS_GBL_DATA_SIZE)
diff --git a/nand_spl/board/karo/tx25/u-boot.lds b/nand_spl/board/karo/tx25/u-boot.lds
index c572557..36d716b 100644
--- a/nand_spl/board/karo/tx25/u-boot.lds
+++ b/nand_spl/board/karo/tx25/u-boot.lds
@@ -53,6 +53,14 @@ SECTIONS
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ .rel.dyn : { *(.rel.dyn) }
+ __rel_dyn_end = .;
+
+ __dynsym_start = .;
+ .dynsym : { *(.dynsym) }
+
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related [flat|nested] 42+ messages in thread* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:25 ` Heiko Schocher
@ 2010-10-05 9:32 ` Albert ARIBAUD
2010-10-05 12:07 ` Heiko Schocher
1 sibling, 0 replies; 42+ messages in thread
From: Albert ARIBAUD @ 2010-10-05 9:32 UTC (permalink / raw)
To: u-boot
Le 05/10/2010 11:25, Heiko Schocher a ?crit :
> Following patch works on the tx25 with booting from nand:
>
> remark !!!! :
>
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -266,7 +266,7 @@ fixnext:
> str r1, [r0]
> add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> cmp r2, r3
> - ble fixloop
> + bne fixloop
>
> Must be discussed/changed, because this fixes just a bug. For this board
> my last entry in __rel_dyn_start is filled with 00000000, which results
> in crashing code ...
The bug you uncovered is -- again -- mine.
The 'bne' would loop until r2 equals r3, and as r3 is *right after* the
last .rel.dyn entry, it works.
Whereas my 'ble' loops until r2 is *greater* than r3, thus it tries to
process as a .rel.dyn entry what actually is the 8 bytes that *follow*
.rel.dyn.
The right opcode (both function and resilient to errors) is 'blo'.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 9:25 ` Heiko Schocher
2010-10-05 9:32 ` Albert ARIBAUD
@ 2010-10-05 12:07 ` Heiko Schocher
1 sibling, 0 replies; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 12:07 UTC (permalink / raw)
To: u-boot
Hello Albert,
Heiko Schocher wrote:
> Albert Aribaud wrote:
>> HISTORY:
>>
>> V1 Initial patch
>> V2 Rebased on latest mainline master
>>
>> This patch is *not* a submission for master!
>>
>> It is a proof of concept of ELF relocations for ARM, hastily done
>> in a day's work time for people on the list to try and to comment.
>> All comments are welcome, as several suggestions have been made
>> today on the list that I did not have time to incorporate, such as
>> rewriting the elf table fixup code in C.
>
> Following patch works on the tx25 with booting from nand:
Sorry, I was to fast, I had a problem with to big nand_spl code,
fixed this now, as I didn;t activate -pie flag for NAND_SPL code,
as this don;t need relocation.
Also I use "blo" instead "ble" in start.S
here now the v2 patch for the tx25 board:
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index e9e02da..19b8f02 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -72,4 +72,6 @@ PLATFORM_LIBS += $(OBJTREE)/arch/arm/lib/eabi_compat.o
endif
endif
LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
-PLATFORM_LDFLAGS += -pie
\ No newline at end of file
+ifndef CONFIG_NAND_SPL
+PLATFORM_LDFLAGS += -pie
+endif
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 5a7ae7e..68e597c 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -266,7 +266,7 @@ fixnext:
str r1, [r0]
add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
- ble fixloop
+ blo fixloop
#endif
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
@@ -295,10 +295,10 @@ clbss_l:str r2, [r0] /* clear loop... */
*/
#ifdef CONFIG_NAND_SPL
ldr r0, _nand_boot_ofs
- adr r1, _start
- add pc, r0, r1
-_nand_boot_ofs
- : .word nand_boot - _start
+ mov pc, r0
+
+_nand_boot_ofs:
+ .word nand_boot
#else
ldr r0, _board_init_r_ofs
adr r1, _start
diff --git a/board/karo/tx25/config.mk b/board/karo/tx25/config.mk
index 51ca1ab..8be6466 100644
--- a/board/karo/tx25/config.mk
+++ b/board/karo/tx25/config.mk
@@ -1,5 +1,5 @@
ifdef CONFIG_NAND_SPL
TEXT_BASE = 0x810c0000
else
-TEXT_BASE = 0x81fc0000
+TEXT_BASE = 0x81200000
endif
diff --git a/include/configs/tx25.h b/include/configs/tx25.h
index c798570..2be3699 100644
--- a/include/configs/tx25.h
+++ b/include/configs/tx25.h
@@ -41,7 +41,7 @@
#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x800
#define CONFIG_SYS_NAND_U_BOOT_SIZE 0x30000
-#define CONFIG_SYS_NAND_U_BOOT_DST (0x81fc0000)
+#define CONFIG_SYS_NAND_U_BOOT_DST (0x81200000)
#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
@@ -178,6 +178,7 @@
/* additions for new relocation code, must added to all boards */
#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 - /* Fix this */ \
CONFIG_SYS_GBL_DATA_SIZE)
diff --git a/nand_spl/board/karo/tx25/u-boot.lds b/nand_spl/board/karo/tx25/u-boot.lds
index c572557..5f95c87 100644
--- a/nand_spl/board/karo/tx25/u-boot.lds
+++ b/nand_spl/board/karo/tx25/u-boot.lds
@@ -53,6 +53,11 @@ SECTIONS
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ __rel_dyn_end = .;
+ __dynsym_start = .;
+
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
@@ -67,4 +72,12 @@ SECTIONS
__bss_start = .;
.bss : { *(.bss) }
_end = .;
+ /DISCARD/ : { *(.bss*) }
+ /DISCARD/ : { *(.dynstr*) }
+ /DISCARD/ : { *(.dynsym*) }
+ /DISCARD/ : { *(.dynamic*) }
+ /DISCARD/ : { *(.hash*) }
+ /DISCARD/ : { *(.plt*) }
+ /DISCARD/ : { *(.interp*) }
+ /DISCARD/ : { *(.gnu*) }
}
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations
2010-10-05 6:31 [U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations Albert Aribaud
` (3 preceding siblings ...)
2010-10-05 9:25 ` Heiko Schocher
@ 2010-10-05 12:52 ` Heiko Schocher
4 siblings, 0 replies; 42+ messages in thread
From: Heiko Schocher @ 2010-10-05 12:52 UTC (permalink / raw)
To: u-boot
Hello Albert,
Albert Aribaud wrote:
> HISTORY:
>
> V1 Initial patch
> V2 Rebased on latest mainline master
>
> This patch is *not* a submission for master!
Following patch works on the beagle (ARMv7) board, with
booting from mmc.
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index f411c0f..b011d7b 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -78,13 +78,13 @@ _armboot_start:
/*
* These are defined in the board-specific linker script.
*/
-.globl _bss_start
-_bss_start:
- .word __bss_start
+.globl _bss_start_ofs
+_bss_start_ofs:
+ .word __bss_start - _start
-.globl _bss_end
-_bss_end:
- .word _end
+.globl _bss_end_ofs
+_bss_end_ofs:
+ .word _end - _start
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
@@ -104,29 +104,29 @@ FIQ_STACK_START:
IRQ_STACK_START_IN:
.word 0x0badc0de
-.globl _datarel_start
-_datarel_start:
- .word __datarel_start
+.globl _datarel_start_ofs
+_datarel_start_ofs:
+ .word __datarel_start - _start
-.globl _datarelrolocal_start
-_datarelrolocal_start:
- .word __datarelrolocal_start
+.globl _datarelrolocal_start_ofs
+_datarelrolocal_start_ofs:
+ .word __datarelrolocal_start - _start
-.globl _datarellocal_start
-_datarellocal_start:
- .word __datarellocal_start
+.globl _datarellocal_start_ofs
+_datarellocal_start_ofs:
+ .word __datarellocal_start - _start
-.globl _datarelro_start
-_datarelro_start:
- .word __datarelro_start
+.globl _datarelro_start_ofs
+_datarelro_start_ofs:
+ .word __datarelro_start - _start
-.globl _got_start
-_got_start:
- .word __got_start
+.globl _got_start_ofs
+_got_start_ofs:
+ .word __got_start - _start
-.globl _got_end
-_got_end:
- .word __got_end
+.globl _got_end_Ofs
+_got_end_ofs:
+ .word __got_end - _start
/*
* the actual reset code
@@ -198,9 +198,8 @@ stack_setup:
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
adr r0, _start
ldr r2, _TEXT_BASE
- ldr r3, _bss_start
- sub r2, r3, r2 /* r2 <- size of armboot */
- add r2, r0, r2 /* r2 <- source end address */
+ ldr r3, _bss_start_ofs
+ add r2, r0, r3 /* r2 <- source end address */
cmp r0, r6
#ifndef CONFIG_PRELOADER
beq jump_2_ram
@@ -213,33 +212,51 @@ copy_loop:
ble copy_loop
#ifndef CONFIG_PRELOADER
- /* fix got entries */
- ldr r1, _TEXT_BASE
- mov r0, r7 /* reloc addr */
- ldr r2, _got_start /* addr in Flash */
- ldr r3, _got_end /* addr in Flash */
- sub r3, r3, r1
- add r3, r3, r0
- sub r2, r2, r1
- add r2, r2, r0
-
+ /*
+ * fix .rel.dyn relocations
+ */
+ ldr r0, _TEXT_BASE /* r0 <- Text base */
+ sub r9, r7, 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 r4, [r2]
- sub r4, r4, r1
- add r4, r4, r0
- str r4, [r2]
- add r2, r2, #4
+ ldr r0, [r2] /* r0 <- location to fix up, IN FLASH! */
+ add r0, r9 /* r0 <- location to fix up in RAM */
+ ldr r1, [r2, #4]
+ and r8, r1, #0xff
+ cmp r8, #23 /* relative fixup? */
+ beq fixrel
+ cmp r8, #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, 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
- bne fixloop
+ blo fixloop
clear_bss:
- ldr r0, _bss_start
- ldr r1, _bss_end
+ ldr r0, _bss_start_ofs
+ ldr r1, _bss_end_ofs
ldr r3, _TEXT_BASE /* Text base */
mov r4, r7 /* reloc addr */
- sub r0, r0, r3
add r0, r0, r4
- sub r1, r1, r3
add r1, r1, r4
mov r2, #0x00000000 /* clear */
@@ -255,18 +272,26 @@ clbss_l:str r2, [r0] /* clear loop... */
* initialization, now running from RAM.
*/
jump_2_ram:
- ldr r0, _TEXT_BASE
- ldr r2, _board_init_r
- sub r2, r2, r0
- add r2, r2, r7 /* position from board_init_r in RAM */
+ ldr r0, _board_init_r_ofs
+ adr r1, _start
+ add r0, r0, r1
+ add lr, r0, r9
/* setup parameters for board_init_r */
mov r0, r5 /* gd_t */
mov r1, r7 /* dest_addr */
/* jump to it ... */
- mov lr, r2
mov pc, lr
-_board_init_r: .word board_init_r
+_board_init_r_ofs:
+ .word board_init_r - _start
+
+_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
+
#else /* #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) */
/*
* the actual reset code
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index d4fd3fc..88a0fec 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -53,6 +53,13 @@ SECTIONS
__datarelro_start = .;
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ .rel.dyn : { *(.rel.dyn) }
+ __rel_dyn_end = .;
+
+ __dynsym_start = .;
+ .dynsym : { *(.dynsym) }
__got_start = .;
. = ALIGN(4);
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 2463be4..5404d60 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -342,6 +342,7 @@ extern unsigned int boot_flash_type;
/* additions for new relocation code, must added to all boards */
#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related [flat|nested] 42+ messages in thread