[coreboot] GeodeLX RAM initialisation issue
daniel at caiaq.de
Fri Dec 4 18:12:44 CET 2009
thanks for your answer.
On Fri, Dec 04, 2009 at 09:03:14AM -0800, ron minnich wrote:
> On Fri, Dec 4, 2009 at 8:47 AM, Daniel Mack <daniel at caiaq.de> wrote:
> > No hint, anyone?
> Just about every time I had this problem on my geodes it was a problem
> with dram. Just about every time. It's quite weird how well DRAM can
> work even if it has not been programmed correctly. The correspondance
> with disable_car() might just be that there's lots of burst cache
> traffic to ram when you do this operation and cache is suddenly
> connected to dram again.
Help me understanding how the DRAM can be programmed correctly. Is it
about timing constraints?
> Also, over the years, we have frequently found that DRAM vendors are,
> well, less-than-honest about their product. One experience was on
> OLPC. We had three boards, all with nominally the same parts,
> different vendors however.
> Boards A&B worked with faster timing; Boards A&C worked with medium
> timing; and boards B&C only worked with the slowest timing. (I believe
> in this case it was ras to cas delay)
That could well be an explanation for what I'm seeing, however, I wonder
why all boards work totally stable once they booted. Wouldn't wrong DRAM
settings result in unpredictable behaviour such as sporadic fails? I
don't see anything like that.
> Rather than "power off for 10 minutes" -- I assume this is "at the
> wall plug" -- I wonder if you'd see an improvement if you yanked the
> DC power at the board. Which were you doing -- AC or DC power off?
I was unplugging the DC jack from the board. There is some blocking
capacitors on it, but I doubt they will cause any part of the system to
survive much longer than a couple of seconds. But even something like
10s doesn't solve it. Only sometimes though, and I haven't found a
reliable pattern yet. Damn, I really wish I could provide more specific
More information about the coreboot