Bump coreboot to 25.09; Add t480

[gaspar-ilom]

This bumps the coreboot to version 25.09.

Also, it applies the WIP Thunderbolt patches from

• https://review.coreboot.org/c/coreboot/+/75286/18
• https://review.coreboot.org/c/coreboot/+/88490/1
• and keeps the PR0 patch and clear TPM log area on creation patch.

Old patches for 24.12 are removed. In particular, the ones we copied from libreboot. However, we might want to keep some which are currently not included such as

• Remove the stack overflow debug option (was included before)
• Disable NVME hotplug (not included before). However, I have not encountered the issue. So I would not do it for now.

The motivation was to get the merged changes for the sky/kaby lake boards such as the T480. Therefore - if merged - this PR would replace #1989 and also require updating #1966

State

• T480 build flashed internally and confirmed working
• The primary USB-C port keeps working inclduding charging and display port
• The lower USB-C port also works
  • Nitrokey works, didn't before.
  • Charging and display port
  • In Qubes a USB block device was not detected nor keyboard, mouse etc. Did not investigate. Works now after correctly assigning devices to VMs.
• Some screen glitches that I had in Qubes OS seem to have disappeared
• Investigate why f077ada is necessary and decide on a (proper) solution
• Thunderbolt needs testing.
  • I don't have a suitable device.
• Implement it cleanly. Rename coreboot 24.12 to 25.09 etc.
  • Currently, it is still a WIP with minimal effort. Will change that if there is a good chance of making it into master.

For testers

• Verify there are not regressions.
  • Flash internally.
  • Boot.
  • Report any issues.
• On the T480 specifically, verify that Thunderbolt works.

Test results

See the comment below: #2007 (comment)

[tlaurion]

@gaspar-ilom thanks for this contribution!

25.09 seems a good moment to switch all boards depending on previous effort against coreboot master (was 24.12 : YY.MM being 2024.12).

That will require all boards coreboot config to be switched with help of helpers (switch to defconfig, make sure what is left there needs overriding over defaults, save back in oldconfig format) and call for testing using testing template and improve upon it, and tagging all known board owners/testers.

This PR should supersede other attempts referred in OP. T480s/t480 support under coreboot master justifies it, as well as TB support, if testing results here is reported upstream so that we can guarantee that next coreboot release will include patches applied here on next coreboot version bump.

[gaspar-ilom]

25.09 seems a good moment to switch all boards depending on previous effort against coreboot master (was 24.12 : YY.MM being 2024.12).

Great!

That will require all boards coreboot config to be switched with help of helpers (switch to defconfig, make sure what is left there needs overriding over defaults, save back in oldconfig format) and call for testing using testing template and improve upon it, and tagging all known board owners/testers.

Not sure I have done what you intended. See commit message of 78451c9

I would only let the testers know when this is done. Testers for boards that use the new coreboot version should be enough, though?!

This PR should supersede other attempts referred in OP. T480s/t480 support under coreboot master justifies it, as well as TB support, if testing results here is reported upstream so that we can guarantee that next coreboot release will include patches applied here on next coreboot version bump.

Let's see what will be reported.

[gaspar-ilom]

Making this a draft because it is not done yet. See f077ada

[gaspar-ilom]

Updated the How to proceed section in the OP to reflect what @tlaurion suggested.

[gaspar-ilom]

@tlaurion CircleCi is beyond me: Why does gaspar-ilom@ced2f98 succeed but x86-musl-cross-make fails reliably for 78451c9 and fdeb5e8 . The latter is identical to the succeeding gaspar-ilom@ced2f98

EDIT: I undid the revert from fe4e190 as it does not seem to change anything. Local build works, of course 🙄

[tlaurion]

@gaspar-ilom i don't make sense of the circleci error, as if cache was partial at https://app.circleci.com/pipelines/github/gaspar-ilom/heads/14/workflows/b282ff7a-03b4-43af-aed1-369e0454906f/jobs/709

This would need to build without cache to succeed if local builds succeed.

To do this, under Circleci project setting, variable, change/add CACHE_VERSION with unique value (I do datestamp) or change variable name under Circleci config, ie

heads/.circleci/config.yml

Line 82 in aaeb63d

- nix-docker-heads-modules-and-patches-{{ checksum "./tmpDir/all_modules_and_patches.sha256sums" }}{{ .Environment.CACHE_VERSION }}

[gaspar-ilom]

