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

[Heiko Schocher <hs@denx.de>]

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