[U-Boot-Users] u-boot hangs after relocating itself to ram
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Tue Nov 28 22:12:01 CET 2006
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> 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?
More information about the U-Boot