To do this, under Circleci project setting, variable, change/add CACHE_VERSION with unique value (I do datestamp) or change variable name under Circleci config, ie

@tlaurion Thanks for the hint. Trying it here: https://app.circleci.com/pipelines/github/gaspar-ilom/heads/12/workflows/8314619a-fb68-4af8-8915-06abf2a8f93d

[tlaurion]

To do this, under Circleci project setting, variable, change/add CACHE_VERSION with unique value (I do datestamp) or change variable name under Circleci config, ie

@tlaurion Thanks for the hint. Trying it here: https://app.circleci.com/pipelines/github/gaspar-ilom/heads/12/workflows/8314619a-fb68-4af8-8915-06abf2a8f93d

@gaspar-ilom FYI ci builds passed :)

[nestire]

tested the t480-hotp-mazimized rom with:
ubuntu 24.04. Kernel 6.14.0 , 64 GB Ram, Samsung 990 Pro nvme. + Nitrokey 3a Mini 1.8.3 Firmware

• OEM Factory reset worked
• Webcam, Ethernet/Wifi worked
• No unexpected errors in the journal

thx for the work @gaspar-ilom

[tlaurion]

tested the t480-hotp-mazimized rom with:
ubuntu 24.04. Kernel 6.14.0 , 64 GB Ram, Samsung 990 Pro nvme. + Nitrokey 3a Mini 1.8.3 Firmware

• OEM Factory reset worked
• Webcam, Ethernet/Wifi worked
• No unexpected errors in the journal

thx for the work @gaspar-ilom

@nestire

As per OP requiring testing: is firewire functioning properly?

[tlaurion]

@nestire @gaspar-ilom : docs as comments in boards say ME is deactivated+neutered.

What means neutered here? To which extent is that true VS xx30 (intel 3rd gen vs 10th Gen : I think deactivated is proper, no?)

Applies to t480s as well. There starts to be multiple PR targeting same boards. I let you decide in which order you want this to be merged and comment accordingly.

Are we ready to test all thinkpads by community members?

[gaspar-ilom]

@tlaurion sorry for becoming so silent. I briefly looked into the build issues and find a better solution to fix the build than the dirty hack in fdeb5e8
Maybe you can help me:

From the root of heads I run these two commands (after make clean on the directory):

./docker_repro.sh make -C build/x86/coreboot-25.09/util/cbmem 
Using CircleCI Docker image: tlaurion/heads-dev-env:v0.2.5
----
Usage reminder: The minimal command is 'make BOARD=XYZ', where additional options, including 'V=1' or 'CPUS=N' are optional.
For more advanced QEMU testing options, refer to targets/qemu.md and boards/qemu-*/*.config.

Type exit within docker image to get back to host if launched interactively!
----

--->Launching container without access to host's USB buses (no USB devices was connected to host)...
make: Entering directory '/home/user/heads/build/x86/coreboot-25.09/util/cbmem'
cc -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o cbmem.o cbmem.c
cc -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o cbmem_drv.o cbmem_drv.c
cc -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o devmem_drv.o devmem_drv.c
cc -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o sysfs_drv.o sysfs_drv.c
cc -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/ipchksum.o /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/ipchksum.c
cc   cbmem.o cbmem_drv.o devmem_drv.o sysfs_drv.o /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/ipchksum.o   -o cbmem
make: Leaving directory '/home/user/heads/build/x86/coreboot-25.09/util/cbmem'

And here's the command from the build that fails:

./docker_repro.sh make -C "/home/user/heads/build/x86/coreboot-25.09/util/cbmem/" CC="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-gcc -fdebug-prefix-map=/root/heads=heads -gno-record-gcc-switches -D__MUSL__ --sysroot  /home/user/heads/install/x86 -isystem /home/user/heads/install/x86/include -L/home/user/heads/install/x86/lib " AR="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-ar" LD="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-ld" STRIP="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-strip" NM="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-nm" OBJCOPY="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-objcopy" OBJDUMP="/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-objdump" PKG_CONFIG_PATH= PKG_CONFIG_LIBDIR="/home/user/heads/install/x86/lib/pkgconfig" PKG_CONFIG_SYSROOT_DIR="/home/user/heads/install/x86" 
Using CircleCI Docker image: tlaurion/heads-dev-env:v0.2.5
----
Usage reminder: The minimal command is 'make BOARD=XYZ', where additional options, including 'V=1' or 'CPUS=N' are optional.
For more advanced QEMU testing options, refer to targets/qemu.md and boards/qemu-*/*.config.

