<div dir="ltr">Hello<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 4:28 PM, Zoran Stojsavljevic <span dir="ltr"><<a href="mailto:zoran.stojsavljevic@gmail.com" target="_blank">zoran.stojsavljevic@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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-"></span>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><div><br></div><div>Edit devicetree.cb and set:<br><br>¬†register "max_mem_clock_mhz" = "666"<br><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 class="gmail_extra"><div class="gmail_quote"> <div></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></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>For the video init, the most plausible course of action is to see how the timings of the existing hardware initialization differ from say Xorg or the Linux Kernel, since the clock code is different and was found to be wrong on  another patch. I'm glad I have examples.<br><br></div><div>We don't have that with raminit.<br></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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-"></span><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></div></div></blockquote><div><br></div><div>It was made by 2 persons I think, based on some reverse work¬† <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 class="gmail_extra"><div class="gmail_quote"><div><br></div><span class="gmail-"></span><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></div></div></blockquote><div><br></div><div>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.<br></div></div><br></div></div>