Switch from flashrom to flashprog #1769
Conversation
tlaurion
force-pushed
the
flashprog
branch
4 times, most recently
from
af6e9ff
to
a4ef189
Compare
|
@JonathonHall-Purism need review and testing on Librems. |
|
Wow! 😮 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. |
|
@i-c-o-n comments in OP still needing feedback otherwise have to reach for community testing and more extensive testing from board owners. |
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 :) |
There was a problem hiding this comment.
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.
|
Adding https://github.com/linuxboot/heads/blob/master/BOARD_TESTERS.md's needing testing to OP prior of merging this PR |
|
Testing needed as per OP post:
|
|
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/ |
Thanks @srgrint will update PR ASAP, I will expect the same for all xx20. |
| endif | ||
|
|
||
| #Only enable AST1100 if requested per board configs | ||
| ifeq "$(CONFIG_FLASHPROG_AST1100)" "y" |
There was a problem hiding this comment.
Patch missing. Even i currently activated under server board and passed at make, doesn't o anything without https://github.com/linuxboot/heads/blob/master/patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/0100-enable-kgpe-d16.patch missing
There was a problem hiding this comment.
I can have a look at it. AFAIR, nobody made a real effort to upstream this. If I rebase this, we'd still need somebody to test it thoroughly. We are quite pedantic when it comes to internal flashing.
There was a problem hiding this comment.
@i-c-o-n it is a problem of upstreaming indeed, keeping track of patches downstream never proved to do any good.
If not under flashprog/flashrom: this means end users need to flash bmc externally which is not a desirable thing. Also as you may know, that bmc port is old but still in charge of best fan control out there for the d16. Having heads flash through https://github.com/linuxboot/heads/pull/1769/files#diff-08a8a9080a4ca4377e0de4dbef6bd94c84209343b4e12a8982352a1c1b09b71b would be useful.
That would be ideal, but not a blocker for this PR.
There was a problem hiding this comment.
@i-c-o-n do you see anything else that should be improved in the flashprog makefile for size/functionalities inclusion?
There was a problem hiding this comment.
Do you see anything that should be added in board config for flash options that should be passed? Something that would make speed of internal flashing faster?
Also not a requirement for this PR, but a nice thing to track in separate issue for improvements, let me know.
There was a problem hiding this comment.
@i-c-o-n do you see anything else that should be improved in the flashprog makefile for size/functionalities inclusion?
No, the current selection is already the minimum AFAICT. Anything else would need some hacking on the code. One low hanging fruit: For targets that use Intel hwseq or linux_mtd, you could drop everything else from flashchips.c. Haven't tried, but it probably won't link the chip drivers then.
Do you see anything that should be added in board config for flash options that should be passed? Something that would make speed of internal flashing faster?
--noverify-all gives you a little reading-speed advantage. But assuming that you update most of the flash anyway, it won't make much of a difference.
unmaintained_boards/UNMAINTAINED_t520-hotp-maximized/UNMAINTAINED_t520-hotp-maximized.config
Outdated
Show resolved
Hide resolved
unmaintained_boards/UNMAINTAINED_t520-maximized/UNMAINTAINED_t520-maximized.config
Outdated
Show resolved
Hide resolved
|
Haswell board owners, time to shine promptly Otherwise they will land as untested boards in the next days. |
Tagging linuxboot#692 by this commit log Signed-off-by: Thierry Laurion <[email protected]>
Signed-off-by: Thierry Laurion <[email protected]>
|
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: |
Also add Makefile helper to move from tested to unmaintained Done by: docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=x230-hotp-legacy board.move_tested_to_unmaintained docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=x230-legacy board.move_tested_to_unmaintained docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=x230-legacy-flash board.move_tested_to_unmaintained git difftool -d git add .circleci/config.yml boards/x230-hotp-legacy/x230-hotp-legacy.config boards/x230-legacy-flash/x230-legacy-flash.config boards/x230-legacy/x230-legacy.config unmaintained_boards/UNMAINTAINED_x230-hotp-legacy/ unmaintained_boards/UNMAINTAINED_x230-legacy-flash/ unmaintained_boards/UNMAINTAINED_x230-legacy/ git commit --signoff -m Signed-off-by: Thierry Laurion <[email protected]>
@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). |
|
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. |
…no known testers Repro docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=UNTESTED_w541-hotp-maximized board.move_untested_to_tested docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make BOARD=UNTESTED_w541-maximized board.move_untested_to_tested git status git add .circleci/config.yml boards/UNTESTED_w541-hotp-maximized/UNTESTED_w541-hotp-maximized.config boards/UNTESTED_w541-maximized/UNTESTED_w541-maximized.config boards/w541-hotp-maximized/ boards/w541-maximized/ git commit --signoff -m Signed-off-by: Thierry Laurion <[email protected]>
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. |
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. |
…pset Locking(PR0) to lock SPI access from Heads prior of kexec to main OS Signed-off-by: Thierry Laurion <[email protected]>
|
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.
We are not the same person. |
…541 (replacing prior @resende-gustavo) @gaspar-ilom still unresponsive, @gaspar-ilom and @ResendeGHF confirmed to not be the same person. Signed-off-by: Thierry Laurion <[email protected]>
@ResendeGHF 5cba23e commit message accurate? |
|
@pietrushnic is Dasharo considering switching to flashprog? |
…c FLASH_OPTIONS instead, might cchange in the future. Signed-off-by: Thierry Laurion <[email protected]>
Accurate. |
can confirm this works on kgpe-d16 and the #1778 patch works as intended aswell |
Signed-off-by: Thierry Laurion <[email protected]>
|
Updated OP #1769 (comment) 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. |
|
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.
|
This is from old to new firmware flashing, from a firmware version still showing Heads internal flashing progress bar. 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.
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 . EDIT: you flashed from a rom that WAS tagging t420 as untested. :) |
There was a problem hiding this comment.
Sorry, for the late reply. I think you tagged me six days ago. I am always willing to test the W541, but I cannot guarantee to do it as promptly as per your requirement. It is your decision whether you want to keep me listed as a tester here.
For the record the last few rounds of board testing I did test the W541 eventually. Personally, I also do not mind if the board is moved to untested and I create a PR after I tested it like I did here: #1750
That said, I understand your frustration with slow testing holding the project back. You know best whether it is worth keeping the board in spite of slow testing or not.
Yes, that was it. I was on an old rom :) Don’t worry, I enjoyed the improved progress bars flashing back to master 😎 |
|
@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. |
|
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 😄 |
Flashrom is unfit for a while:
See #1546 for more details leading for this work.
Unknows @i-c-o-n:
hwseq automatic or still needed on command line?yes. Added. oklegacy boards: internal flashing on --ifd specified bios region: ok? (deprecating soon legacy boards): deprecated, but should work.Tested with amazing progress bar output:
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: