Notices by Thierry Laurion (tlaurion@infosec.exchange)

@libreleah
https://github.com/linuxboot/heads/blob/master/patches%2Fcoreboot-24.12%2F0004-do-not-break-building-other-thinkpads-with-the-hacks.patch

@libreleah

My point, here again dismissed, I don't know why, is that there is "black magic" or a "voodoo dance" that is not needed in libreboot flashing documentation for t480 (and I expect the same for t480s).

Science/engineering requires to repro things. t480 board owners, and myself challenging libreboot instructions, concluded that it was not needed to do aforementioned steps (erase spi through flash tool, then flash zeroed file, then tb.bin which is the only step needed, really), point still dismissed in your previous answers: stating libreboot docs can be referred as is. They should be corrected, and then Heads could refer to libreboot docs.

By lack of possible collababoration with libreboot, with attempts (plural) by board owners to chat in libreboot channel, me here: Heads documentation for t480 removed unneeded steps, board owner hacked upstream patchset used under libreboot. And this is why I call for upstream collaboration in the future.

I repeat, in this case, upstream code reference is libreboot until coreboot merges code. Documentation is libreboot for now until there is effort upstreaming our docs under coreboot docs: https://doc.coreboot.org/

Heads effort on t480 will not extend to t480s because there is no board owner technical enough that showed leadership to redo what was done for t480 (40h of unpaid/properly compensated time on my side here), while future might be brighter with mentorship done here, while I do not have the board nor plan to have all coreboot supported boards: Heads is a community effort; Heads requires technical board owners to take port lead/co-maintainership to thrive and propel other boards ports. In that regard, Heads is a coreboot payload; a linux based bootloader replacement with its own features and agenda. I repeat once more; there needs to be proper seperation of duties and understanding of who does what. Heads is not coreboot/libreboot/skulls as those are coreboot distributions packing already supported payloads; Heads is that payload with its own buildsystem to arrive to that goal, with reproducible build approach where roms are built reproducibly from CI is a directly flashable form. Heads doesn't pretend to be a coreboot distribution in the large sense of things, but needs to build coreboot to have its payload stitched in it, alongside all other blobs needed to have fully externally flashable roms/internally upgradable roms. Therefore, Heads needs to collaborate upstream/downstream for all its dependencies/forks/OEMs/rebrandings and time is limited.

TLDR: my suggestion, not demand, is that libreboot reviews its documentation for t480 in regard of tb.bin flashing from downstream Heads effort, which corrected the facts with lots of duplicated effort, reviews, iterations to arrive to its merged state, including participation upstream where it was possible.

Correction of facts:
This is not something personal, caprice. Its politics. To better the ecosystem if the real goal is to make this easy for users to flash, code to review/better, use, and ease support without constantly reinventing the wheel, duplicating efforts, etc. Otherwise we won't fill what I still believe is our common vision: to have coreboot on a maximum number of platforms out there, while easing developers onboarding on our projects. We need to unite here, not be enemies picking stupid ego fights. We need to take time and reflect on what we do and how we do it, if, of course, the mission is aligned with vision.

@libreleah @mkukri

Note that the guide doesn't instruct users to
- Stay on UEFI, disable battery, adaptive usb from UEFI menu
- Use flashrom to erase spi content
- Flash a zeroed file
- Then flash tb.bin

Documentation was duplicated since it was not possible to discuss those matters so Heads could refer to libreboot docs. Again duplicating efforts.

IDelaly, flashing docs should be under coreboot docs, not repeated into all downstream coreboot distribution. We don't do anything different here then
- Disassembling instructions for boards, CMOS battery position and battery wiring position.
- Point where SPI chips are, their form factor and clip/probe sizing and voltage range of all SKU for same board (newer platforms have SPI chips for same model ranging from 1.8v to 3.3v and should be considered in the future).
- Instruct to use a programmer of choice (not to be duplicated in each board instructions, referred to instead) to flash those chips.

Upstream should document those things for all coreboot boards supported, not us. Downstream projects should refer to that upstream doc.

I think we should collaborate in that goal. Otherwise its just too much duplicated work. Even boards in our downstream work duplicate parts of the same docs across boards.

This is in my opinion, a lack of time to do more important things. Note that I'm not using must, but should. I'm not doing demand, just speaking from my experience, sharing knowledge and trying to collaborate, not create drama.

@libreleah @mkukri I'm. Sorry if I hurted your feelings.

Videos are made on how to flash tb, following instructions that don't seem to be needed. Conferences were made stating that t480/t480s were supported but coreboot, which was false. Things need to be reproducible.

People came to Heads asking for port. Said I wouldn't do it but mentor to do the port if it was supported. 30h later, one technical board owner patched patchset so that it doesn't cause regression, but none are coreboot devs.

Therefore efforts are duplicated and a waste of time, because it's hacks on top of hacks.

I respect initial work of @mkukri and endeavors of libreboot /mini free goals of making coreboot more accessible. But this port got traction before being ready without causing regressions.

The rest of the world is rebasing their work on top of 24.12 and for that to happen, hacks need to be added on top of prior work to keep primalty and accountability, Attribution of work, as well as credit to primal author, since it's how open source works.

