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 daniel@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 input :-/
Thanks, Daniel