Hi Ron, 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 <[email protected]> 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 input :-/ Thanks, Daniel -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
