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

Reinhard Meyer
2010-10-05T08:59:49Z

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