I'm simply stating that things need to be a bit more mature prior of being stated as supported. I have much respect for your work against Goliath. Not so much for the drama, fights and silo work. We don't compete here. We rely on each other's work. T480/t480s building in lbmk bubble doesn't pass reality way of how upstream nor other downstream projects builds, Leah. You cna be angry at me for that, but that's the reality outside of "Leah's planet"

@libreleah @mkukri

Gentle reminder that this ecosystem is small and we should work together, for the benefit of the ecosystem.

I'm only representing desire from downstream, and pointed you to effort that is happening because upstream patch don't build. As usual you do as you want. I'm not fighting against you, I'm fighting for the benefit of all. You choose to pick a fight, I'm just pointing the obvious.

Heads is a payload of coreboot and doesn't pretend to be coreboot. Heads depends on functional coreboot ports. And require forks to build and not cause regressions for other boards. Just like Skulls, upstream, and all other forks who woukd have wanted to use 24.12 + t480/t480s.

You're being unreasonable. It's not my fight. People were misleaded by fake news saying t480 was supported by coreboot, creating demand and community effort. You're really hard to deal with @leah, I'm not your enemy.

@libreleah @mkukri

On planet earth, community effort continues since they care more than upstream, patching patchset.
https://github.com/tlaurion/heads/pull/25

@libreleah Agreed that goals might be the same but approaches makes lbmk not fail on t480 because 24.12 not reused for other boards which should reuse 24.12. We're looping here.

Heads community members struggling and now passing more than 30h mentoring them understand lbmk and Heads where if patchset was ok upstream, it would be for Heads/Lbmk to do their own things as they want. Problem is, the patchset is incomplete for coreboot to review.

Anyway, putting the t480 aside, and postponing t480s until coreboot patchset under review is merged on my side, and taking note that a board can only be supported if part of a maintained coreboot fork (that is, that is not causing regressions for other boards depending on the same commit).

Heads port of t480 will stay where it is at https://github.com/linuxboot/heads/pull/1908#issuecomment-2704450527

I have not much more time to invest on this. As I said, I do not sell the t480, collaboration should happen upstream (for the bettering of the whole ecosystem) and debating lbmk/Heads buildsystem differences is out of scope of my message here, with all the others going in multiple directions as well.

If you are to invest into something to revise buildsystem buildstack, I would advise looking into StageX. I invested a lot of time into building a Nix docker image to fix reproducibility issues once and for all since Heads builds a lot of standard linux tools packed into initramfs, but StageX is working on the gnat/ADA boostrapping and once done, they will be feature complete and par with Nix for providing the proper docker image, and more (maybe even use StageX to produce libs and binaries to be packed into initramfs) without needing to build musl-cross-make, nor crossgcc buildstacks eventually; they could be packed into docker image and reproduced as needed)

