From mboxrd@z Thu Jan 1 00:00:00 1970 From: Friedrich Lobenstock Date: Tue, 31 May 2005 01:10:10 +0200 Subject: [U-Boot-Users] mcf5272 hanging while relocating In-Reply-To: <429B9956.90804@scottygroup.com> References: <4289E7A5.90307@scottygroup.com> <429B8F62.7040202@scottygroup.com> <429B9956.90804@scottygroup.com> Message-ID: <429B9D52.3060102@scottygroup.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 : moveal %a0,%a1 > 0x7e70de : addal #78848,%a1 > 0x7e70e4 : moveal %a1,%a5 > 0x7e70e6 : moveal %a0,%a2 > 0x7e70e8 : addal #78848,%a2 > 0x7e70ee : movel %a1@,%d1 > 0x7e70f0 : subil #-2096128,%d1 > 0x7e70f6 : addl %a0,%d1 > 0x7e70f8 : movel %d1,%a1 at + > 0x7e70fa : cmpal %a2,%a1 > 0x7e70fc : bnew 0x7e70ee > > 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