On Fri, Sep 17, 2010 at 5:10 AM, Heiko Schocher <h...@denx.de> wrote: > Change the implementation for ARM V7 to relocate the code to an > arbitrary address in RAM. > > Adapt the Beagle board (Cortex A8) to test the changes. > Heiko,
I'm running -next on a Beagle board (first version of arm reloc not v2). I noticed that when I wrote to ram in the range where u-boot runs before being relocated sometimes the board hangs. I then narrowed it down to being able to reproduce the hang by writing to a single byte. Turns out that __aeabi_uidiv gets called in its original location after relocation. I believe the culprit is ____aeabi_uidiv_veneer. Here is a disassembly of my u-boot elf file: 80035c98 <____aeabi_uidiv_veneer>: 80035c98: e51ff004 ldr pc, [pc, #-4] ; 80035c9c <_end+0xfffc2498> 80035c9c: 800356f1 .word 0x800356f1 My relocaton offset is 0x07f7c000 so the relocated ____aeabi_uidiv_veneer is at 0x80035c98+0x07f7c000 or 0x87fb1c98. If I dump memory there: OMAP3 beagleboard.org # md 0x87fb1c98 87fb1c98: e51ff004 800356f1 e51ff004 80035bfd .....V.......[.. The original 800356f1 is still there. Looks like these *veneer routines need to be relocated. Please disregard if this is fixed in v2. Regards, John _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
