Friedrich Lobenstock wrote on 31.05.2005 00:53 MET:
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),%a27: 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?
I might want to add that I just copied the board definition m5272c3 but did not change something in regards to the __got_xxx addresses. I just copied the dir cpu/mcf52x2 to cpu/mcf52xx to apply local initialization changes.
# diff -u board/m5272c3/u-boot.lds board/uncle_rev_4/u-boot.lds --- board/m5272c3/u-boot.lds 2004-02-12 01:47:11.000000000 +0100 +++ board/uncle_rev_4/u-boot.lds 2005-05-16 05:37:18.000000000 +0200 @@ -56,9 +56,9 @@ /* WARNING - the following is hand-optimized to fit within */ /* the sector layout of our flash chips! XXX FIXME XXX */
- cpu/mcf52x2/start.o (.text) + cpu/mcf52xx/start.o (.text) lib_m68k/traps.o (.text) - cpu/mcf52x2/interrupts.o (.text) + cpu/mcf52xx/interrupts.o (.text) common/dlmalloc.o (.text) lib_generic/zlib.o (.text)
Running "diff -u board/m5272c3/u-boot.lds board/m5282evb/u-boot.lds" also reveals that there are some different modules located at different locations. Could that be the influence that the compiler computes __got_end the wrong way?
Someone with a Motorola Coldfire 5272 cpu experienced the same and could give me a hint.