[coreboot] More details about ram issues
pluspluscharlotte at gmail.com
Sat Nov 12 04:28:31 CET 2016
On Fri, Nov 11, 2016 at 5:32 PM, Nico Huber <nico.h at gmx.de> wrote:
> The XMP implementation just needs to be completed to also do > the voltage
> Which either does not work if the board is not designed for it or would
> include hardware modifications.
No it doesn't. The voltage is directly controlled by the CPU pins (cf infra)
> > No, XMP calls for precise voltage. From wikipedia:
> I know what it is. It's not the standard board manufacturers usually
> work with.
> > 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.
I don't know which standards manufacturers work with. Likewise, I can't
guess which voltage the W520 supports.
I am only basing myself on the specs. I read them the best I could, and I
stand by my conclusion.
On the W520 block diagram page 6, I see DDR3_VREF_CA and DQ comes from
RSVD#D1 and RSVD#B4.
I see the pinout name:
I see: " Memory Channel A/B DIMM DQ Voltage Reference:
These output pins are connected to the DIMMs, and are programmed to
have a reference voltage with optimized margin.
The nominal source impedance for these pins is 150 Ω.
The step size is 7.7 mV for DDR3 (with no load) and 6.99 mV for
DDR3L/DDR3L-RS (with no load). "
I interpret that as the CPU being directly in control of the voltage feed
to the DIMM, with 2 reference voltage 1.5 and 1.3V, that can be changed in
increments of 7mv.
So I don't understand why the CPU could not be giving say 1.6V in a DDR3
setting if the XMP profiles contains the information and the IMC is
instructed to do so, as it is what the XMP standard is for.
Maybe I fully misunderstand that. Yet googling for "cpuz ddr3" and looking
at the pictures, I see in the XMP profiles: 1.650V for the first 2 hits,
then 1.600V, etc.
This is just a random google search, but non 1.5V profiles do not seem as
rare as you think.
> 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
> > 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
I will do that. I have now received my FT232H and just 5 minutes ago I made
a debug cable (FT232H on one side, CP210X on the other side, total cost $15
if anyone else need a cheap debug cable). It seems to work just fine as I
get much more debug output than in cbmem.
It should help a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot