[U-Boot-Users] u-boot hangs after relocating itself to ram

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Andre Puschmann wrote:
> Hey folkes,
> I have ported u-boot to a custom board based on a freescale mpc5200. I
> can successfully copy u-boot into flash using the connected bdi2000 and
> we get some output on the debug port. It seems that the board crashes
> right after relocation to ram (see output). I already
> read the regarding faq entry but I'm not sure if this problem has
> something to do with faulty sdram initialization.
> 
> this is the output than comes up on the console:
> 
> 20030.56> U-Boot 1.1.6-ge4bbd8da-dirty (Nov 27 2006 - 18:46:24)
> 20030.56>
> 20030.56> CPU:   MPC5200 v1.2, Core v1.1 at 396 MHz
> 20030.56>        Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
> 20030.57> Board: MPC5200 ECU
> 20030.57> I2C:   85 kHz, ready
> 20030.57> DRAM:   8 MB
> 20030.57> FLASH:
> 
> I'm using eldk 4.0 + insight to debug the problem. I can single-step
> through the code up to the point where it branches to sdram.
> After relocation I loaded a new symbol file width offset 0x7d8000, since
> this is the dest-address for relocate_code().
> 
> If I continue running from that point on the board crashes at 0x7dc314
> which is in function loadtask(). In assembler the code looks like this:
> "0x7dc314	<loadtask+48>:		lwz     r11,-32768(r30)"
> 
> Can this be a sdram related problem or what might cause this behavior?
> 
> Any comments and suggestions are more than welcome.
> 
> Best regards,
> Andr? Puschmann

If it _isn't_ a SDRAM related problem, I suggest you look into what is 
going on in loadtask+48 (source and also disassemble it using the cross 
flavor of objdump).  -32768 is integer for "the largest negative number 
you can represent" and I would be suspicious that it is a reference to a 
variable that is undefined or too far distant to be reached relative to 
r30.  What is r30 in this context and what is it trying to access?

gvb