SDRAM failures on MPC5200B

SDRAM failures on MPC5200B

[lokowich]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

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
lokowich@acdstar.com

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com


[-- Attachment #2: Type: text/html, Size: 1324 bytes --]

Re: SDRAM failures on MPC5200B

[Rafal Jaworowski]

lokowich 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.
> 

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

Re: SDRAM failures on MPC5200B

[Frank Bennett]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

lokowich 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.
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/>_
_

>
> Thanks,
> Mark Lokowich
> Systems Engineer
> Advanced Communication Design
> 7901 12th Ave. So.
> Bloomington, MN 55425
> 952-854-4000
> lokowich@acdstar.com
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


[-- Attachment #2: Type: text/html, Size: 3232 bytes --]

Re: SDRAM failures on MPC5200B

[Florian A. Voegel]

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

On Fri, 20 Jul 2007 10:40:30 -0500
lokowich <lokowich@acdstar.com> 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
> lokowich@acdstar.com
> 
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
> 
> 

Re: SDRAM failures on MPC5200B

[lokowich]

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

lokowich 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
> lokowich@acdstar.com
> 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
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: SDRAM failures on MPC5200B

[Roman Fietze]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

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.

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

-- 
Roman Fietze Telemotive AG Büro Mühlhausen


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: SDRAM failures on MPC5200B

[lokowich]

[-- Attachment #1: Type: text/html, Size: 3855 bytes --]