[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock <f.lobenstock@scottygroup.com>]

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),%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 at +
> 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.
>>
> 
> 


-- 
MfG / Regards
Friedrich Lobenstock