<div dir="ltr">Hello Charlotte ++,<div><br></div><div>Forgive me/apologies for my ignorance in some parts... I would like to ask few questions since I am not clear on some data here.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 8:30 PM, Charlotte Plusplus <span dir="ltr"><<a href="mailto:pluspluscharlotte@gmail.com" target="_blank">pluspluscharlotte@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>I have had similar issues with Corsair ram on the W520 recently: sometimes not booting at all, sometimes being unstable (in memest) after a succesfull raminit.<br><br></div>The only way I could get the 4 dimms to work was to hardcode some SPDs, or set the MCU to a much slower speed.<br></div></div></blockquote><div><br></div><div>As I know (and knew) MCU stands for MicroCode Unit (INTEL terminology), or Memory Controller Unit (common terminology), and I am sure you do refer to later, since to former this does not make too many (not at all) sense (to me, at least).</div><div><br></div><div>If MCU is former, could you, please, explain the following: <i><u>"set the MCU to a much slower speed"</u></i>?</div><div>If MCU is later, could you, please, explain how you did this in IVB Coreboot code (since this might be beneficial to Federico's attempts)?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Like you, I found removing even 1 stick did help a lot: the raminit succeeded much more frequently as a higher MCU, even if this MCU still lower than the one the RAM is rated for, or that worked in the factory bios.<br><br></div><div>I tried using the MRC blob to compare the timings, but I must have done something wrong in my code as it didn't work at all.<br></div></div></blockquote><div><br></div><div>Here I understood that you tried to compare IVB raminit.c source code with MRC algorithm, embedded in BIOS itself. And I have here one ignorant question: what is the difference between IVB (I assumed in this case SNB (tock), since I could not find IVB (tick) in rc/northbridge/intel/) raminit.c source code and MRC from IVB BIOS (there MUST be some difference, it is obvious, doesn't it)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>My guess is something is really wrong in the raminit code. I read up too much specs and code for no result, so I just gave up on this.<br></div></div></blockquote><div><br></div><div>This is exactly the main point! And the main question here is the following: who wrote raminit.c code, and does this person did it using parts of IVB/SNB MRC source code? In other words, was this person member of SNB BIOS team from INTEL CCG?</div><div><br></div><div>This is much more question directed to INTEL people (IOTG and CCG) observing this thread. Also to Ron (Minnich). Or anybody else from Coreboot knowing the answer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hopefully more people getting similar problems will mean the MRC will be added back as an option next to the native raminit. This would facilite comparison on all boards, and identification of whatever bug there may be. (imagine figuring out native video init issues if there was no way to use a VGA option rom)</div></div></blockquote><div><br></div><div>This is also a good point. I need clarification on the following:<i><u> "...will mean the MRC will be added back as an option next to the native raminit"</u></i>. Do you mean to have IVB/SNB MRC binary blob with defined APIs to be used as alternative to IVB/SNB raminit.c, since I am certain INTEL will not allow to have complete MRC added in Coreboot as source code (never was, never will be)?</div><div><br></div><div>Thank you (and everybody else) in advance for clarification (answers to these questions),</div><div>Zoran</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-HOEnZb"><font color="#888888"><div>Charlotte</div></font></span></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 8:22 AM, Andrey Korolyov <span dir="ltr"><<a href="mailto:andrey@xdel.ru" target="_blank">andrey@xdel.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-2645310689950910516HOEnZb"><div class="gmail-m_-2645310689950910516h5">On Tue, Nov 22, 2016 at 3:35 PM, Federico Amedeo Izzo<br>
<<a href="mailto:federico.izzo42@gmail.com" target="_blank">federico.izzo42@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> I have a problem with my ThinkPad X201 (nehalem)<br>
><br>
> I have two sticks of Samsung 4GB 2Rx8 PC3-10600S (1333MHz)<br>
> When i use only one of them in one of the two slots, the computer boots<br>
> fine,<br>
> but when i use both of them in the two slots, the computer doesn't boot,<br>
> the screen doens't even turn on.<br>
><br>
> I dumped the logs via EHCI but they seem normal, in fact both the<br>
> working combination and the broken one make 34 or so iterations of<br>
> Timings dumping,<br>
> but then the working conf. start booting, while the broken one freezes<br>
> without printing error messages on the EHCI.<br>
><br>
> I have tried adding more `printk` calls in<br>
> `src/northbridge/intel/nehalem<wbr>/raminit.c`<br>
> but ended up in a brick, probably because i slowed down the<br>
> initialization too much.<br>
><br>
> I attach three EHCI logs:<br>
> - the first stick in the first slot: working<br>
> - the second stick in the second slot: working<br>
> - both stick inserted: not working<br>
><br>
> Also i find difficult to understand the code in `raminit.c` of nehalem<br>
> because it lacks almost completely of comments, with respect to<br>
> raminit.c of sandybridge for example.<br>
<br>
</div></div>I`ve seen simular issue on my x201(t), the workaround could be a<br>
hardcoded SPD limitation from above for memory clock speed. Using<br>
different memory sticks (Kingstons rather than Samsungs) is 'solving'<br>
problem as well. I`ve not paid necessary attention to the problem at<br>
the time, so if you have some spare cycles, you could possibly want to<br>
figure out right SPD settings. The simplest way is to use decode-dimms<br>
from i2c-tools or CPU-z and to compare vendor`s settings with single-<br>
and dual-dimm setups and coreboot`s with a single dimm.<br>
<div class="gmail-m_-2645310689950910516HOEnZb"><div class="gmail-m_-2645310689950910516h5"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailm<wbr>an/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div></div>