[U-Boot] uboot MPC5200B DDR memsize hangs

[U-Boot] uboot MPC5200B DDR memsize hangs

[Chris Alfred]

> 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 

[U-Boot] uboot MPC5200B DDR memsize hangs

[Detlev Zundel]

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
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] uboot MPC5200B DDR memsize hangs

[Chris Alfred]

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