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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
