SDRAM failures on MPC5200B
We're working on bringing up a MPC5200B version of our original MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B. Other than the CPU, the board is identical. The bootloader crashes just after relocation to RAM, often with a Program Check Exception, typically a memory corruption issue. I noticed failures at different stages after relocation based on content, suggesting problems with upper SDRAM. If I force the initram to 1/2 the determined size (64MB instead of 128MB), then everything works well through kernel load and initialization. We've added termination resistors to improve AD signals, to no avail. Memory tests work fine too. Any help is appreciated.
Thanks,
Mark Lokowich
Systems Engineer
Advanced Communication Design
7901 12th Ave. So.
Bloomington, MN 55425
952-854-4000
[email protected]
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
Quoted 2 lines · lokowich
We're working on bringing up a MPC5200B version of our original MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B. Other than the CPU, the board is identical. The bootloader crashes just after relocation to RAM, often with a Program Check Exception, typically a memory corruption issue. I noticed failures at different stages after relocation based on content, suggesting problems with upper SDRAM. If I force the initram to 1/2 the determined size (64MB instead of 128MB), then everything works well through kernel load and initialization. We've added termination resistors to improve AD signals, to no avail. Memory tests work fine too. Any help is appreciated.
Assuming your RAM chips are fine, are you setting the SDelay register (MBAR + 0x0190)? If not, this can lead to a strange hangs similar to the described. For details please see the current U-Boot's initdram() for icecube, and AN3221.
Rafal
Hi,
Considering the age of the U-Boot version you're using, it's most likely the problem with the SD-RAM controller of the 5200B. Later U-Boot versions fix this I think by writing a value of 4 to the register at MBAR+0x0190, which does _something_ to resolve the problem. It worked for us. However, we still had problems with SD-RAM in conjunction with other components, so we switched to DDR which has worked flawlessly so far - you might want to consider doing the same.
Greets,
Florian Voegel
Carangul.Tech
Quoted 23 lines · On Fri, 20 Jul 2007 10:40:30 -0500 lokowich <[email protected]> wrote:
We're working on bringing up a MPC5200B version of our original MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B. Other than the CPU, the board is identical. The bootloader crashes just after relocation to RAM, often with a Program Check Exception, typically a memory corruption issue. I noticed failures at different stages after relocation based on content, suggesting problems with upper SDRAM. If I force the initram to 1/2 the determined size (64MB instead of 128MB), then everything works well through kernel load and initialization. We've added termination resistors to improve AD signals, to no avail. Memory tests work fine too. Any help is appreciated.
Thanks,
Mark Lokowich
Systems Engineer
Advanced Communication Design
7901 12th Ave. So.
Bloomington, MN 55425
952-854-4000
[email protected]This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
Quoted 1 line · lokowich
We're working on bringing up a MPC5200B version of our original MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B. Other than the CPU, the board is identical. The bootloader crashes just after relocation to RAM, often with a Program Check Exception, typically a memory corruption issue. I noticed failures at different stages after relocation based on content, suggesting problems with upper SDRAM. If I force the initram to 1/2 the determined size (64MB instead of 128MB), then everything works well through kernel load and initialization. We've added termination resistors to improve AD signals, to no avail. Memory tests work fine too. Any help is appreciated.
Review MPC5200B errata data sheets. I found a BDI2000 + RS232 console port most useful for turning on a new design. Even the exercise of BDI commands to tftp load/verify, memory write/verify, debugging u-boot to run out of ram, with & w/o cache turned on can be enlightening.
/*/Frank Bennett
President/*/
Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
www.mathegraphics.com <http://www.mathegraphics.com/>_
_
Quoted 16 lines
Thanks,
Mark Lokowich
Systems Engineer
Advanced Communication Design
7901 12th Ave. So.
Bloomington, MN 55425
952-854-4000
[email protected]
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
------------------------------------------------------------------------_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
A follow-up: The first version of our termination network was based on the Lite5200 reference design, but was confirmed by Freescale to be inadequate. We revised the hardware per their errata, terminating both ends of the data bus. This fixed the problem. Thanks for the helpful feedback.
Mark
Quoted 18 lines · lokowich
We're working on bringing up a MPC5200B version of our original MPC5200 board using U-Boot 1.1.4 configured for Icecube/Lite5200B. Other than the CPU, the board is identical. The bootloader crashes just after relocation to RAM, often with a Program Check Exception, typically a memory corruption issue. I noticed failures at different stages after relocation based on content, suggesting problems with upper SDRAM. If I force the initram to 1/2 the determined size (64MB instead of 128MB), then everything works well through kernel load and initialization. We've added termination resistors to improve AD signals, to no avail. Memory tests work fine too. Any help is appreciated.
Thanks,
Mark Lokowich
Systems Engineer
Advanced Communication Design
7901 12th Ave. So.
Bloomington, MN 55425
952-854-4000
[email protected]
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
------------------------------------------------------------------------_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Hallo Mark,
Quoted 5 lines · On Tuesday 13 November 2007 14:59:56 lokowich wrote:
A follow-up: The first version of our termination network was based on the Lite5200 reference design, but was confirmed by Freescale to be inadequate. We revised the hardware per their errata, terminating both ends of the data bus. This fixed the problem. Thanks for the helpful feedback.
If I can remember it correctly, the is no errata on the Freescale documentation web pages specifying to terminate the SDRAM data lines on both ends. The only document I can remember that specifies something similar is AN3045, "A comparison of the MPC5200B (Mask Set M62C) with prior MPC5200 Versions" on page 2, in the chapter "1. Overview".
Could you please give me some hint about what errata or other document we probably missed?
Maybe I have to tell our HW people that it will be necessary to fix our design as well.
Thank you
Roman
Signature · 1 line
Roman Fietze Telemotive AG Büro Mühlhausen
Roman Fietze wrote: Hallo Mark, On Tuesday 13 November 2007 14:59:56 lokowich wrote: A follow-up: The first version of our termination network was based on the Lite5200 reference design, but was confirmed by Freescale to be inadequate. We revised the hardware per their errata, terminating both ends of the data bus. This fixed the problem. Thanks for the helpful feedback.