Last note and repetition for clarity: each board under Heads specify a coreboot version (which corresponds to a fork/release), a linux version and configuration files for both. Then the boards are built by CI, with a dependency chain to reuse not only build stacks, but every build artifacts. This is accomplished because of the way the Make buildsystem does things, so no need for caching under coreboot by itself, all the boards will try to refresh build artifacts ad ski rebuuding them because fresh enough. This permits me to have a qube per project I work on and not waste time rebuilding anything else then initramfs which contains the scripts I work on under Heads, the rest is reused unless changed. And there is helpers in Makefile, and modules/* to clean things up if needed. Building fresh, I understand as a concept. But if reproducibility is guaranteed, is there a need to build fresh and waste CPU and disk space? Different ideologies, both valid. But once one tries to build roms on CI, one has to optimize those things because free tier builds are limiting, and Heads builds a lot of stuff.

LBMK fits LBMK needs. Heads fits Heads needs. Heads would improve by having things cached in a reproducible guaranteed cache system. It won't be Nix because Nix doesn't build things cached with muslc... But StageX does. And StageX was made with the goal of making firmware reproducibility a resolved problem.

Conference on ladt vPub: https://www.youtube.com/watch?v=9-xfccecwpo

@libreleah @mkukri

Both Heads and lbmk permit to apply patches on top of a coreboot fork.

The difference between the two here is that lbmk builds the tree, clean, for each boards, where Heads applies the patches to a fork once, and each board reuses fork build artifacts;, building board specifics in a board specific artifact directory. That permits crossgcc, being the buildstack of each coreboot fork version to be built once, and also repro build issues upstream, economizing both disk space, cpu resource for user and CI.

In Heads goal of building fully functional roms, CI can build and stitch reproducible roms for each commit for end users to download directly from CI, for each commit, and see if a comit broke a built, for each commit. CI cache is reused, so that we don't waste CI resources either.

In the case of t480, the patch was made with lbmk in mind, not coreboot nor Heads, and breaks other thinkpads in coreboot upstream, trying to not only build for t480 but make sure t480 patchset doesn't break other boards. In this case, it breaks all other thinkpads, so prevent Heads from merging the PR. What you propose here is for libreboot and Heads to maintain a patchset not merged upstream; it might suit libreboot mindset, being more bleeding edge, and minifree, selling the t480, but not Heads. Heads tries to stay as close as possible to upstream forks, and pushes upstream projects to merge patches. Its long, not easy, but the right thing to do. The patches stays in a patch dir for everyone to see, per software version. In this case, patches/coreboot-24.12/*

I tried to apply the following patch without success instead of commenting thermal.asl

+diff --git a/src/ec/lenovo/h8/acpi/ec.asl b/src/ec/lenovo/h8/acpi/ec.asl
+index bc54d3b..a0408c8 100644
+--- a/src/ec/lenovo/h8/acpi/ec.asl
++++ b/src/ec/lenovo/h8/acpi/ec.asl
+@@ -331,7 +331,13 @@ Device(EC)
+ #include "sleepbutton.asl"
+ #include "lid.asl"
+ #include "beep.asl"
++
++#ifndef CONFIG_BOARD_LENOVO_T480
+ #include "thermal.asl"
++#else
++//#include "thermal.asl"
++#endif
++
+ #include "systemstatus.asl"
+ #include "thinkpad.asl"
+ }

Other non t480 fail to build, and I have no more time to spend on this. The community is interested, tried to reach libreboot and were seen as spammers.

Please fix your patchset upstream. People saw the t480 being "supported by coreboot" in a talk. People didn't understand it was a WiP patchset under coreboot. And here we are. 24.12 was december 2024 "release", there will be another one in 25.03... I do not have time to maintain patches on top of patches, Leah. My focus is not to be a coreboot distribution. My focus is to deliver reproducible roms to users needing accessible security, and improve that UX. There is no grub/seabios under Heads, my focus is to make upstream do the right thing and participate upstream, and make contributors participate upstream. Here, you stated loud and clear tha libreboot comes first before coreboot, I respect that. But the t480 patchset is the one too from upstream. That upstream patch needs to build, and then will be merged and then you won't have to maintain it either. And others will fix audio issues, nvidia etc. Otherwise its silo work, and i'm not interested in that anymore

---

Yes, there is different coreboot forks specified in a central place: modules/coreboot.

And there, the buildsystem says if it can reuse crossgcc of another fork to fasten builds for each commit. The idea here is that the user building one board, or multiple boards will get the same result, but CI building multiple boards based on the same fork will speed up builds massively.

d16 will move to fam15h fork from other community effort. I mentor now, I don't try to do everything myself. Just as here, trying tto collaborate with you so you fix what was brought up upstream. But up to now, you are upstream for t480.

The goal here was not to compare our buildsystems, simply stating that the patchset upstream will never be merged if it causes regressions building other boards. Libreboot can do what it wants, but needs to respect how coreboot works. Their CI does the same, and make sure that building a commit for a board won't break others. In current case, it breaks others and needs to be updated.

This needs to be fixed upstream at https://review.coreboot.org/c/coreboot/+/83274

@libreleah @mkukri

Ideal would be to update patchset so it gets merged eventually so we don't maintain patchset downstream in all projects, nor need for board to build per fork either @libreleah. All 24.12 boards should be able to build per 24.12 fork + patchset, otherwise patchset will never get merged upstream. Have we lost track of getting things merged upstream as a primary goal here and decided to work in silo downstream forever?

I've abandoned helping community port after 30h Mentoring port unpaid until patchset is in order.

Conclusion is: if coreboot is not upstream or maintained and par with stock firmware on basic features and docs, Heads will not get involved in the future. Heads is a payload of coreboot, and does not pretend to be anything else than that. Heads rely in partnership with coreboot developers or boards maintained upstream and learned from its past mistakes doing otherwise.

Let me know when patchset upstream is fixed and doesn't, break other 24.12 boards builds.

@libreleah @mkukri

Nice to read :)

Note that Heads doesn't rely on u-root though, that's linuxboot as a project.

Heads relies on the same ideology if linuxboot though :"let Linux do it". But as opposed to linuxboot which relies on single binary built from go code Ala busybox, Heads relies on scripts and native tools used typically under Linux.

---

Please let me know when the upstream patchset that has been partly reviewed is attacked so that it can eventually be merged, at https://review.coreboot.org/c/coreboot/+/83274

That patchset, when used to build other thinkpads, currently fails. Thsts probzbly why the review didn't get so much traction until now, the CI of coreboot probably reported failing back then, but those are no more available.

I replicated the failings because thermal.asl is commented, making all other thinkpads fail to build, and uncommenting this makes the T480 shortly boot, warn of thermal issues and power off, resulting in a brick.

The T480 effort is driven by Heads community that wanted the board and I decided to invest time to mentor for future ports as well. But this is a blocker. Maintaining patches over a patch for a board that has not been reviewed properly, has known issues unresolved and fails to build other thinkpads is unfortunately a blocker for downstram Heads support of the T480 as of now.

@libreleah feel free to comment there: if you saw the effort, you can as well collaborate there so that the community of technical enough board owners may want to speed up things upstream, and Lear what it means to get a board supported upstream.

--

This is a nice experiment. Thanks for your work there @mkukri!