search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.4k stars 181 forks source link

Switch Haswell boards to NRI (Native Ram Initialization) when ready upstream #1711

Open tlaurion opened 3 weeks ago

tlaurion commented 3 weeks ago

NRI effort in Haswell was revived in June 2024.

Most important being

@srgrint thanks for your pointers at https://github.com/linuxboot/heads/issues/1711#issuecomment-2206793780

srgrint commented 3 weeks ago

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 commented 3 weeks ago

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 commented 1 week ago

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 commented 2 days ago

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-fhdedp ) 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 commented 1 day ago

@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 commented 1 day ago

@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 commented 1 day ago

No. NRI is not production ready.

fhvyhjriur commented 1 day ago

@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 commented 1 day ago

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: