From mboxrd@z Thu Jan 1 00:00:00 1970 From: Friedrich Lobenstock Date: Tue, 31 May 2005 00:53:10 +0200 Subject: [U-Boot-Users] mcf5272 hanging while relocating In-Reply-To: <429B8F62.7040202@scottygroup.com> References: <4289E7A5.90307@scottygroup.com> <429B8F62.7040202@scottygroup.com> Message-ID: <429B9956.90804@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: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? > > Someone with a Motorola Coldfire 5272 cpu experienced the same and could > give me a hint. > -- MfG / Regards Friedrich Lobenstock