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.42k stars 187 forks source link

Switch from flashrom to flashprog #1769

Closed tlaurion closed 2 weeks ago

tlaurion commented 2 months ago

Flashrom is unfit for a while:

See https://github.com/linuxboot/heads/issues/1546 for more details leading for this work.

Unknows @i-c-o-n:

Tested with amazing progress bar output: PXL_20240902_002217653.MP.jpg

Needs double flashing: reflashing within Heads to see if flashprog is able to flash again the firmware you had

Quick test for other boards untested:

tlaurion commented 2 months ago

@JonathonHall-Purism need review and testing on Librems. Can be tested under #1773

JonathonHall-Purism commented 2 months ago

Wow! :open_mouth: The progress bar shown in the video (in #1773) is extremely compelling to me. Thanks for this, I'm building the combined MR to test and will review now.

tlaurion commented 2 months ago

@i-c-o-n comments in OP still needing feedback otherwise have to reach for community testing and more extensive testing from board owners.

tlaurion commented 2 months ago

Wow! :open_mouth: The progress bar shown in the video (in #1773) is extremely compelling to me. Thanks for this, I'm building the combined MR to test and will review now.

Quick reminder that CircleCi builds for quick testing. This #1773 was just a staging PR containing all the pending changes to ease testing to reduce delays in functional testing results :)

tlaurion commented 2 months ago

Adding https://github.com/linuxboot/heads/blob/master/BOARD_TESTERS.md's needing testing to OP prior of merging this PR

tlaurion commented 2 months ago

Testing needed as per OP post:

srgrint commented 2 months ago

Have tested x220.

Unfortunately, it needs

export CONFIG_FLASH_OPTIONS="flashprog memory --progress --programmer internal:ich_spi_mode=hwseq"

Otherwise I get:

flashprog is free software, get the source code at https://flashprog.org/ Calibrating delay loop... ОК. coreboot table found at 0x7faf1000. Found chipset "Intel QM67". Enabling flash write... OK. Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) on internal. Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/M !!!!! Please specify which chip definition to use with the c option. /tmp/flash_gui/update_package/heads-x220-maximized-v0.2.0-2241-ge313c18-dirty.rom: Flash failed

tlaurion commented 2 months ago

Have tested x220.

Unfortunately, it needs

export CONFIG_FLASH_OPTIONS="flashprog memory --progress --programmer internal:ich_spi_mode=hwseq"

Otherwise I get:

flashprog is free software, get the source code at https://flashprog.org/ Calibrating delay loop... ОК. coreboot table found at 0x7faf1000. Found chipset "Intel QM67". Enabling flash write... OK. Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on internal. Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) on internal. Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/M !!!!! Please specify which chip definition to use with the c option. /tmp/flash_gui/update_package/heads-x220-maximized-v0.2.0-2241-ge313c18-dirty.rom: Flash failed

Thanks @srgrint will update PR ASAP, I will expect the same for all xx20.

tlaurion commented 2 months ago

@srgrint bd98101 rebased on master with hwseq in! Can you post results?

tlaurion commented 2 months ago
tlaurion commented 2 months ago

Amazing work. The progress indicator is awesome. Thank you so much for this @tlaurion 🙇

I tested Librem L1UM, 13v2, 14, and 11 (representing our range of chipsets pretty well) and all work perfectly.

@i-c-o-n : thank you for your great work and maintainership of flashprog!!!

srgrint commented 2 months ago

@srgrint bd98101 rebased on master with hwseq in! Can you post results?

Yes x220 works fine again with hwseq

By the way, I don't have access to my t440p for a few weeks. Hopefully one of your other testers will test haswell.

tlaurion commented 2 months ago

By the way, I don't have access to my t440p for a few weeks. Hopefully one of your other testers will test haswell.

Haswell board owners, time to shine promptly @ThePlexus @akunterkontrolle @rbreslow @resende-gustavo @gaspar-ilom

Otherwise they will land as untested boards in the next days.

i-c-o-n commented 2 months ago

Nice progress :)

  • xx20: hwseq automatic or still needed on command line? yes. Added.

In theory, we could check if the necessary registers are filled by firmware and then enable it by default. I assume some newer systems are not affected because we already default to hwseq when there are multiple flash chips. (And the newest don't support swseq anymore.)

  • legacy boards: internal flashing on --ifd specified bios region: ok? (deprecating soon legacy boards)

If it's all Intel-based Sandy Bridge or newer? then bios region should be fine.

No point verifying flash with internal programmer?

In general, verification is still useful with internal flashing to catch bugs in the application and hardware failure beyond transmission errors. On Intel systems, --noverify-all is needed though, when the ME region is read protected. --ifd -i bios --noverify-all is a common combination for Intel production systems.

tlaurion commented 2 months ago

Nice progress :)

  • xx20: hwseq automatic or still needed on command line? yes. Added.

In theory, we could check if the necessary registers are filled by firmware and then enable it by default. I assume some newer systems are not affected because we already default to hwseq when there are multiple flash chips. (And the newest don't support swseq anymore.)

@i-c-o-n : no problem, it was like that of xx20 before under flashrom, keeping it not an issue.

  • legacy boards: internal flashing on --ifd specified bios region: ok? (deprecating soon legacy boards)

If it's all Intel-based Sandy Bridge or newer? then bios region should be fine.

@i-c-o-n keeping it as it was for flashrom then.

No point verifying flash with internal programmer?

In general, verification is still useful with internal flashing to catch bugs in the application and hardware failure beyond transmission errors. On Intel systems, --noverify-all is needed though, when the ME region is read protected. --ifd -i bios --noverify-all is a common combination for Intel production systems.

@i-c-o-n awesome, that's what I got reading the docs. Heads changed so that failing flash prog results in getting into recovery shell in case of failing so all good as well under flash.sh 668f697

tlaurion commented 2 months ago

Double checking (without memory command line option from https://github.com/linuxboot/heads/compare/dd936d8d36111b7b905847fb6be98fbbe2e51cf8..668f6974645a11a5e47c02c07223b634d47289e8 change, rebased PR on master):

tlaurion commented 2 months ago

By the way, I don't have access to my t440p for a few weeks. Hopefully one of your other testers will test haswell.

Haswell board owners, time to shine promptly @ThePlexus @akunterkontrolle @rbreslow @resende-gustavo @gaspar-ilom

Otherwise they will land as untested boards in the next days.

Moved Haswell based boards to UNTESTED_ per fa9d14c, so owners without external programmers do not flash their platforms from master after this PR merge without explicit verbiage saying those roms were not reported as tested on those platforms. Those are still built from CircleCI when UNTESTED.

NOTE: this is why board testers with external programmers are needed for this project to thrive without leaving Pull Requests bitrot and more maintainer time (my time) because conflicts with other Pull Requests.

On next important PR merge without further testing of those UNTESTED boards, those UNTESTED boards will eventually be moved unmaintained_boards/ directories (and at that point, will not built by CircleCI because untested (considered unused-> not fit to my maintainer time because unused and not tested promptly when testing needed) until tested by board owners with external programmers, and them bringing back those now UNMAINTAINED boards back to tested with help Makefile helpers.

Hope this is clear. I cannot invest time in boards that are not used enough. If one thing that should come out of this is at least refresh the board testers list under #692. I consider the present boards owners list for Haswell platforms not responsive enoough and new board owners need sto step up. I cannot waste my time and permit newcomers to brick their platforms from CircleCI downloads because there is no testers to test PR content when needed.

tlaurion commented 2 months ago

Also moved talos-2 to untested. I'm the only known board owner and cannot invest time to thoroughly test this platform that nobody else uses until others show up under #692. This is a waste of my time (and also past financial investment)

tlaurion commented 2 months ago

Also moved talos-2 to untested. I'm the only known board owner and cannot invest time to thoroughly test this platform that nobody else uses until others show up under #692. This is a waste of my time (and also past financial investment)

Will do this seperately, commit log for reasons why https://github.com/linuxboot/heads/pull/1769/commits/05842f773366d262e35ab515caa026738ad524fd : tldr, board name hardcoded for different codepath, would need to be switched into better regex to include board name not be direct string matches.

tlaurion commented 2 months ago

No regression for currently supported platforms, even talos-2.

Asked for input from Dasharo team at https://matrix.to/#/!rsKWMJGPMsyPTTjXuh:matrix.org/$TiQytGPh1IU4Ucau-zhSTZTcqbiyyJyVRYnCHqhI4-w?via=matrix.org&via=nitro.chat&via=fedora.im

Once merged, should be integrated under #1753

natterangell commented 2 months ago

Out of country, can test t420 within 48 hours. Sorry for the late reply.

tlaurion commented 2 months ago

Out of country, can test t420 within 48 hours. Sorry for the late reply.

@natterangell thanks for caring but t420 is expected to work as x220. What is unsure now is w541/t440p which have already been moved to untested in this PR.

fhvyhjriur commented 2 months ago

Tested on T440p. Flashed with -p internal -w heads-UNTESTED_t440p-maximized-v0.2.0-2337-gf10ab57.rom from https://app.circleci.com/jobs/github/tlaurion/heads/53277, then boot into heads and went to settings, i changed the flash writing protection to disabled and saved the settings to SPI. Flashprog jumped in and wrote the modified settings to SPI. System is still booting fine and not bricked.

Would be nice to have any version numbering listed in flashprog instead of 'flashprog unknown on Linux ...'

fhvyhjriur commented 2 months ago

You removed the untested from T440p but let it at W541. The T440p and W541 are both Haswell. You told you need a single test on each cpu generation like one on Sandy Bridge, Ivy Bridge (probably tested on your x230) and one on Haswell. Thats why i did not do any tests on t420 because like you already told its already tested on x220. Why have you changed your mind about W541 or did you just missed that point that both are haswell?

You wrote here: https://github.com/linuxboot/heads/pull/1769/commits/bd7b1c86a464830a4442e5ac86dcca9e0ea04be4#diff-c9676b59bb507b9a6a8464e3ea34759f20950dcbd7fdf287048f8e800739496dR32 that its now tagged untested.

tlaurion commented 2 months ago

You removed the untested from T440p but let it at W541. The T440p and W541 are both Haswell. You told you need a single test on each cpu generation like one on Sandy Bridge, Ivy Bridge (probably tested on your x230) and one on Haswell. Thats why i did not do any tests on t420 because like you already told its already tested on x220. Why have you changed your mind about W541 or did you just missed that point that both are haswell?

You wrote here: bd7b1c8#diff-c9676b59bb507b9a6a8464e3ea34759f20950dcbd7fdf287048f8e800739496dR32 that its now tagged untested.

@fhvyhjriur it is still untested and needs other testers, doesn't it? I can move it back, but left a note under board testers. This platform is unused and is not worth my pings and waits and PR bitortting. It's the 4th time noone answers the call in time for w541. Who uses it is the real, unanswered question. I do not have time for this anymore i'm sorry. Muted users needs to voice themselves otherwise my caring is diminishing proportionally. So this is one user (I think those 2 usernames are the same person, unsure).

fhvyhjriur commented 2 months ago

Great to see finally the "legacy" moving to unmaintained. I like free software.

Humanity, please stop using the 1vyrain method and finally open up your hardware and flash the whole chips. The Intel ME crap have known security issues below the OS/UEFI code and you wont remove them when you do not remove the Intel ME. You are installing heads for privacy and security. It does not make any sense to then let the known broken closed source Intel software running the whole time you turn on the computer.

tlaurion commented 2 months ago

Great to see finally the "legacy" moving to unmaintained. I like free software.

Humanity, please stop using the 1vyrain method and finally open up your hardware and flash the whole chips. The Intel ME crap have known security issues below the OS/UEFI code and you wont remove them when you do not remove the Intel ME. You are installing heads for privacy and security. It does not make any sense to then let the known broken closed source Intel software running the whole time you turn on the computer.

Until then. It's unmaintained. Free software means also contributionnism from people who uses that free software, not just leechers and complainers when things doesn't work anymore with red lights from maintainer for years.

I cannot maintain unused stuff. Untested stuff. This is not the open source spirit either. Cannot support for ghosts.

If you have solution to propose I'm all ears. Otherwise, I do things with my maintainer hat. Believe me, I wish there were more active users and voices. But there isn't and my time and funds are limited. I leave things in a known working state for others to pick up as well. I'm not supposed to care more then users for all existing platforms, we discussed that already many times @fhvyhjriur. Convince FSF to care about open source firmware? I don't know the right angle anymore, I just know I cannot support things without known users.

Someone that cares enough can bring it back. Helpers are there in global Makefile. Commit messages shows how this was moved and can be moved back.

There is nothing much more I can do but give fishing lines here: not unlimited supplies of fish. Aho.

tlaurion commented 2 months ago

Great to see finally the "legacy" moving to unmaintained. I like free software.

Humanity, please stop using the 1vyrain method and finally open up your hardware and flash the whole chips. The Intel ME crap have known security issues below the OS/UEFI code and you wont remove them when you do not remove the Intel ME. You are installing heads for privacy and security. It does not make any sense to then let the known broken closed source Intel software running the whole time you turn on the computer.

I share your opinion. Ecosystem moved forward. Still, you could use 1vyrain and flash maximized builds as said elsewhere. But unsupported. If bricks : need external programmer. Meaning cannot be daily driver hence unsupported.

A reminder that builds from CI in master are expected to be usable by people NOT HAVING EXTERNAL PROGRAMMERS to constantly unbrick. So if boards are untested by people having external programmer, they should be marked as untested. And then moved to unmaintained. I hope we are clear once and for all. I won't support for boards variants without a single known, voiced user, anymore. And one user is not enough. Too much burden. Not enough usefulness. This is not Pareto compliant and worth my time. Not gonna care more then the community not even asking for it. No, one user is not a community; that user should be technical enough to have the board tested, and useful for others. This is what FOSS is about, if that wasn't clear, that is a clear statement of what FOSS is not.

So that's that. If there is suggestions into getting boards more tested and unvoiced board owners voiced: this iswhat i'm looking for. This PR is an important change, as where coreboot version bumps and kernel version bumps that need to be rtested on platforms. I cannot have this debate on each PR. I repeat, Haswell paltforms are less tested then others. This makes me unconfortable. dGPU boards went unsupported because untested. This is a reality. I cannot live in fantasy: I have somehow a responsibility that what lands in master is tested, and as the recent commit logs show; things are not enough tested and others forks depend on things being stable. There is a limit of what I can test and more work is not possible.

ResendeGHF commented 2 months ago

I've just tested on w541 board, from the CircleCI job #53413 for aad131b , and everything is working fine. I apologize for the delay with the testing. I needed the board and was concerned about having enough time to address any issues if the changes didn't work.

I will make sure to manage and ensure that such delays do not occur again.

So this is one user (I think those 2 usernames are the same person, unsure).

We are not the same person.

tlaurion commented 2 months ago

I've just tested on w541 board, from the CircleCI job #53413, and everything is working fine. I apologize for the delay with the testing. I needed the board and was concerned about having enough time to address any issues if the changes didn't work.

I will make sure to manage and ensure that such delays do not occur again.

So this is one user (I think those 2 usernames are the same person, unsure).

We are not the same person.

@ResendeGHF 5cba23e commit message accurate?

tlaurion commented 2 months ago

@pietrushnic is Dasharo considering switching to flashprog? Would need go/no go for this PR, all boards were tested working.

ResendeGHF commented 2 months ago

@ResendeGHF 5cba23e commit message accurate?

Accurate.

arhabd commented 2 months ago

Flashrom is unfit.

* No progress bar, leaving users in the dark, Heads gave up on his homemade progress bar because changes in flashrom verbose output, parsed for Heads to draw output constantly changes. Its not for Heads to maintain this. As of master, users left in the dark while erasing/writing to SPI. not cool

* Bricking with newer flashrom version for internal flashing for nv41... Probably also buggy with newer platforms. Not sure what's up with flashrom

* Commits missing in flashrom releases for WP on time of release

* Getting things merged under flashrom is problematic for a while.

See #1546 formore details leading for this work.

Unknows @i-c-o-n:

* xx20: ~hwseq automatic or still needed on command line?~ yes. Added.

* talos II: linux_mtd working? ok.

* ~legacy boards: internal flashing on --ifd specified bios region: ok? (deprecating soon legacy boards)~: ok.

Tested with amazing progress bar output: PXL_20240902_002217653.MP.jpg

Needs double flashing: reflashing within Heads to see if flashprog is able to flash again the firmware you had

* [x]  x230 : thanks @tlaurion

* [x]  nv41 : thanks @tlaurion

* [x]  one sandy result

  * [ ]  t420 (xx20): @alexmaloteaux @natterangell (iGPU) @akfhasodh @doob85
  * [x]  x220 (xx20): @Thrilleratplay @BlackMaria @srgrint : thanks @srgrint for testing once again [Switch from flashrom to flashprog #1769 (comment)](https://github.com/linuxboot/heads/pull/1769#issuecomment-2336744150)

* [x]  one haswell result

  * [x]  t440p: @ThePlexus @srgrint @akunterkontrolle @rbreslow : thanks to @fhvyhjriur [Switch from flashrom to flashprog #1769 (comment)](https://github.com/linuxboot/heads/pull/1769#issuecomment-2340479889)
  * [ ]  w541 (similar to t440p): @resende-gustavo @gaspar-ilom  : saved from becoming untested by @fhvyhjriur [Switch from flashrom to flashprog #1769 (comment)](https://github.com/linuxboot/heads/pull/1769#issuecomment-2341097328)

* [x]  talos-2 for linux_mtd : thankd @tlaurion

* [ ]  d16 (should work)

  * [ ]  kgpe-d16 (AMD fam15h) (dropped in coreboot 4.12): @Tonux599 @zifxify @arhabd

* [ ]  legacy-boards? If no answer, deprecate as part of this PR.

Quick test for other boards untested:

* download master zip artifcat from circleci for board, this pr zip.

* flash this pr zip

* flash master zip back. If successful, report success.

can confirm this works on kgpe-d16 and the https://github.com/linuxboot/heads/pull/1778 patch works as intended aswell

tlaurion commented 2 months ago

Updated OP https://github.com/linuxboot/heads/pull/1769#issue-2498854329

Waiting for approval/comments/concerns.

Started a thread for vPub today: https://matrix.to/#/!HAonmNlisbeoADmnrN:matrix.org/$SmBpUcZDlvATbUruP1sMfV16gZjEDIwVmm6Yi98n5cw?via=matrix.org&via=kit.edu&via=invisiblethingslab.com

Starts in one hour, should talk on this after 14:00 EST.

natterangell commented 2 months ago

Flashed heads-t420-hotp-maximized-v0.2.0-2343-gd5ddab5.zip from this PR and wrote back heads-t420-hotp-maximized-v0.2.0-2323-g3fef9e0.zip from master.

Works flawlessly!

PS! t420-hotp-maximized shows up as untested when flashing.

IMG_0023

tlaurion commented 2 months ago

Flashed heads-t420-hotp-maximized-v0.2.0-2343-gd5ddab5.zip from this PR and wrote back heads-t420-hotp-maximized-v0.2.0-2323-g3fef9e0.zip from master.

Works flawlessly!

IMG_0023

This is from old to new firmware flashing, from a firmware version still showing Heads internal flashing progress bar. PXL_20240902_002217653.MP.jpg

The goal of this testing is double flashing, meaning you have to flash something FROM this PR. Flashing the same ROM is ok.

Please redo.

PS! t420-hotp-maximized shows up as untested when flashing.

Will check, meaning boardname is untested. With your update, can move to tested @natterangell

Output should look like OP's screenshot on second flash, from within that new firmware being flashed @natterangell . Hopefully other testers reported success on this premise.

EDIT: you flashed from a rom that WAS tagging t420 as untested. :)

natterangell commented 2 months ago

EDIT: you flashed from a rom that WAS tagging t420 as untested. :)

Yes, that was it. I was on an old rom :)

Don’t worry, I enjoyed the improved progress bars flashing back to master 😎

tlaurion commented 2 months ago

@JonathonHall-Purism do we merge and deal with ecosystem switching to flashprog /not switching/ reverting to flashrom later if needed?

Seems like we won't get feedback here. Feel free to merge.

tlaurion commented 1 month ago

https://github.com/Dasharo/dasharo-issues/issues/1060#issuecomment-2374274054

Patch needed

i-c-o-n commented 1 month ago

Dasharo/dasharo-issues#1060 (comment)

Patch needed

https://review.sourcearcade.org/c/flashprog/+/259

Should probably put more work into auto-detection... I'll try to get everything merged over the next weekend, then you can pull from the main branch :smile:

tlaurion commented 3 weeks ago

This is where I don't know how to act. https://review.coreboot.org/c/flashrom/+/84102 is still unmerged while flashprog works for all platforms, producing needed progress output as well.

@macpijan @SergiiDmytruk what do we do? Blocker for https://github.com/linuxboot/heads/pull/1753 as well.

macpijan commented 3 weeks ago

We have used flashrom mostly so far, not flashprog, but if it works better for you, we do not mind. Do you need us to test something with flashprog?

tlaurion commented 3 weeks ago

We have used flashrom mostly so far, not flashprog, but if it works better for you, we do not mind. Do you need us to test something with flashprog?

My personal preference for forks are for ones that are listening to downstream needs: here Heads is a downstream user of flashrom/flashprog that needs to be stable, functionally equivalent and provide proper UX not aimed at geeks but more and more non-technical end users under Heads umbrella.

@macpijan

Do you need us to test something with flashprog?

Not specifically: This PR proved its point where https://review.coreboot.org/c/flashrom/+/84102 and whole https://github.com/linuxboot/heads/pull/1753 discussion with patches missing under flashrom, and versions not including some patches at time of release, releases breaking compatibility with older platforms and the lack of progress output consideration from upstream for 2+ years under https://ticket.coreboot.org/issues/390 are all reasons for me to want tot get away of flashrom ASAP if possible.

My question is more: what project do we want to use and promote. And then, if I switch to flashprog, does it generates a veto or not?

This is where I don't know how to act. https://review.coreboot.org/c/flashrom/+/84102 is still unmerged while flashprog works for all platforms, producing needed progress output as well.

I just need understanding of the situation, where @i-c-o-n clearly surpassed my expectations in the past and moves things forward and fast and stabler then flashrom. This is actually why the project was forked. Again not wanting to go political, but this is why projects fragments: right? When things don't advance as fast as expected downstream: this is why projects gets forked, amongst many other reasons of course. Eg: why Heads tends to rely on more forks of coreboot then upstream for recent platforms. I am reluctant to change from flashrom to flashprog for political reasons, not technical ones.

@macpijan If you are confortable, please approve PR. :)

tlaurion commented 3 weeks ago

TODO:

tlaurion commented 3 weeks ago

@macpijan change of mind since input from @SergiiDmytruk at https://github.com/linuxboot/heads/pull/1753#issuecomment-2433527375? I really don't know what do do with this fragmented ecosystem and need advice, really.

i-c-o-n commented 2 weeks ago
  • [ ] have confirmation with @i-c-o-n that the commit pointed under modules/flashprog is good for now/newer commit without regression expected for tested boards should be used (link to current review)

Current commit pointer looks good. I have plans to go over the patches on the wp_cli branch one more time this week and then merge to main. But I don't see a reason to wait for that.

tlaurion commented 2 weeks ago

Tested on optiplex after rebasing on master: working.