[U-Boot] uboot MPC5200B DDR memsize hangs
Hm... U-Boot 1.2.0 is very old. Please consider it obsolelte and unsupported. Is there any special reason for not using current code?
No reason, UBoot 1.2.0 is in ELDK4.1. Will seek and download latest uboot
UBoot starts and we see serial output; but UBoot hangs on the very first read from DDR which is done in memsize.c:get_ram_size().
The serial output is: CPU: MPC5200 v2.2, Core v1.4 at 462 MHz Bus 132 MHz, IPB 66 MHz, PCI 33 MHz Board: JKC5200N7 I2C: 85 kHz, ready DRAM:
We are pretty sure the DDR configuration is correct, but we would have thought this would not cause get_ram_size() to hang - merely return 0 or incorrect memory size.
You are almost certainly wron - either your hardware or your DDR initialization is broken.
Can bad DDR configuration really hang the processor? I thought there was no acknowledgement system for DDR.
See also the FAQ at http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
Does the relocation occur before checking the DDR size?
Chris
Hi Chris,
Hm... U-Boot 1.2.0 is very old. Please consider it obsolelte and unsupported. Is there any special reason for not using current code?
No reason, UBoot 1.2.0 is in ELDK4.1. Will seek and download latest uboot
Stable tarballs can be found on our ftp server[1] - git access to the very latest and greatest is available here[2].
See also the FAQ at http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
Does the relocation occur before checking the DDR size?
For PowerPC we relocate to the highest possible RAM address, so no we need to probe RAM before we can relocate. Also I would think that we do not even get to the relocation but hang in the probing phase. You should really hook up a JTAG debugger and find out what's wrong.
Best wishes Detlev
[1] ftp://ftp.denx.de/pub/u-boot/ [2] http://git.denx.de/?p=u-boot.git;a=summary
For those interested,
The problem was a bad solder joint on CAS.
During writes to DDR, the CPU generates the DQS strobes.
During reads from DDR, the SDRAM asserts the DQS strobes. If the DDR SDRAM is not initialised properly, the SDRAM will not assert the DQS signals and the CPU will hang on a read from SDRAM. Eventually the CPU seems to reset after about 90 seconds - must be an internal MPC5200 timeout of some sort.
SDR does not use the DQS signals so you can not hang on any SDR SDRAM transaction even if the SDRAM is not configured correctly.
Thanks for the help, Chris
Hi Chris,
Hm... U-Boot 1.2.0 is very old. Please consider it obsolelte and unsupported. Is there any special reason for not using current code?
No reason, UBoot 1.2.0 is in ELDK4.1. Will seek and download latest uboot
Stable tarballs can be found on our ftp server[1] - git access to the very latest and greatest is available here[2].
See also the FAQ at http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
Does the relocation occur before checking the DDR size?
For PowerPC we relocate to the highest possible RAM address, so no we need to probe RAM before we can relocate. Also I would think that we do not even get to the relocation but hang in the probing phase. You should really hook up a JTAG debugger and find out what's wrong.
Best wishes Detlev
[1] ftp://ftp.denx.de/pub/u-boot/ [2] http://git.denx.de/?p=u-boot.git;a=summary
-- If we knew what it was we were doing, we wouldn't call it research. -- Einstein
participants (3)
-
Chris Alfred -
Chris Alfred (Internode) -
Detlev Zundel