[coreboot] Nehalem not booting with two ram sticks

[Zoran Stojsavljevic]

Hello Charlotte++,

On Wed, Nov 23, 2016 at 2:40 AM, Charlotte Plusplus <
pluspluscharlotte at gmail.com> wrote:


> Edit devicetree.cb and set: register "max_mem_clock_mhz" = "666"
>

Good to know! Thank you for the tip, so Federico can try quick check and
see if this does work as workaround for now. :-)

Federico, I have here also suggestion for you. You should try to run only
one DDR memory stick, and then record the memory values (since I see from
your logs that they are identical for both memories/DDRs), and then to try
to hard-code them for both sticks, altogether avoiding raminit.c setup, and
see if this improves your situation?!


> I suppose there is one. I don't know. I want to investigate. I will
> certainly try again by adding the patches suggested by Kyosti. As soon as I
> can get the MRC blob to work, I can make some better guesses about what is
> going wrong (I tried so many various things already) by having some
> reference points.
>

Please, keep us in the loop. I really enjoy reading your posts. They are
very technical, and very instructive. They force me to think, and recall
various things I did once upon a time (referring to Y2012/Y2013).

At the moment, I want to make a first public commit  for the W520, but with
> the RAM issues (only stable with the MCU at 666), and no native video init,
> and the power consumption issues, I'm not sure how helpful it will be.
>

YES, of course, it will be/is VERY/extremely helpful. You did excellent
job, paving path to other platform yet, and leaving to the community to fix
these bugs.

Yeah, the blob. I don't like blob, but I like to have the option of
> something that works if I need to investigate why something else is not
> working. Or just for an initial release.
>

You are talking about SNB/IVB MRC blob, I have noticed. About this blob
(beneath), correct?
_______

*This change was committed on Apr. 5th, 2012 into the main coreboot git
repository. In fact, if you going to look into directory:*

*…/src/northbridge/intel/sandybridge/raminit.c you'll see the following:*

*http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/intel/sandybridge/raminit.c;h=696417f1615621bc9118c92b4717ce4afdcb4e5a;hb=HEAD
<http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/intel/sandybridge/raminit.c;h=696417f1615621bc9118c92b4717ce4afdcb4e5a;hb=HEAD>
*

*Please, find the line 213:
void sdram_initialize(struct pei_data *pei_data)*

*And then, the line 245:
entry = (unsigned long)cbfs_find_file("mrc.bin", 0xab);*

_______

Yup, this was the MRC blob and the commit you are referring to, back then
in April 5th, 2012. This was the MRC SNB BIOS blob developed (my best
guess) by some BIOS CCG group for Coreboot/Google. And I also guess, this
one was reverse engineered by two of Google people (Vladimir Serbinenko
somehow comes to my mind). ;-)

Kyosti, my best guess is that you can find this patch/original SNB MRC blob
API code, and blob itself, can you (since Charlotte++ would like to
experiment with it)?

Thank you all for refreshing my old, patchy, full of black holes brain,
giving me the hope that I can (much) better organize huge DATA info
scattered all over my mind! :-)

Zoran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161123/0aaaf693/attachment.html>