[U-Boot-Users] mcf5272 hanging while relocating

[NZG]

> >>> 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.
Zach probably knows better than me about the 5272, I kind of jumped the 5272 
and went straight for the 82. The current 82 code had a lot of problems in 
the fec, timers, and initialization area. If the 5272 code is in a similar 
state then you may need to either use a preloader, or start with the patched 
5282 base and modify it up to offer similar support to the 5282.

Note that the 5272 code in the EMAC release should be essentially the same to 
the core, as most of the changes are ifdef's, with the exception of the fec 
code that has just been changed, and the cpu/52x2/start.S code, which has 
some new tricks in it.

As you have already discovered, the start.s code works by temporarily writing 
a small piece of code the the internal flash, jumping there, and using that 
code to relocate itself into it's final destination in a flash in upper 
memory.

Depending on the setting of INTERNAL_BOOT, this is either in internal flash(it 
it is set) or in external flash if it is not.

Depending on the setting of this flag, some other addresses will have to be 
set accordiingly in include/configs/"whatevertheboardisnamed".h

Notably:
CFG_MONITOR_BASE, which may be causing your problem below
CFG_FLASH_BASE	
and
CFG_INT_FLASH_BASE	

Take a look at include/configs/SOM5282EM.h and see if that doesn't clear some 
things up about how things will need to be set.

If it does not, please continue to post, and I will try to answer any specific 
questions and update the README as appropriate.


> I've also ported the serial 
> initialization code from that code to a generice form which applies for the 
> mcf5272 as well as the m5282.
That sounds good, 


thx,
NZG.


> >> [...]
> >> 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.