[U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations

Heiko Schocher
2010-10-05T09:00:57Z

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