From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] AMCC 405EX Trap
Date: Mon, 04 May 2009 10:58:41 -0400 [thread overview]
Message-ID: <49FF02A1.2020909@ge.com> (raw)
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F01B303F2BA@midas.usurf.usu.edu>
Jonathan Haws wrote:
>> On Thursday 30 April 2009, Jonathan Haws wrote:
>>> I am certain that it is a hardware failure that is causing the machine
>>> check because I can use the exact same binary on another (identical)
>> board
>>> and have it boot just fine. That tells me that all the EBC and SDRAM
>>> settings are correct;
>> From my experience you can't be sure that SDRAM setting are "currect" at
>> this
>> stage.
>
> Would that be the case on our other 6 boards then? We have 6 boards
> that are up and running with the exact same U-Boot binary file. If
> there was a problem with the SDRAM settings on one board, would not
> the other board show the same symptoms? That is the reason why I
> have not dug deeper into the SDRAM initialization. However, I will
> take your advice and do so, because if there is a problem there, then
> the other boards may be experiencing problems, just not to the extent
> that this one is.
>
>>> and that I am using the right addresses and chip
>>> selects for the data cache.
>>>
>>> Currently I am leaning toward an SDRAM problem because I get about a 20
>>> second pause when U-Boot tries to relocate to RAM.
>> Yes, I'm pretty sure that you have some SDRAM related problems. Either
>> configuration is non-optimal, or even (perhaps more unlikely) a hardware
>> problem. I suggest that you re-check the DDR2 autocalibration (method A &
>> B).
>>
>
> Thanks for confirming my initial hunch - problem lies in SDRAM. I
> will let you know what I find - whether it is a hardware or software
> problem.
>
> One thing I may mention is that we had the SDRAM chips re-balled
> before they were mounted on the board. Maybe something went wrong
> during that process on these chips on the problem board - who knows.
>
> Anyway, once I get this resolved I will post the solution.
>
> Thanks all!
>
> Jonathan
1) Six boards work, one board fails.
2) SDRAM chips re-balled on the failing board.
3) SDRAM failing.
That sounds like a hardware/assembly problem to me. My bet is a solder
problem. Have you (can you) x-ray the chips and verify the SDRAM
soldering is OK?
Best regards,
gvb
next prev parent reply other threads:[~2009-05-04 14:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 19:45 [U-Boot] AMCC 405EX Trap Jonathan Haws
2009-04-29 23:37 ` Grant Erickson
2009-04-30 14:34 ` Jonathan Haws
2009-05-04 7:53 ` Stefan Roese
2009-05-04 14:43 ` Jonathan Haws
2009-05-04 14:53 ` Grant Erickson
2009-05-04 14:56 ` Stefan Roese
2009-05-04 15:01 ` Jonathan Haws
2009-05-04 15:08 ` Stefan Roese
2009-05-04 15:12 ` Grant Erickson
2009-05-04 15:19 ` Jonathan Haws
2009-05-04 18:19 ` Wolfgang Denk
2009-05-04 14:58 ` Jerry Van Baren [this message]
2009-05-04 15:05 ` Jonathan Haws
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49FF02A1.2020909@ge.com \
--to=gerald.vanbaren@ge.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.