Hi, Haswell coreboot maintainer and Haswell NRI author here.
If you encounter any problems with Haswell NRI, please open an issue in coreboot's bug tracker so that I can take a look. I've spent years working on coreboot's Haswell codebase (especially Haswell NRI), so I am very familiar with it.
I am afraid the patches in the haswell-patchset folder are not useful:
0002-device-dram-tck-1600-and-freq-table-docs.patch adds code for a 1600 MHz case. Which corresponds to DDR3-3200 (3200 MT/s) speeds (not supported by Haswell), NOT DDR3-1600. Comments mix up MHz and MT/s, and the "fixed" math does not consider where the values come from (they are not raw SPD values).0003-nb-intel-haswell-soften-a0-die.patch adds verbosity for naught. It is not worth accounting for all the differences in programming Haswell A0 needs (which are not limited to MRC/NRI; PCIe/DMI init also has some A0-specific details). However, that patch's commit message still says "tested"... Unless you actually own a Haswell A0 CPU, there is nothing to test.0004-nb-intel-haswell-early-guard-lpddr-ecc-no-dimm.patch misses the point: LPDDR3 support and ECC support are not yet implemented, as I do not have the hardware to actually test it. This also runs SPD processing twice, not taking into account how the code is supposed to work. Also, Haswell MRC.bin cannot possibly work with LPDDR3, even though the hardware should support LPDDR3; if you cannot figure out why, you should not be touching this.0005-nb-intel-haswell-fix-convert-timings-units.patch fixes absolutely nothing. If those timings were wrong in the first place, absolutely nothing would work.0006-nb-intel-haswell-add-s3-resume-schedule.patch actually breaks S3 resume, which has been working ever since this change got submitted.0007-Kconfig-Update-native-raminit-help-text.patch is not accurate. It is true the Kconfig help text was not updated when S3 resume support got introduced (which is why I just pushed a patch to fix this). However, NRI is capable of running RAM at speeds faster than DDR3-1600, although I do not recommend doing so given NRI's current state (not all training steps are implemented), because it is likely to result in instability. The part about ACPI S3 is absolute nonsense (hint: what is CBMEM?).
Unsurprisingly, haswell-patchset-README.md is a pile of nonsense. QEMU Q35 will not even build Haswell NRI so "testing" that is essentially useless. I see that there is a test harness in the repo, which is hallucinated. I looked at the MCHBAR cross-ref part and it was egregiously awful; I did not really look into the rest of the files.
I have seen something about some "fix" regarding a register value being different. If the information is actually correct, we're talking about training results being off by 1 or 2 ticks compared to MRC. Thing is, training is not an exact science so those values not being exactly the same is a non-issue. Especially considering that NRI does not implement all training steps.
So, given how well this research project seems to be going (nothing good out of it, and it does not look promising either), I would kindly ask you to please stop using generative AI on Haswell NRI's codebase. It is not doing the planet any favours.
Hi, Haswell coreboot maintainer and Haswell NRI author here.
If you encounter any problems with Haswell NRI, please open an issue in coreboot's bug tracker so that I can take a look. I've spent years working on coreboot's Haswell codebase (especially Haswell NRI), so I am very familiar with it.
I am afraid the patches in the
haswell-patchsetfolder are not useful:0002-device-dram-tck-1600-and-freq-table-docs.patchadds code for a 1600 MHz case. Which corresponds to DDR3-3200 (3200 MT/s) speeds (not supported by Haswell), NOT DDR3-1600. Comments mix up MHz and MT/s, and the "fixed" math does not consider where the values come from (they are not raw SPD values).0003-nb-intel-haswell-soften-a0-die.patchadds verbosity for naught. It is not worth accounting for all the differences in programming Haswell A0 needs (which are not limited to MRC/NRI; PCIe/DMI init also has some A0-specific details). However, that patch's commit message still says "tested"... Unless you actually own a Haswell A0 CPU, there is nothing to test.0004-nb-intel-haswell-early-guard-lpddr-ecc-no-dimm.patchmisses the point: LPDDR3 support and ECC support are not yet implemented, as I do not have the hardware to actually test it. This also runs SPD processing twice, not taking into account how the code is supposed to work. Also, Haswell MRC.bin cannot possibly work with LPDDR3, even though the hardware should support LPDDR3; if you cannot figure out why, you should not be touching this.0005-nb-intel-haswell-fix-convert-timings-units.patchfixes absolutely nothing. If those timings were wrong in the first place, absolutely nothing would work.0006-nb-intel-haswell-add-s3-resume-schedule.patchactually breaks S3 resume, which has been working ever since this change got submitted.0007-Kconfig-Update-native-raminit-help-text.patchis not accurate. It is true the Kconfig help text was not updated when S3 resume support got introduced (which is why I just pushed a patch to fix this). However, NRI is capable of running RAM at speeds faster than DDR3-1600, although I do not recommend doing so given NRI's current state (not all training steps are implemented), because it is likely to result in instability. The part about ACPI S3 is absolute nonsense (hint: what is CBMEM?).Unsurprisingly,
haswell-patchset-README.mdis a pile of nonsense. QEMU Q35 will not even build Haswell NRI so "testing" that is essentially useless. I see that there is a test harness in the repo, which is hallucinated. I looked at the MCHBAR cross-ref part and it was egregiously awful; I did not really look into the rest of the files.I have seen something about some "fix" regarding a register value being different. If the information is actually correct, we're talking about training results being off by 1 or 2 ticks compared to MRC. Thing is, training is not an exact science so those values not being exactly the same is a non-issue. Especially considering that NRI does not implement all training steps.
So, given how well this research project seems to be going (nothing good out of it, and it does not look promising either), I would kindly ask you to please stop using generative AI on Haswell NRI's codebase. It is not doing the planet any favours.