Feature #56


16GB DIMM support on Sandy/Ivy Bridge

Added by Iru Cai about 6 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:


The first 16GB DDR3L was released last year, and for Intel platforms, only Broadwell and some Atom SoCs support it. However, in the compatibility list[2], it is said that many existing boards that supports DDR3 support 16GB DDR3L, and CPUs on X79 boards can support it with a modified MRC. So I think it's possible to be supported on a Sandy/Ivy Bridge machine.

The raminit logs show that coreboot does the memory init, and the code in romstage that should be run in memory works fine, but it crashes on payload stage.

(The following is what I wrote on the mailing list)


I'm tesing to see if the coreboot Sandy/Ivy MRC supports 16GB DIMMs. Here's my result.

I'm using a MT16KTF2G64HZ-1G6A1[1]. My machine is Lenovo T420 with i7-3630QM. With this module inserted (I've tested 16G+0 and 16G+8G), the system can light up, but it'll then get crashed.

  • with GRUB2 payload, it'll crash after the payload loads
  • with SeaBIOS payload with proprietary VGABIOS, I can see the prompt, and can boot to a GRUB or syslinux loader on my USB stick, but when I try to boot a system, it get crashed. If I boot to Memtest86+ on my USB stick, the system will crash when memtest starts to test the memory.

And another thing I can see is, the first boot can boot to payload, but the second boot will fail. I think it's caused by the MRC cache.

I'm still wondering if Sandy/Ivy northbridge can support 16GB DIMMs. I'll give a more detailed EHCI debug output later. According to [2], I think the incompatibility is an MRC issue instead of hardware incompatibility.



ehci.log (344 KB) ehci.log The boot log on the first boot Iru Cai, 05/31/2016 12:38 PM
ehci.log.2 (156 KB) ehci.log.2 The boot log on the second boot Iru Cai, 05/31/2016 12:38 PM
Actions #1

Updated by Patrick Rudolph about 6 years ago

My guess is that the DRAM address pin for 16GB DIMMs is missing. Please try to modify raminit and fake a 8GB DIMM.
The same could be achieved by modifing TOM, TOUUD, MEBASE, REMAP, ....
If the payload is working, it's a hardware bug.
The raminit seems to work fine.

I don't know if 16 GB DIMMs have been tested by the vendor. I guess not.

Actions #2

Updated by Arthur Heymans almost 5 years ago

This also happens on older controllers (intel 4 series) when unsupported RAM is used. Raminit succeeds because during raminit all ranks are mapped as 128M? ranks which does not present the issue of not addressable ram (which I think causes the crashes). On Intel 4 series faking lower sized dimms worked to some extend: it boots Linux and is usually workable (but locks up in memtest86+ after ~12min).

Datasheets say only 4G technology is supported (so 8G for dimms with 2 ranks) and I doubt it can be worked around.

Let's close this one?

Actions #3

Updated by Patrick Rudolph almost 5 years ago

It would be easier to have a working platfrom (X79) and then reverse engineer or test coreboot on that platform.


Also available in: Atom PDF