[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

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?

> 
> Someone with a Motorola Coldfire 5272 cpu experienced the same and could 
> give me a hint.
> 


-- 
MfG / Regards
Friedrich Lobenstock