From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sentry.acdstar.com (mail.acdstar.com [209.98.244.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id E376EDDE16 for ; Sat, 21 Jul 2007 02:07:55 +1000 (EST) Received: from MailerDaemon by sentry.acdstar.com with local-bsmtp (Exim 4.63) (envelope-from ) id 1IBumj-0007dY-HA for linuxppc-embedded@ozlabs.org; Fri, 20 Jul 2007 10:52:53 -0500 Received: from [192.168.2.3] (port=60080 helo=mail.acdstar.com) by sentry.acdstar.com with esmtp (Exim 4.63) (envelope-from ) id 1IBumg-0007dP-0M for linuxppc-embedded@ozlabs.org; Fri, 20 Jul 2007 10:52:50 -0500 Received: from [192.168.2.105] (rnd-03.int.acdstar.com [192.168.2.105]) by mail.acdstar.com (8.13.6/8.13.6) with ESMTP id l6KFqM5R019889 for ; Fri, 20 Jul 2007 10:52:22 -0500 Message-ID: <46A0D76E.4030101@acdstar.com> Date: Fri, 20 Jul 2007 10:40:30 -0500 From: lokowich MIME-Version: 1.0 To: linuxppc-embedded@ozlabs.org Subject: SDRAM failures on MPC5200B Content-Type: multipart/alternative; boundary="------------050903060002030509050804" List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------050903060002030509050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------050903060002030509050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------050903060002030509050804-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.semihalf.com (mail.semihalf.com [83.12.36.68]) by ozlabs.org (Postfix) with ESMTP id C4E90DDE4A for ; Sat, 21 Jul 2007 03:06:31 +1000 (EST) Message-ID: <46A0E6E7.3050309@semihalf.com> Date: Fri, 20 Jul 2007 18:46:31 +0200 From: Rafal Jaworowski MIME-Version: 1.0 To: lokowich Subject: Re: SDRAM failures on MPC5200B References: <46A0D76E.4030101@acdstar.com> In-Reply-To: <46A0D76E.4030101@acdstar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sgpsmtp2.avagotech.com (bastion.smtp.avagotech.com [202.153.6.34]) by ozlabs.org (Postfix) with ESMTP id 7A104DDEC0 for ; Sat, 21 Jul 2007 07:53:47 +1000 (EST) Message-ID: <46A0EAEC.9010607@lpbroadband.net> Date: Fri, 20 Jul 2007 11:03:40 -0600 From: Frank Bennett MIME-Version: 1.0 To: lokowich Subject: Re: SDRAM failures on MPC5200B References: <46A0D76E.4030101@acdstar.com> In-Reply-To: <46A0D76E.4030101@acdstar.com> Content-Type: multipart/alternative; boundary=------------090408030606030908010805 Cc: linuxppc-embedded@ozlabs.org Reply-To: bennett78@lpbroadband.net List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------090408030606030908010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 _ _ > > 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 --------------090408030606030908010805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

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

--------------090408030606030908010805-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from asgard.akp-net.com (carangul.com [83.149.88.131]) by ozlabs.org (Postfix) with ESMTP id 43EFDDDE25 for ; Sat, 21 Jul 2007 03:13:31 +1000 (EST) Date: Fri, 20 Jul 2007 19:39:27 +0200 From: "Florian A. Voegel" To: lokowich Subject: Re: SDRAM failures on MPC5200B Message-Id: <20070720193927.858cd85b.fvoegel@carangul.com> In-Reply-To: <46A0D76E.4030101@acdstar.com> References: <46A0D76E.4030101@acdstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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 > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g2host.com (mailfront1.g2host.com [208.42.176.212]) by ozlabs.org (Postfix) with ESMTP id C8A36DDDFC for ; Wed, 14 Nov 2007 00:59:59 +1100 (EST) Received: from [74.95.143.41] (account lokowich@acdstar.com HELO [192.168.2.105]) by mailfront1.g2host.com (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 25093316 for linuxppc-embedded@ozlabs.org; Tue, 13 Nov 2007 07:59:54 -0600 Message-ID: <4739ADDC.8010402@acdstar.com> Date: Tue, 13 Nov 2007 07:59:56 -0600 From: lokowich MIME-Version: 1.0 To: linuxppc-embedded@ozlabs.org Subject: Re: SDRAM failures on MPC5200B References: <46A0D76E.4030101@acdstar.com> In-Reply-To: <46A0D76E.4030101@acdstar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.telemotive.de (mail.telemotive.de [62.206.149.210]) by ozlabs.org (Postfix) with ESMTP id A48A9DDDF9 for ; Wed, 14 Nov 2007 01:47:01 +1100 (EST) Received: from rfietze.mit.telemotive.de (rfietze.mit.telemotive.de [192.168.5.33]) by alderan.mit.telemotive.de (Postfix) with ESMTP id 5820F3CADC for ; Tue, 13 Nov 2007 15:40:19 +0100 (CET) From: Roman Fietze To: linuxppc-embedded@ozlabs.org Subject: Re: SDRAM failures on MPC5200B References: <46A0D76E.4030101@acdstar.com> <4739ADDC.8010402@acdstar.com> In-Reply-To: <4739ADDC.8010402@acdstar.com> MIME-Version: 1.0 Message-ID: <200711131540.18315.roman.fietze@telemotive.de> Date: Tue, 13 Nov 2007 15:40:17 +0100 Content-Type: multipart/signed; boundary="nextPart2504171.lkXzIyz8hA"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --nextPart2504171.lkXzIyz8hA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 =2D-=20 Roman Fietze Telemotive AG B=FCro M=FChlhausen --nextPart2504171.lkXzIyz8hA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHObdSp5XY/BK//MIRAu3oAJwNZr3d7SLG8LPeAjlP9wILJWiAcgCZAe9B ZfNos6EYsbDNJCfS6Y754Kk= =zqR0 -----END PGP SIGNATURE----- --nextPart2504171.lkXzIyz8hA-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g2host.com (mailfront1.g2host.com [208.42.176.212]) by ozlabs.org (Postfix) with ESMTP id 7E5BFDDE0F for ; Tue, 4 Dec 2007 03:01:58 +1100 (EST) Message-ID: <47542865.30308@acdstar.com> Date: Mon, 03 Dec 2007 10:01:41 -0600 From: lokowich MIME-Version: 1.0 To: Roman Fietze Subject: Re: SDRAM failures on MPC5200B References: <46A0D76E.4030101@acdstar.com> <4739ADDC.8010402@acdstar.com> <200711131540.18315.roman.fietze@telemotive.de> In-Reply-To: <200711131540.18315.roman.fietze@telemotive.de> Content-Type: text/html; charset=ISO-8859-1 Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,

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.


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?

This is message from Freescale to our HW engineer and was in reference to Figure 1 in AN3045

A design could avoid termination resistors if the trace delay is less than
1/6 of the rise fall/time, if the output impedance matches the trace
impedance or if the switching waveform is not so important (like PCI
synchronous signals). The first two conditions are not met for MPC5200B DDR
signals with 5 cm traces.

The MPC5200B memory controller's nominal output impedance is 22 Ohms (16..35
worst case range).
The nominal rise/fall time is ~400ps. However, worst case r/f time is about
200ps.

Thus, MPC5200B memory design must include signal terminations. The most
critical signals are memory clocks and DQS. The ringing on these signals (at
the threshold level) is not allowed.
The recommended series resistor value is 20..30 Ohms (may depend on the
load). 
Bidirectional signals (DQM) should have series termination at both ends of
data bus. It is common recommendation for MPC5200B memory design as well as
for MPC5200 Rev.A.

Lite5200B board doesn't follow these recommendations. This was done before
the importance of the correct termination resistors was known. A large
number of the issues people are having in moving from the MPC5200 to the
MPC5200B are caused by not using the correct termination resistors. The
Lite5200B board should not be used as an example.

Memory system design must ensure AC timing specs for MPC5200 and SDRAM.
Memory signals must have valid levels within setup/hold time window. The
ringing caused by the PCB trace reflections must be damped before the input
setup window begins. The ringing reduces time margins provided for signals.
Proper termination of the signal removes the ringing. 

Using proper series termination solves most issues caused by poor signal
integrity. In order to find optimal termination, use IBIS models of MPC5200
and SDRAM to simulate signal waveforms

Maybe I have to tell our HW people that it will be necessary to fix
our design as well.


Thank you

Roman


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded