From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Kastner Date: Wed, 25 May 2005 12:58:25 +0200 Subject: [U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem In-Reply-To: <42944F6B.5020400@anagramm.de> References: <20050525094452.17432.qmail@web15905.mail.cnb.yahoo.com> <42944F6B.5020400@anagramm.de> Message-ID: <42945A51.8010203@marekmicro.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Sam, cooler spray might help find the cause, too. For example I once had a similar problem that looked like a SDRAM problem. In the end I found out that the oscillator sourcing the CPU's PLL input was a little weak and the CPU's internal PLL sometimes went crazy, causing this strange behaviour. Cooler spray on the oscillator marginally raised the slew rate and the system ran stable. Check the clocks, especially termination. If you have any chance to reduce the SDRAM clock rate, try that. Maybe by changing dividers in software or replacing a hardware oscillator. Generally speaking cooler spray has saved me a lot of time finding the cause of timing problems, so this really might be worth a try. Kind regards, Thomas Clemens Koller wrote: > Hi, Sam! > > As Wolfgang said, check the voltages, caps, terminations... > > You might also try to actively lower/rise the voltages of > your board/ram/... a bit. If your problem changes, I would > bet it's a hardware problem. > > Greets, > > Clemens > > Sam Song wrote: > >>-- Wolfgang Denk wrote: >> >> >>>>Thanks. Actually, it involves the grey area which >>>>a probelm was supposed to produce by hardware or >>>>software. The golden role is to check SW first. >>> >>>You must be one of these hardware guys who always >>>blame the software. >> >> >>Firmware guys is better to me. I amn't willing to >>be an native HW fellow although I come from HW >>field. To blame right is my hope. SW is only one >>side:-) >> >>[snip] >> >> >>>We've seen lots of "funny" problems with the many >>>boards we lay hands on. Three more things to check: >>> >>>* Check the voltages on your system: tolerances ok? >>>spikes or other noise on the lines? especially >>>close to the CPU? >>>* Check the clocks. Check the clocks again. >>>* check for unconnected pins, missing pull-ups or >>>-downs, or incorrect resistor values >> >> >>Ummm, this is really what I want. It seems I should >>look back more to take case HW side:-) >> >>Thanks so much, >> >>Sam >> > > -- Thomas Kastner Dipl.-Ing. (FH) Entwicklung Hard- und Software MarekMicro GmbH Fuggerstr. 9 D-92224 Amberg Tel: +49 96 21 / 97 32 - 124 Fax: +49 96 21 / 97 32 - 199 eMail: thomas.kastner at marekmicro.de http://www.marekmicro.de PGP: http://pgpkeys.pca.dfn.de/pks/lookup?search=0xA197D41B