Type exit within docker image to get back to host if launched interactively!
----

--->Launching container without access to host's USB buses (no USB devices was connected to host)...
make: Entering directory '/home/user/heads/build/x86/coreboot-25.09/util/cbmem'
/home/user/heads/crossgcc/x86/bin/x86_64-linux-musl-gcc -fdebug-prefix-map=/root/heads=heads -gno-record-gcc-switches -D__MUSL__ --sysroot  /home/user/heads/install/x86 -isystem /home/user/heads/install/x86/include -L/home/user/heads/install/x86/lib  -O2 -Wall -Wextra -Wmissing-prototypes -Wshadow -Werror -I . -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/include -I /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include -D_DEFAULT_SOURCE -include /home/user/heads/build/x86/coreboot-25.09/src/commonlib/bsd/include/commonlib/bsd/compiler.h  -c -o cbmem.o cbmem.c
cbmem.c: In function 'parse_tpm12_log':
cbmem.c:512:9: error: implicit declaration of function 'le32toh' [-Werror=implicit-function-declaration]
  512 |         le32toh(spec_log->platform_class) == 0 ? "PC Client" :
      |         ^~~~~~~
cbmem.c: In function 'print_tpm2_digests':
cbmem.c:548:16: error: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
  548 |  for (i = 0; i < le32toh(log_entry->digest_count); i++) {
      |                ^
cbmem.c:550:11: error: implicit declaration of function 'le16toh' [-Werror=implicit-function-declaration]
  550 |   switch (le16toh(hash->hashAlg)) {
      |           ^~~~~~~
cc1: all warnings being treated as errors
make: *** [<builtin>: cbmem.o] Error 1
make: Leaving directory '/home/user/heads/build/x86/coreboot-25.09/util/cbmem'

Not sure what is missing from the cross compilation toolchain. I am not a pro at this, so any pointer is welcome.

Here's the error without my fix in circle ci https://app.circleci.com/pipelines/github/gaspar-ilom/heads/15/workflows/47bb1c05-aef5-4ad3-a540-5973e28d0e60/jobs/850/parallel-runs/0/steps/0-102

[gaspar-ilom]

@nestire @gaspar-ilom : docs as comments in boards say ME is deactivated+neutered.

What means neutered here? To which extent is that true VS xx30 (intel 3rd gen vs 10th Gen : I think deactivated is proper, no?)

It is explained in the script here. Not sure what info is missing? Maybe the documentation is not in sync with that?

heads/blobs/xx80/download_clean_deguard_me_pad_tb.sh

Lines 74 to 82 in 475a289

	# Neutralize and shrink Intel ME. Note that this doesn't include
	# --soft-disable to set the "ME Disable" or "ME Disable B" (e.g.,
	# High Assurance Program) bits, as they are defined within the Flash
	# Descriptor.
	# However, the HAP bit must be enabled to make the deguarded ME work. We only clean the ME in this function.
	# https://github.com/corna/me_cleaner/wiki/External-flashing#neutralize-and-shrink-intel-me-useful-only-for-coreboot
	# MFS is needed for deguard so we whitelist it here and also do not relocate the FTPR partition
	python "$me_cleaner" --whitelist MFS -t -O "$me_output" "${me_installer_filename}_extracted/Firmware/${extracted_me_filename}"

Applies to t480s as well. There starts to be multiple PR targeting same boards. I let you decide in which order you want this to be merged and comment accordingly.

No preference. I can always rebase this on master. Just did. Although once, testers are informed this should not change anymore.

Are we ready to test all thinkpads by community members?

See my previous comment. If you don't mind the hack. I am ok with it. In that case I would just change the commit message.

[tlaurion]

@nestire @gaspar-ilom : docs as comments in boards say ME is deactivated+neutered.

@gaspar-ilom https://github.com/linuxboot/heads/blob/master/boards%2FEOL_t480-hotp-maximized%2FEOL_t480-hotp-maximized.config#L99

This is unedited copy paste from xx30.

[gaspar-ilom]

@nestire @gaspar-ilom : docs as comments in boards say ME is deactivated+neutered.

@gaspar-ilom https://github.com/linuxboot/heads/blob/master/boards%2FEOL_t480-hotp-maximized%2FEOL_t480-hotp-maximized.config#L99

This is unedited copy paste from xx30.

Addressed this here: 696bffd
Good enough? Wasn't sure what the non-technical terms such as "neuter" really mean. I hope it is clear now.

[gaspar-ilom]

EOL_UNTESTED_w541-hotp-maximized -> EOL_w541-hotp-maximized in .circleci/config.yml

@Tonux599 fixed here. Thanks gaspar-ilom@ca384ab

EDIT: @tlaurion force pushed over my change. So here's the winning commit: 35941b5

[tlaurion]

EOL_UNTESTED_w541-hotp-maximized -> EOL_w541-hotp-maximized in .circleci/config.yml

@Tonux599 fixed here. Thanks gaspar-ilom@ca384ab

EDIT: @tlaurion force pushed over my change. So here's the winning commit: 35941b5

Sorry about that. :)

[gaspar-ilom]

Sorry about that. :)

