[coreboot] GeodeLX RAM initialisation issue

Marc Jones marcj303 at gmail.com
Fri Dec 4 18:30:21 CET 2009


On Fri, Dec 4, 2009 at 10:12 AM, Daniel Mack <daniel at caiaq.de> wrote:
> 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 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
> input :-/

I'm a little confused. Is the failure always at disable_car when you
do the flash programming? What does "the system most likely won't come
up immediately" mean? This description sounds more like the 5536 being
in a bad state, which may or may not have to do with RAM. I have heard
of problems with the 5536 getting locked up if power sequencing is not
exactly right. Does it work if you unplug, remove the cmos battery,
press the power button to remove any capacitance, then plug it back in
make it work?

If it always breaks at disable_car(), it could be a memory or cache
state problem that wouldn't be seen with the legacy BIOS because it
doesn't do CAR. It could still be hardware/power sequence related
since we don't see this on every platform.  As far as I know, the AMD
reference designs and the Artec mainboards don't exhibit this problem.

Marc

-- 
http://marcjonesconsulting.com




More information about the coreboot mailing list