Support #626
openHaswell Trad/T440p: Support for 16GB DDR3L modules with NRI?
0%
Description
There are rumors, that 16GB modules may be supported with NRI, even though the original BIOS nor the MRC blob support them in a T440p. I really wanted to test this myself, but unfortunately with limited success...
I have tested two different RAM modules over the last two months:
-
ZimaBlade - 16GB PC3L-10600S(returned to seller) - Micron MT16KTF2G64HZ-1G6A1 - 16GB PC3L-12800S
Both showed identical errors:
- The graphics output (via VGA) is mangled and unusable. Only a small "condensed" area is visible.
- EDK2 and memtest86+ start successfully (with the mentioned graphics issue), but memtest86+ crashes after a few seconds and causes a reset/reboot.
- GRUB2 loads successfully, but Debian (12/13) hangs at some point. Probably during kernel initialization.
The 16GB module from Micron starts up in other devices (Igel M340C + Lenovo T450s) without any problems and survives a memtest86+ over several hours. So it doesn't appear to be defective.
I then added various other 2/4/8 GB modules in addition to the 16GB module. Funnily enough, this changes the graphics output! Now every second line (each consisting of a few pixels in height) is displayed correctly. Unfortunately, this does not change the fact, that memtets86+ crashes and Debian can't boot.
I purchased a USB dongle (with a FT232H chip) specifically to read all Coreboot debug logs and have attached these along with my build configuration for v25.12!
I would like to know whether 16GB modules are really not supported in a T440p with NRI, or whether this could be a bug? I am happy to execute further tests or flash specific commits.
Files
AP Updated by Angel Pons 17 days ago
- Subject changed from Haswell/T440p: Support for 16GB DDR3L modules with NRI? to Haswell Trad/T440p: Support for 16GB DDR3L modules with NRI?
- Category set to chipset configuration
- Status changed from New to In Progress
- Assignee set to Angel Pons
- Priority changed from Low to Normal
- Affected hardware changed from T440p to Haswell Trad (e.g. T440p)
First of all, I feel I have to address the elephant in the room: are there any success reports of people using 16 GiB DIMMs on a Haswell Trad (traditional, i.e. not ULT) computer? For the record, I cannot magically work around hardware limitations.
Looking at the logs with the 16 GiB SO-DIMMs, they all have the following amounts of address bits:
Row addr bits : 16
Column addr bits : 11
After investigating, looks like Haswell Trad only supports 10-bit column addresses, so 16 GiB (SO-)DIMMs won't work on the T440p (or any other Haswell Trad board). I believe the mangled graphical output (which I assume comes from the iGPU) happens because one of the bits in the column address isn't driven by the memory controller.
The margins themselves look fine, even though NRI currently only implements a few training steps. https://review.coreboot.org/89314 (more training steps) got merged yesterday, feel free to give it a try but I highly doubt it will help, although seeing the plots from the new training steps will help me confirm or deny whether the margins are okay.
That being said, looks like ULT supports 10-bit and 11-bit column addresses (12-bit column address support is yet to be confirmed). This would explain why the same SO-DIMMs work on the T450s (Broadwell ULT).
TL;DR the modules aren't supported on Haswell Trad, and I don't think I can do anything about it (other than adding a check, to handle the error properly instead of booting with unstable RAM).
AP Updated by Angel Pons 17 days ago
Upon looking further into things, I think Haswell ULT only supports 11-bit column addresses for LPDDR3, not DDR3. However, Broadwell ULT might actually support 11-bit column addresses for DDR3. Broadwell Trad is out of the question for now since it currently doesn't work at all.
CS Updated by Christian Schrötter 15 days ago
- File 1772412470-c940d20-nri-16gb-top.fixed.log 1772412470-c940d20-nri-16gb-top.fixed.log added
- File 1772412665-c940d20-nri-16gb-bottom.fixed.log 1772412665-c940d20-nri-16gb-bottom.fixed.log added
- File 1772412740-c940d20-nri-16gb+2gb.fixed.log 1772412740-c940d20-nri-16gb+2gb.fixed.log added
- File 1772413121-c940d20-nri-2gb-bottom.fixed.log 1772413121-c940d20-nri-2gb-bottom.fixed.log added
are there any success reports of people using 16 GiB DIMMs on a Haswell Trad (traditional, i.e. not ULT) computer? For the record, I cannot magically work around hardware limitations.
Unfortunately not :-(
I am aware that it's not possible to fix a hardware limitation. I am just looking for confirmation that it's really a hardware limitation so that I can finally close this chapter. :-)
The margins themselves look fine, even though NRI currently only implements a few training steps. https://review.coreboot.org/89314 (more training steps) got merged yesterday, feel free to give it a try but I highly doubt it will help, although seeing the plots from the new training steps will help me confirm or deny whether the margins are okay.
I've built the main branch (commit c940d20696b4200bfa47c48f3f86a6d8f9ff6147), new logs attached.
Funnily enough, the graphic errors have slightly changed since my last 25.12 build if there's only the 16GB module installed. If you want, I can attach a photo tomorrow.
AP Updated by Angel Pons 14 days ago
Thanks for the logs. Margins look absolutely fine (yes, read timings have a bit of a positive offset, but I have seen this behaviour on all Haswell boards I've tried NRI on). I'm pretty sure this is a hardware limitation so the only thing left to do here is for me to add a check in NRI to check for non-10-bit column addresses and report that they're unsupported.
Aside: I have noticed that your logs say the following: SF size 0x2800000 does not correspond to CONFIG_ROM_SIZE 0xc00000!!
The T440p has 12 MiB of flash (8 MiB + 4 MiB), but the IFD is reporting a much larger size (40 MiB total, probably 8 MiB + 32 MiB). This means the flash component sizes in your IFD are misconfigured. This is not a coreboot issue and this should NEVER happen if you used the IFD that came with your mainboard. However, if you're using an IFD from some other source (e.g. you flashed a full libreboot image with a "cleaned" ME firmware), please check if they have already fixed this in an update, otherwise raise an issue in their bugtracker.
CS Updated by Christian Schrötter 14 days ago
Thanks for looking into it!
Aside: I have noticed that your logs say the following:
SF size 0x2800000 does not correspond to CONFIG_ROM_SIZE 0xc00000!!
The T440p has 12 MiB of flash (8 MiB + 4 MiB), but the IFD is reporting a much larger size (40 MiB total, probably 8 MiB + 32 MiB). This means the flash component sizes in your IFD are misconfigured. This is not a coreboot issue and this should NEVER happen if you used the IFD that came with your mainboard. However, if you're using an IFD from some other source (e.g. you flashed a full libreboot image with a "cleaned" ME firmware), please check if they have already fixed this in an update, otherwise raise an issue in their bugtracker.
Strange. I've never used Libreboot on any device, only self-built Coreboot ROMs with extracted blobs from original Lenovo BIOS flash. But I can't speak for the previous owner(s), I don't know what they've done to this device. I got it with an outdated BIOS and updated BIOS+ME before fiddling around with Coreboot...
Anyways, thanks for this hint! This is only my "naked" mainboard for various tests. I'll compare the IFD stuff with my real T440p daily-driver. (Which is still on v25.06 with NRI disabled.)
AP Updated by Angel Pons 14 days ago · Edited
Okay, false alarm: Nicholas Chin just let me know that the size reporting on Haswell / Lynx Point boards with 2 flash chips is consistently wrong. Looks like both coreboot and ifdtool decode the size wrongly.