Friedrich Lobenstock wrote on 31.05.2005 00:10 MET:
Zachary Landau wrote on 17.05.2005 15:31 MET:
I've got a little problem porting U-Boot to a Coldfire MCF5272 based platform. Everything's fine (now) up to the point where it relocates itself to RAM. See the boot message:
If you haven't already, you should search the mailing list archives for information about the 5282 patches floating around. Your best bet is probably to modify those for the 5272.
[...] Using gdb with the BDM interface I find that the actual copying of the code to RAM succeeds but while clearing the BSS an exception happens as the system goes into the _fault endless loop.
Tracking it further down (with caches disabled) it actually clears the BSS but in the following section titled "fix got table in RAM" it creates the exception.
From cpu/mcf52xx/start.S(my local copy from cpu/mcf52x2/start.S): [...] move.l 16(%a6), %a0 /* Save copy of Destination Address */ [...] /* * fix got table in RAM */ move.l %a0, %a1 add.l #(__got_start - CFG_MONITOR_BASE),%a1 move.l %a1,%a5 /* * fix got pointer register a5 */
move.l %a0, %a2 add.l #(__got_end - CFG_MONITOR_BASE),%a2
7: move.l (%a1),%d1 sub.l #_start,%d1 add.l %a0,%d1 move.l %d1,(%a1)+ cmp.l %a2, %a1 bne 7b
which result in the following code (already running from ram here): 0x7e70dc <in_ram+22>: moveal %a0,%a1 0x7e70de <in_ram+24>: addal #78848,%a1 0x7e70e4 <in_ram+30>: moveal %a1,%a5 0x7e70e6 <in_ram+32>: moveal %a0,%a2 0x7e70e8 <in_ram+34>: addal #78848,%a2 0x7e70ee <in_ram+40>: movel %a1@,%d1 0x7e70f0 <in_ram+42>: subil #-2096128,%d1 0x7e70f6 <in_ram+48>: addl %a0,%d1 0x7e70f8 <in_ram+50>: movel %d1,%a1@+ 0x7e70fa <in_ram+52>: cmpal %a2,%a1 0x7e70fc <in_ram+54>: bnew 0x7e70ee <in_ram+40>
now setting a (hardware-)breakpoint at address 0x7e70ee and printing the values of the startvalue (register a1) and the end value (register a2):
Program received signal SIGTRAP, Trace/breakpoint trap. 0x007e70f0 in in_ram () at /home/fl/work/coldfire/uboot/u-boot-1.1.2/cpu/mcf52xx/start.S:100 100 _start: (gdb) p /x $a1 $1 = 0x7fa400 (gdb) p /x $a2 $2 = 0x7fa400 (gdb) p /x $a0 $3 = 0x7e7000
Hmmmm....I would expect a2 to result in something higher than a1. Is this some sort of compiler bug?
Someone with a Motorola Coldfire 5272 cpu experienced the same and could give me a hint.