<div dir="ltr">Hello<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 11, 2016 at 7:53 AM, Nico Huber <span dir="ltr"><<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>></span> wrote:<span class="gmail-"></span><br><span class="gmail-"></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> After reading more about XMP and SPD, it is my understanding that :<br>
>  - JEDEC specs stop at 1600, and after that XMP is required<br>
>  - even before 1600, XMP also offers profiles, and they are not optional:<br>
> some memory is otherwise unable to work at its advertised speed<br>
<br>
</span>This would mean the memory is just broken. But that's what I suspect of<br>
any memory that's supposed to run out of spec.<span class="gmail-"><br></span></blockquote><div><br></div><div>I think it is a being too extreme. All of the ram sold, and most of what is being used contains XMP profiles. It is hard to say how much of the installed base may have problems when using XMP profiles without adapting the voltage since not many people use coreboot, and not many of those who use coreboot will be running memtest for hours.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
>  - XMP profiles are some kind of overclocking: they usually require<br>
> adjusting the voltage, to deal with this increased speed<br>
<br>
</span>Not kind of overclocking, simply overclocking. There's only one voltage<br>
specified for DDR3, IIRC.<span class="gmail-"><br></span></blockquote><div><br><div>It is indeed  Intel fault for rating the IMC only to 1600, and putting a hack on top of that to make RAM go faster. But they made this hack a standard, adopted by manufacturers. So it is not just overclocking in the usual sense. It is Intel and ram-manufacturers validated overclocking, where the XMP profiles contain speed settings + voltage, and negociate with the system to get this voltage. <br></div><br></div><div>It is stable, or it wouldn't be used in production by so many bioses.<br></div> <span class="gmail-"></span><br><span class="gmail-"></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>JEDEC is the standard. If the XMP support is half-baked it should be<br>
disabled by default. Maybe we should even put a warning in the log if we<br>
encounter an XMP profile with anything else than 1.5V (if it's common<br>
that those DIMMs are broken ex factory).<span class="gmail-"><br></span></blockquote><div><br></div><div>So many standards to chose from lol I wouldn't call the XMP support half baked. It is a very nice addition, as based on my understanding, some combination of chipsets + RAM may not even be able boot without XMP profiles. The XMP implementation just needs to be completed to also do the voltage part.<br><br></div><div>Likewise, we can't say that 99% of the DIMMs are broken. The XMP profiles have been tested and validated.<br><br></div><div>In my opinion, XMP should be a compile time option, defaulting to y, but with a warning of possible ram errors.<br><br></div><div>Most of the boards have a max_mem_clock_mhz at 933, which concerns me just as much in terms of ram errors.<br></div><div><br>I would suggest RAM settings to override that, and the selected SPD settings. This way that unstable settings detected in memtest86 can be adjusted in nvramgui  without having to recompile.<br><br><div>I will do more research to see if I can do that in userland (like 
MSR can be used for CPU overclocking, there must be a way to specify ram
 voltage)<br></div> <br></div><div>End result until XMP voltage can be adjustable in some way or another:<br></div><div> - most system will be unaffected<br></div><div> - unstable system can put max_mem_clock_mhz override to 666 or see if they can get something better with manual SPD<br></div><div> - userland programs may automate that last part<br></div><div> - when XMP voltage is supported (and 100 MHz for ivy bridge instead of 133 as Patrick noted, etc), coreboot will have gained much more flexibility in RAM initialization to deal with similar situations that may arise with new specs<br></div><div><br></div><div>It will also be very nice to have all that work without blobs.<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"><span class="gmail-"></span>Depending on the board the voltage might not be configurable at all. Why<br>
should it be if there is only one voltage defined in the standard?<span class="gmail-"><br></span></blockquote><div><br></div><div>No, XMP calls for precise voltage. From wikipedia:<br><br>bit 0
Module Vdd voltage twentieths (0.00 or 0.05)<br>bits 4:1
Module Vdd voltage tenths (0.0–0.9)<br>bits 6:5
Module Vdd voltage units (0–2)<br><br></div><div>The standard call for the DIMM asking the system a specific voltage. It is a negociation of speed, latency and voltage, cf <a href="https://en.wikipedia.org/wiki/Serial_presence_detect#Extreme_Memory_Profile_.28XMP.29">https://en.wikipedia.org/wiki/Serial_presence_detect#Extreme_Memory_Profile_.28XMP.29</a><br></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"><span class="gmail-">
</span>If the board can work at that frequency, that's just fine. If the<br>
voltage is a problem, it's due to the memory module. IMHO, the rule<br>
should be to ignore SPD frequency settings that include an out of spec<br>
voltage<br></blockquote><div><br></div><div>XMP is a specification. It should be supported. I think the only mistake is that the voltage part is not being applied. It's not out of spec, it's within another spec.<br></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">
If you want to do further testing, you can try to find out which com-<br>
binations of processor and DIMMs work with the Vendor BIOS or the MRC<br>
blob (I wouldn't expect that it supports non-JEDEC stuff, but it would<br>
be nice to know if something can be fixed in coreboot easily).</blockquote><div><br></div><div>I tested the Lenovo bios in depth with memtest86. It works just fine.<br></div><div><br></div><div>Could you give me some suggestions to use the MRC blob? I don't see anything like that in coreboot soure. (And actually, if it's a intel blob, I would expect that it will support XMP)<br><br></div><div>I will try to find a way to adjust the voltage from userland. I will do more test when I have either the blob thing or the voltage working.<br><br></div><div>Thanks<br></div><div>Charlotte<br></div></div></div></div>