Switch Haswell boards to NRI (Native Ram Initialization) when resume from suspend works

[tlaurion]

NRI effort in Haswell was revived in June 2024.

• Track revived June 2024 patches https://review.coreboot.org/q/topic:%22haswell-nri-revived%22 until merged edit: wrong effort see
• Track whole NRI patchset at https://review.coreboot.org/q/topic:%22haswell-nri%22 until merged
• Have platforms owners involved
  • Have them report no S3 regression
  • Have them report no ram init speed regression
  • Accept PR
  • Merge PR

---

Most important being

• https://review.coreboot.org/c/coreboot/+/81897 for S3
• I guess the whole patchset being important for ram init being par if not superior in speed and stability when merged.

@srgrint thanks for your pointers at #1711 (comment)

[srgrint]

I think you probably want to track https://review.coreboot.org/q/topic:%22haswell-nri%22 rather than https://review.coreboot.org/q/topic:%22haswell-nri-revived%22

I think the haswell-nri patch train is actually Angel's more recent version. For example, it contains https://review.coreboot.org/c/coreboot/+/81897 which as I understand it is vital for working S3 resume.

[tlaurion]

I think you probably want to track https://review.coreboot.org/q/topic:%22haswell-nri%22 rather than https://review.coreboot.org/q/topic:%22haswell-nri-revived%22

I think the haswell-nri patch train is actually Angel's more recent version. For example, it contains https://review.coreboot.org/c/coreboot/+/81897 which as I understand it is vital for working S3 resume.

@srgrint thanks for your input. Modified OP accordingly.

[fhvyhjriur]

I am interested in testing NRI. I really do not like closed source software and the mrc.bin held me back for some years of getting a T440p(or W541). I did not like to have one more closed source part. Having one less closed source part in a computer is attractive advertisement. Having one more closed source part is bad reputation and should hold people back from getting the hardware.
Now i have a T440p after i find out the existence of NRI and already preflashed a existing maximized image to make it ready to install a NRI image.
Update: I flashed on T440p after initial Heads-flash with mrc.bin the latest libreboot release with NRI and it is working great.

[fhvyhjriur]

I see you added when ready upstream
Like i wrote above, i am using on a T440p now NRI thanks to Libreboot releases and its working great. Also ran memtest without any issues. What about you release in the next days Heads NRI images for people like me that do not want to run any additional closed source parts if there is any code that could somehow replace it?
At the moment the images for T440p (and W541) look like this:
heads-t440p-maximized-v0.2.0-2229-g7b0d995.rom
heads-t440p-hotp-maximized-v0.2.0-2229-g7b0d995.rom

After we changed the logic behind the naming of the UNMAINTAINED and added the additional UNTESTED here: https://github.com/linuxboot/heads/tree/master/unmaintained_boards , maybe in combination with the logic you use for the modded x230 heads also support ( x230-maximized-fhd_edp ) and combine both additions with the warning in README.md "Warning: Do not try to use UNTESTED_ images if you do not have a external flasher."

The image would be then named(following the examples above):
UNTESTED_heads-t440p-maximized-nri-v0.2.0-2229-g7b0d995.rom
Because the NRI code is not merged upstream but of course testing people are needed, heads could help upstream by releasing such images.
I know you do not like writing documentation/wiki that much. I could rewrite some part of the heads-wiki to implement the now missing UNTESTED and also UNMAINTAINED documentation to the wiki. There i can also write about the NRI-images and why they have UNTESTED in their filename and how to report the tests to coreboot upstream.

In heads the filename UNTESTED_heads-t440p-maximized-nri-v0.2.0-2229-g7b0d995.rom would change to normal heads-t440p-maximized-v0.2.0-2229-g7b0d995.rom (removing the mrc.bin and not mentioning the historic mrc.bin or mentioning NRI any more) when upstream coreboot also merged it (stable release). The default images would then have NRI and no additional images with more closed source software any more released.

[tlaurion]

@fhvyhjriur from OP

Most important being

https://review.coreboot.org/c/coreboot/+/81897 for S3

I guess the whole patchset being important for ram init being par if not superior in speed and stability when merged.

@srgrint thanks for your pointers at #1711 (comment)

@fhvyhjriur is suspend to ram (s3) working from libreboot with NRI? I said "once merged upstream" because as per past users reports, there were important regressions both on performance and features.

See planning of OP, I don't see myself patching coreboot 4.22.01, 24.02.01 or 24.05, maintaining patchset that is expected to change and cause regressions.

---

@fhvyhjriur : I would suggest using libreboot community and NRI actual users to collaborate upstream the same way you suggest Heads to do: they decided to include NRI which suffice the Prerequisites to have this collaborated into and facilitate patch testings as of now. Libreboot has faster coreboot version bumps and end users don't use their systems with security as a first goal.

To me, noted regressions on different fronts: performance, stability and lack of s3 is a no go for Heads as of now. I will stick to OP plan unless PR provided and maintained by board owners technical enough users to test and provide test results upstream, just like libreboot NRI users could do today. I am not enclined to test bleeding edge features under Heads and create NRI flavors of all haswell platforms as of today.

[tlaurion]

@Th3Fanbus (Angel from pending patchsets upstream): This issue is about users willing to test roms produced for a pointed commit I could create a PR against and for technical enough users to report back upstream under coreboot if that would help merging this faster, feel free to tag me.

