On 11.11.2016 16:59, Charlotte Plusplus wrote: > Hello > > On Fri, Nov 11, 2016 at 7:53 AM, Nico Huber <[email protected]> wrote: > >>> After reading more about XMP and SPD, it is my understanding that : >>> - JEDEC specs stop at 1600, and after that XMP is required >>> - even before 1600, XMP also offers profiles, and they are not optional: >>> some memory is otherwise unable to work at its advertised speed >> >> This would mean the memory is just broken. But that's what I suspect of >> any memory that's supposed to run out of spec. >> > > 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.
You claimed that the XMP profile is non-optional for some modules. That's what I call broken (independently of coreboot). > > >>> - XMP profiles are some kind of overclocking: they usually require >>> adjusting the voltage, to deal with this increased speed >> >> Not kind of overclocking, simply overclocking. There's only one voltage >> specified for DDR3, IIRC. >> > > 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. > > It is stable, or it wouldn't be used in production by so many bioses. I have no idea about XMP adoption. So I can only guess: Those many BIOSes are a fraction of all BIOSes, which are a fraction of all PC firmware, which are a fraction of all firmware for PC-like devices... in the end a very tiny fraction in a world full of DDR3. > > >> JEDEC is the standard. If the XMP support is half-baked it should be >> disabled by default. Maybe we should even put a warning in the log if we >> encounter an XMP profile with anything else than 1.5V (if it's common >> that those DIMMs are broken ex factory). >> > > 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. Which either does not work if the board is not designed for it or would include hardware modifications. > > Likewise, we can't say that 99% of the DIMMs are broken. The XMP profiles > have been tested and validated. > > In my opinion, XMP should be a compile time option, defaulting to y, but > with a warning of possible ram errors. > > Most of the boards have a max_mem_clock_mhz at 933, which concerns me just > as much in terms of ram errors. > > 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. Which would open the path to brick your system by nvram settings. Not a feature of BIOSes that I'd want coreboot to adopt. > > 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) > > End result until XMP voltage can be adjustable in some way or another: > - most system will be unaffected > - unstable system can put max_mem_clock_mhz override to 666 or see if they > can get something better with manual SPD > - userland programs may automate that last part > - 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 > > It will also be very nice to have all that work without blobs. Agreed. > > Depending on the board the voltage might not be configurable at all. Why >> should it be if there is only one voltage defined in the standard? >> > > No, XMP calls for precise voltage. From wikipedia: > > bit 0 Module Vdd voltage twentieths (0.00 or 0.05) > bits 4:1 Module Vdd voltage tenths (0.0–0.9) > bits 6:5 Module Vdd voltage units (0–2) > > The standard call for the DIMM asking the system a specific voltage. It is > a negociation of speed, latency and voltage, cf > https://en.wikipedia.org/wiki/Serial_presence_detect#Extreme_Memory_Profile_.28XMP.29 > I know what it is. It's not the standard board manufacturers usually work with. > >> If the board can work at that frequency, that's just fine. If the >> voltage is a problem, it's due to the memory module. IMHO, the rule >> should be to ignore SPD frequency settings that include an out of spec >> voltage >> > > 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. > > >> If you want to do further testing, you can try to find out which com- >> binations of processor and DIMMs work with the Vendor BIOS or the MRC >> blob (I wouldn't expect that it supports non-JEDEC stuff, but it would >> be nice to know if something can be fixed in coreboot easily). > > > I tested the Lenovo bios in depth with memtest86. It works just fine. Which is a sign that the voltage setting isn't causing trouble. Since the W520 doesn't support anything beside 1.5V, as Patrick pointed out. > > 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) Enable CONFIG_USE_BLOBS and disable CONFIG_USE_NATIVE_RAMINIT. And you have to implement mainboard_fill_pei_data() in romstage.c (e.g. like kontron/ktqm77). If it's working, you can compare settings made by the blob and the native raminit with inteltool dumps. You can of course com- pare settings of the vendor BIOS too, but I'd expect less noise from the MRC blob. Nico > > 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. > > Thanks > Charlotte > -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
