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

[Albert ARIBAUD <albert.aribaud@free.fr>]

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.