Cross-post under coreboot matrix channel at https://matrix.to/#/!EhaGFZyYcbyhdSgStq:matrix.org/$sn5yonF4e3fJE4aCUGxfQv_xENoq80BeK6h5hqwQnHw?via=matrix.org&via=sibnsk.net&via=nope.chat

---

To @fhvyhjriur:

I could create testing PR in draft for you to test on a coreboot commit to be referred as testable by upstream devs; that is easy enough for me to do for one target to be tested if you are willing to take that task of communicating results upstream and if upstream is ready to push this forward. This is not my call and could be discussed with coreboot devs directly following my message there if you will.

A reminder that Heads is a coreboot user, where forks are coreboot devels maintained(Purism, Dasharo).

On community boards, we try to stay with upstream and collaborate where needed, where edp/fhd was a maintainership burden until it was merged.

Heads on community tested boards we are behind at least 2 releases most of the time because a lot of things break unfortunately and lack of testers to promptly test and report results, which that alone takes around 2 weeks each time and coreboot releases now being every 3 months...

So if this can happen upstream, I'm willing to modify modules/coreboot to use upstream coreboot + commit, modify one board target for it to use NRI and for you to take responsibility of reporting upstream if there is consent this is useful for them to push this forward. I have no clue of the priority of this for Angel nor have followed NRI improvements and status in libreboot.

But kepp in mind that once this is merged upstream, community boards will stay 2 releases behind until NRI is part of upstream fork and we can switch to NRI for all Haswell boards at once. Again, that unless I receive technical collaboration to move things forward on community work. This is a lot of work by itself and I try to follow Purism/Dasharo coreboot used versions where its impossible to support more and more forks without building time to explode and have more maintenance on my shoulders. Those are all important things to consider, but I hear your desire. I want NRI too. But not at the cost of what you propose me to do for you on community time, unfortunately. This is plainly irrealistic and I have other priorities.

[Th3Fanbus]

No. NRI is not production ready.

[fhvyhjriur]

@Th3Fanbus Great to see you following this thread. I want to thank you for the NRI Haswell code. This is what changed the situation for me to get a Haswell based device.
I think the most logical thing would be to ask you if you want people having a simplified (prebuild images) ability to run the heads code combined with NRI code and report using such images issues to you.
Or do you share the opinion that Libreboot prebuild images with NRI are enough for testing?

[Th3Fanbus]

I am not following this thread, I only got dragged into it because of tlaurion's ping. Yesterday's response was very short because it was late for me.

Although it should be usable (I recently implemented basic support for S3 resume in https://review.coreboot.org/81897 but note that it fails to account for DIMM changes), Haswell NRI is not yet complete. The missing parts are mainly optimisation steps to reduce power consumption and improve performance; while it is possible for a computer to boot without doing these steps, power/performance is not ideal (it is not too serious, though). Moreover, overclocking is completely out of the question for now: the system would be too unstable due to the missing training steps (especially without command training).

If I remember correctly, the then-current situation (I have not looked at it in a long time) regarding Libreboot is that they provide the choice to use MRC or NRI, with a warning that NRI is not complete yet. I also requested not to be contacted directly by end-users about issues as I do not have the time or energy to provide support on my own. I would suggest doing the same here, at least for the time being: if NRI does not work for some reason, one can use MRC to at least have a usable computer.

In order for any bug reports to be effective, I would require that the reporter be capable of building coreboot, reflashing the board and getting logs out of it on their own. Having to explain how to do this myself is wasteful (other people could explain it instead). Instead of that, I believe it would be great if projects making NRI available to end-users (in prebuilt firmware images and/or as a new build option) could triage NRI-related issues (get debug logs, system information, see if other people / boards have the same problem, etc) so that I can focus on what I can do best: figure out what the heck went wrong with my bowl of spaghetti code.

About topic:"haswell-nri-revived": I had temporarily withdrawn myself from coreboot due to mental health issues, and when I returned I saw that patch train. I never got any messages from the other patch train's author. I think this was quite rude (I felt as if I had been left for dead).

TL;DR:

• https://review.coreboot.org/q/topic:%22haswell-nri%22 contains the patches I am working on
• NRI is usable but not complete and should be considered experimental (use at your own risk)
• Overclocking including XMP (eXtreme Memory Profiles) is not supported (not enough training)
• For now it would be best to provide both options (MRC and NRI) in case there are any issues
• If there's issues, I'd appreciate if you could help triage (get logs/info, try to reproduce)

[tlaurion]

@Th3Fanbus aith current situation outlined at #1825 (comment) it might be a good moment for Heads to switch to NRI for t440p and w541 since augmenting CBFS region results in boot time of >50s with ram init from blobs borrowed from Chromebook.

Would you be willing to analyse cbmem logs provided by board testers if I do PR with testable roms directly built from CI if you point me to a coreboot commit you would like those users to test and iterate?

Otherwise Heads users will boot in >50s for those platforms until NRI is ready :(

TLDR: MRC not usable anymore for Heads, unless another round of optimization for space (a lot have been done there already... see #590)... gets funded.

[tlaurion]

Also note official opened issue on coreboot side which didnt get any real attention: https://ticket.coreboot.org/issues/457