I guess that this is what --force-with-lease was made for 😄

[srgrint]

Can confirm x220 works

[tlaurion]

Testing https://output.circle-artifacts.com/output/job/7eb2d649-c251-445e-a2a0-529a4b8db272/artifacts/0/build/x86/EOL_x230-maximized/heads-EOL_x230-maximized-.zip from commit's 35941b5 circleci run

no regression.
Tested:

• internal flashing, no settings preserved
• in memory keygen without keys copied to usb security dongle (solely relaying on usb thumb drive's encrypted partition for private authentication subkey and detached signed validation against fused pubkey from oem-factory-reset
  • picture to be referred in matrix discussion (key material: private/public keys):
    
• set default boot, signature with usb thumb drive backup of key material
• booting into qubesos 4.2.3 works

---

unrelated:
@gaspar-ilom can you remind me why the roms have no version in your circleci instance? Something something git branch related?

[tlaurion]

LGTM.

there is some untested boards per each cpu family known to be really similar but untested. Per current policies, we should move them to untested in this PR, and board testers reporting them as working should move them from untested to tested with helper script.

ex:
./docker_repro.sh make BOARD=UNTESTED_XZY board.move_untested_to_tested

This is currently the case for:

• t530
• optiplex
• etc

Should I move them to untested? I guess so.

[gaspar-ilom]

unrelated: @gaspar-ilom can you remind me why the roms have no version in your circleci instance? Something something git branch related?

@tlaurion I noticed this as well. Did not look into it, though? How is the commit id usually included in the artifact name? I can look into my mi project settings and see if I find anything...

Should I move them to untested? I guess so.

Yes, that would be great. I could do it, too, but only in two days.

[gaspar-ilom]

Should I move them to untested? I guess so.

I moved the boards to untested in separate commits. Please verify that they are fine. T530 was already untested but W530 was not. All boards should have the appropriate state now.

However one doubt: Should W541 maybe stay untested due to the slow raminit (with MRC blob) if I recall correctly. This was the reason the board was move to untested.

@tlaurion I took the liberty of fixing the board helper scripts. They did not handle EOL prefixes correctly (assuming you want "EOL_UNTESTED_" and not "UNTESTED_EOL_" as per the existing boards with the prefixes).
In order to make moving back from unmaintained to tested I hacked the CONFIG variable in the main Makefile. Probably not the most reliable solution. So feel free to drop that part or the entire commit in case you don't like the approach: 971f2e0

[tlaurion]

Should I move them to untested? I guess so.

I moved the boards to untested in separate commits. Please verify that they are fine. T530 was already untested but W530 was not. All boards should have the appropriate state now.

Nice. Thank you.

However one doubt: Should W541 maybe stay untested due to the slow raminit (with MRC blob) if I recall correctly. This was the reason the board was move to untested.

Unsure. It is tested with known boot delays until native ram init possibly fixing it and a pinned issue. You would keep it unmaintained?

@tlaurion I took the liberty of fixing the board helper scripts. They did not handle EOL prefixes correctly (assuming you want "EOL_UNTESTED_" and not "UNTESTED_EOL_" as per the existing boards with the prefixes).
In order to make moving back from unmaintained to tested I hacked the CONFIG variable in the main Makefile. Probably not the most reliable solution. So feel free to drop that part or the entire commit in case you don't like the approach: 971f2e0

I like it, Thank you! Didn't put much thoughts into nomenclature yet.

EOL will stay EOL forever. Where UNTESTED might come and go. Your input is as valuable (diversity is needed) as mine here. I'm no king. :)

[gaspar-ilom]

However one doubt: Should W541 maybe stay untested due to the slow raminit (with MRC blob) if I recall correctly. This was the reason the board was move to untested.

Unsure. It is tested with known boot delays until native ram init possibly fixing it and a pinned issue. You would keep it unmaintained?

Thinking about it: I would keep the board tested, but make sure that the slow boot and flaky resume from suspend are mentioned as a known issues. Other than that the board works fine. So it IS tested.
EDIT: I address this here: cb5beee Maybe the T440p deserves similar documentation but I don't own this board and as of now it is anyway untested. So I think this is no blocker.

EOL will stay EOL forever. Where UNTESTED might come and go. Your input is as valuable (diversity is needed) as mine here. I'm no king. :)

@tlaurion I am asking you because you use these scripts much more often and know the code better. So I wouldn't be surprised if you saw a problem in some part of the code that I was unaware of. Also, I wanted to make sure that you reviewed that and not sneak it in after you approved the PR.

[gaspar-ilom]

@tlaurion is this ready to be merged now? I would say so.

[tlaurion]

Didn't put much thoughts into nomenclature yet.

EOL will stay EOL forever. Where UNTESTED might come and go.

From this, my question was more around should it be UNTESTED_EOL or EOL_UNTESTED?

[gaspar-ilom]

From this, my question was more around should it be UNTESTED_EOL or EOL_UNTESTED?

I have no real preference as long as it is consistent. So let's stick with the way it is until someone there is some reason to change it.

[tlaurion]

Also, it applies the WIP Thunderbolt patches from

* https://review.coreboot.org/c/coreboot/+/75286/18

* https://review.coreboot.org/c/coreboot/+/88490/1

@gaspar-ilom : Those are still unmerged upstream and someone asked if thunderbolt support was tested under matrix channel https://matrix.to/#/!eMLMv62wAMCW1V-ufL_bJ_JDngDhrpSOSEQBLzX8aTg/$51snIMsZb-VoqvZxouKuqTF7QVQaiCitlkVfzZYoa5U?via=matrix.org&via=nitro.chat&via=envs.net

If no comment upstream from testing, this won't be merged meaning downstream needed maintainership.
Quote:

If I’m seeing this correctly, the latest version of Heads for the ThinkPad T480 is based on a newer Coreboot and it fixes the headphone jack. Does it also fix Thunderbolt so that it works normally and not just for charging?

Thunderbolt supposed to work with newest patches merged, untested #2007. This includes

• https://review.coreboot.org/c/coreboot/+/75286/18 : no testing report; TESTERS NEEDED otherwise not merged upstream. Participate in testing please.
• Also needed, no testing report, also unmerged https://review.coreboot.org/c/coreboot/+/88490/1 patchset has conflict with master upstream codebase... Participate in testing please.

[gaspar-ilom]

Also, it applies the WIP Thunderbolt patches from

* https://review.coreboot.org/c/coreboot/+/75286/18

* https://review.coreboot.org/c/coreboot/+/88490/1

@gaspar-ilom : Those are still unmerged upstream and someone asked if thunderbolt support was tested under matrix channel https://matrix.to/#/!eMLMv62wAMCW1V-ufL_bJ_JDngDhrpSOSEQBLzX8aTg/$51snIMsZb-VoqvZxouKuqTF7QVQaiCitlkVfzZYoa5U?via=matrix.org&via=nitro.chat&via=envs.net

If no comment upstream from testing, this won't be merged meaning downstream needed maintainership. Quote:

If I’m seeing this correctly, the latest version of Heads for the ThinkPad T480 is based on a newer Coreboot and it fixes the headphone jack. Does it also fix Thunderbolt so that it works normally and not just for charging?

Thunderbolt supposed to work with newest patches merged, untested #2007. This includes

• https://review.coreboot.org/c/coreboot/+/75286/18 : no testing report; TESTERS NEEDED otherwise not merged upstream. Participate in testing please.
• Also needed, no testing report, also unmerged https://review.coreboot.org/c/coreboot/+/88490/1 patchset has conflict with master upstream codebase... Participate in testing please.

@tlaurion I don't have a device to test this. I am aware that these patches have not been merged upstream. Even if Thunderbolt patches were still broken, they would bring direct value to the end users as they also fix the lower USB-C port which I have tested working. I commented here now: https://review.coreboot.org/c/coreboot/+/88490/comments/6f4aab77_95fe756b It's the best I can do atm.