Ah, just realized I'll have to also update the tb.bin too. I manually created this from lenovo's binaries and they had a different resource/URL for the T480s thunderbold firmware, so best not to risk someone bricking their board with the T480 version.

Edit: I just realized my commits got unsigned when I retroactively signoff'ed the commits. I will fix later.

@thickfont

Ah, just realized I'll have to also update the tb.bin too

Confused about this. I thought the TB was common between the two boards. As part of testing, you must test tb flasshing. Flashing the t480 tb to observe if only slow charging (bad for t480s) or if fast charging works (good also for t480s), otherwise reverting to stock tb from a backup you took prior of flashing t480 and investing time to bring a distinct t480s tb.bin under xx80 blobs dir. Comparing the t480s/t480 tb.bin from libreboot and exposing results would also help.

commits got unsigned when I retroactively signoff'ed the commits. I will fix later.

Commits are "signed-off" by GitHub not from command line git. Can you sign those (git rebase --signoff b19af32fd3d4ee850108a2d9479a38d254015138^ with git knowing your key identity and actually signinf the commits.)

Also if you could squash the last two commits together so that there is no "CircleCI fix" commit, that would be awesome.
If you could rename the previous t480 ifd and gbe to follow the same naming scheme you added for t480s would be great too, otherwise someone will need to do this later (and this is needed since t480 is not alone using xx80 dir blobs anymore).

You can also search t480 issues/pr and tag t480s users that were interested into the t480s. Once tagged and those users accept to be added into https://github.com/linuxboot/heads/blob/master/BOARD_TESTERS.md, you must also add yoruself there along other responders.

Once all that is done, this PR will be mergeable and board testers (including yourself) accountable for testing promptly when there is coreboot/linux/platform specific changes needing to be tested in distinct PRs.

Thanks for your contribution @thickfont ! Really much appreciated!

@thickfont

Ah, just realized I'll have to also update the tb.bin too

Confused about this. I thought the TB was common between the two boards. As part of testing, you must test tb flasshing. Flashing the t480 tb to observe if only slow charging (bad for t480s) or if fast charging works (good also for t480s), otherwise reverting to stock tb from a backup you took prior of flashing t480 and investing time to bring a distinct t480s tb.bin under xx80 blobs dir. Comparing the t480s/t480 tb.bin from libreboot and exposing results would also help.

Apologies, I wasn't clear with my tb.bin comment.

I did flash my T480s board with updated thunderbolt firmware directly from lenovo's website using Libreboot's method as documented here: https://libreboot.org/docs/install/t480.html#manual-tbt.bin-extraction-optional

I have not flashed the T480 thunderbolt firmware and see no reason to risk doing so if lenovo offers an updated T480s version anyway that we can use.

However, I forgot to include my blob in my commit (or the steps to reproduce it similarly to how the T480 one is currently produced). I will have to fix this.

I didn't actually test the slow/fast charging after updating it. I'm not sure how to test that beyond manually monitoring the charging speeds, but I'll look into it to see if the updated firmware actually does work.

commits got unsigned when I retroactively signoff'ed the commits. I will fix later.

Commits are "signed-off" by GitHub not from command line git. Can you sign those (git rebase --signoff b19af32fd3d4ee850108a2d9479a38d254015138^ with git knowing your key identity and actually signinf the commits.)

Also if you could squash the last two commits together so that there is no "CircleCI fix" commit, that would be awesome. If you could rename the previous t480 ifd and gbe to follow the same naming scheme you added for t480s would be great too, otherwise someone will need to do this later (and this is needed since t480 is not alone using xx80 dir blobs anymore).

You can also search t480 issues/pr and tag t480s users that were interested into the t480s. Once tagged and those users accept to be added into https://github.com/linuxboot/heads/blob/master/BOARD_TESTERS.md, you must also add yoruself there along other responders.

Once all that is done, this PR will be mergeable and board testers (including yourself) accountable for testing promptly when there is coreboot/linux/platform specific changes needing to be tested in distinct PRs.

Thanks for your contribution @thickfont ! Really much appreciated!

Appreciate the feedback. Will get to fixing all of the above. (I'm a git newbie :) )

My point is still valid here: if you are to provide a tb.bin, you will have to test it :)
So previous comment still stands for this PR to be merged (and used by others as a repro of you work and tests here) for that board to be added and supported, as any other in tree.

@thickfont great to see it worked!

@thickfont in case you did not do it yet, it would be really helpful for other less experienced user to have at least one picture of disassembled t480s board on the heads-wiki flashing guide. In my view, it can really reduce the stress level if the location of the SPI chips is different.

@thickfont it looks like the build failed…

@thickfont it looks like the build failed…

No its #1965
: meanwhile, replaced CACHE_VERSION variable of CircleCI so that build doesn't reuse cache (builds clean).

I added the t480s tb.bin to the blob download script.

Both t480 and t480s currently share the tb.bin file name in the blobs/xx80 directory. So if you build t480 board, the tb.bin file will be for t480. Whereas if you build t480s board, the tb.bin file will be for the t480s. In other words both tb.bin files currently can't co-exist in the directory if someone built both boards. Both file hashes co-exist in hashes.txt too (not ideal, but it works if you know to expect an error if you manually run "sha256sum -c hashes.txt").

I would have named the tb.bin files "t480_tb.bin" and "t480s_tb.bin", but that would require modifications to the targets/xx80_me_blobs.mk file (as it references the blobs/xx80/tb.bin file directly). I don't understand the formatting of this file to confidently modify it for both possible tb.bin file names.

EDIT:
I tested this locally first and it worked, so I'm not 100% sure why circleci is failing.
However from the logs:

/root/heads/blobs/xx80/tb.bin /root/heads
sha256sum: /root/heads/blobs/xx80/tb.bin: No such file or directory
sha256sum: 'standard input': no properly formatted checksum lines found
ERROR: SHA256 checksum for /root/heads/blobs/xx80/tb.bin doesn't match.

You can see the first line is the output from this line in the script:
$ echo "$sha256_hash" "$filename" "$(pwd)"

Therefore, $sha256_hash is null which is actually $TB_BIN_HASH which is set in my new if/else statement which assumes the local BOARD environment variable is set. $TB_BIN_HASH will only be null if the BOARD environment variable is not set. Is this variable not set in the context of CircleCI's execution of this script? If so, how else can can I determine which board is being built within this script? Is there better logic for this?

The second line of the above logs (missing tb.bin) is also explained by the same missing BOARD environment variable.

@akunterkontrolle @mblanqui @kjkent

Are any of you guys interested in being official board testers for the T480s? I found you guys displaying varying levels of interest in a t480s port in other threads. Cheers!

Ref: https://github.com/linuxboot/heads/blob/master/BOARD_TESTERS.md

EDIT: Don't flash anything yet though! I haven't flashed roms from circleci's yet, so I can't guarantee they work even though they should (hashes are different from my locally built and tested roms which I think is normal until the PR is merged?).

@thickfont sure am! Happy to contribute.

EDIT: Don't flash anything yet though! I haven't flashed roms from circleci's yet, so I can't guarantee they work even though they should (hashes are different from my locally built and tested roms which I think is normal until the PR is merged?).

@thickfont the roms should match, where local build artifats differences for same commit are typically linked to non-clean cpio that are not rebuilt. You should arrive to the same CircleCI built artifacts if local is clean, by doing the following if final rom hashes are different
- ./docker_repro.sh make BOARD=t480s-hotp-maximized real.remove_canary_files-extract_patch_rebuild_what_changed

This should be fixed with #1961 that should be merged today (which seems to have fixed initrd.cpio-xz rebuild, but if not, another issue should be opened)

Also note that CircleCI failing to build has been merged in master just now under #1967.

You should be able to merge master into this PR by doing

• git fetch origin/master
• git merge origin/master

I added the t480s tb.bin to the blob download script.

Both t480 and t480s currently share the tb.bin file name in the blobs/xx80 directory. So if you build t480 board, the tb.bin file will be for t480. Whereas if you build t480s board, the tb.bin file will be for the t480s. In other words both tb.bin files currently can't co-exist in the directory if someone built both boards. Both file hashes co-exist in hashes.txt too (not ideal, but it works if you know to expect an error if you manually run "sha256sum -c hashes.txt").

I would have named the tb.bin files "t480_tb.bin" and "t480s_tb.bin", but that would require modifications to the targets/xx80_me_blobs.mk file (as it references the blobs/xx80/tb.bin file directly). I don't understand the formatting of this file to confidently modify it for both possible tb.bin file names.

EDIT: I tested this locally first and it worked, so I'm not 100% sure why circleci is failing. However from the logs:

/root/heads/blobs/xx80/tb.bin /root/heads
sha256sum: /root/heads/blobs/xx80/tb.bin: No such file or directory
sha256sum: 'standard input': no properly formatted checksum lines found
ERROR: SHA256 checksum for /root/heads/blobs/xx80/tb.bin doesn't match.

You can see the first line is the output from this line in the script: $ echo "$sha256_hash" "$filename" "$(pwd)"

Therefore, $sha256_hash is null which is actually $TB_BIN_HASH which is set in my new if/else statement which assumes the local BOARD environment variable is set. $TB_BIN_HASH will only be null if the BOARD environment variable is not set. Is this variable not set in the context of CircleCI's execution of this script? If so, how else can can I determine which board is being built within this script? Is there better logic for this?

The second line of the above logs (missing tb.bin) is also explained by the same missing BOARD environment variable.

@thickfont as said in previous comment, tb rom differences, and if such difference needed, should be validated and tested prior of me investing time helping for the port here with commits.

As previously asked: have you figured out under libreboot why those tb.bin are the different and if needed as requested? if the t480 tb file can be used on t480s then no need for the following. But if needed, here is what is needed:

Also, I saw you partially added differential tb bins but reuse same tb.bin instead of duplicated in blob script.
If you choose to add t480s tb into the shared xx80 blob script instead of duplicating it/renaming it, you should also duplicate the logic everywhere, not share a final tb.bin. There should be a t480_tb.bin and a t480s_tb.bin if this is confirmed needed.

The checksum should be unique for each file; no tb.bin should be shared if required to be different, this can lead to bricks and CI as confirmed by CI, logic is wrong: the blob script should should download and reconstruct both on a CircleCI prep_step; therefore i'm not sure your conditional BOARD logic is the right thing to do under a shared shared blob script; either you duplicate the blob script into two t480/t480s, split the scripts into shared degard+me/ separate tb480 + separate tb480s or have a single script that doenloads and reconstructs blobs needed for both t480s and t480. You should figure out which option is better for you and others to understand and maintain (I think splitting blobs download script into t480/t480s and same for target should make things clearer to yyou and easier to reuse existing code)so that they require and point to individual tb files, and for those to be created, depend on individual blob script (that seems to be where you got confused with @gaspar-ilom code which uses variables to point ot checksum and files you didn't completely duplicate in your previous attempt).

Current issue with blob script issue and non-duplicated target/xx80:
The problem I see with your duplication of xx80 blob script is that the script doesn't duplicate tb_flashable, so it fails when chk_sha256sum function is called to verify hash against it. I would recommend just duplicating logic so that two different codepath is used to download, extract and verify hash for tb. Same for hashes: the files for hash comparison cannot be the same file.

for Makefile logic under target/xx80, same thing: duplicate into t480 and t480s and rename to t480s_tb.bin and t480_tb.bin as your duplicated in xx80/blob download +pad + mv into xx80 blob dir and you should be able to resolve circeci

no need to duplicate config/linux-t480s.config here: they do not have a single difference. Just have the board config for t480s point to t480 linux config

Time spent currently on t480s review: 2h total. Trying to mentor and code review instead of doing the changes this time. Might take longer but more chances of others to do ports and succeed. We can see #1658 having been dropped as an effort after a lot of work. Sorry to not invest more time for other people's desired board without doing paid consultation services anymore; revising approach, let me know what I can do better for others to be able to port things better and help co-maintain Heads on free tier.

Thanks for the review @tlaurion, exactly the kind of feedback I was hoping for. Much appreciated.

Will try to fix most if not all of this today.

I reviewed the libreboot docs and their tb.bin implementation. They are using different tb.bins for each board, and they also say "Please make sure to flash the correct one for your board". Goes without saying that The tb.bins have different hashes too. I see no reason to test the t480 tb.bin on my only remaining t480s board unless you can guarantee it won't brick the board...

I see no reason to test the t480 tb.bin on my only remaining t480s board unless you can guarantee it won't brick the board...

This is really problematic.

Before merging this PR, at least one of the BOARD_TESTERS.md updated file for t480s needs to flash that t480s_tb.bin, ideally the one porting the t480s. No, I cannot guarantee that it won't brick your USB port's fast charging capabilities, as libreboot produced documentation nad guide to reproduce those blobs, and t480 board challenged that documentation prior of creating a flashing page with the facts. I'm sorry @thickfont but if you are weary on flashing that blob, but that untested blob comes on your PR, which PR content is supposed to be tested working at the best of your knowledge and to the best of my review: we have a problem, since you basically say here that you are not willing to test/report/collaborate with libreboot on things not fcuntional, and as I stated numerous times before, after having spent more than 30h on the t480 and challenging Leah (with all the drama that came with it) and with the t480/t480s still not merged under coreboot, the current PR will not be merged.

We are mixing things here. I am willing to give advice/mentoring/share knowledge to those who want to have Heads on the platforms they port to Heads. I am not willing dealing with support requests technical board owners are not willing to test nor fix themselves nor challenge upstream (here libreboot until coreboot) since I am not paid for this work either.

TLDR: if you are not willing to test libreboot instructions yourself for the t480s tb bins CircleCI produced, nor any other technical enough board owners (candidated @akunterkontrolle @mblanqui @kjkent) stand up to the task of being able to maintain/test this board/participate upstream under libreboot/coreboot here, you are basically expecting me to deal with consequences of other people flashing things that should be tested but weren't and might brick their boards. It would not be ethical to merge this.

If this is what you are aiming to do, I would gladly ask you to do another commit which will rename the t480s as UNTESTED (there are helpers under global Makefile to facilitate this), as until one more technical board owner stands up as being the one that will maintain this board. My job as a maintainer of Heads is to make sure that changes needed across all supported boards are tested per their board testers in time for possible linked regression for future PR.

I'm sorry if there was still a misunderstanding, but the goal of the Heads project is to have supported boards and a community to help each other support those board. Here, libreboot is upstream until merged under coreboot at https://review.coreboot.org/c/coreboot/+/83274, so under libreboot community channels. There is no way anything merged under Heads becomes Heads responsibility because other people in the accountability chain fails their responsibilities. Yours here is to flash all build artifacts and confirm no other regressions happen in terms of coreboot+libreboot so that people that would arrive to me would be only for things Head srelated. There is no way I extend my role outside of that. I have no time for that, nor own a t480s. I hope we are clear and there is nothing personal here. I understand you are excited by the t480s being WiP under coreboot at https://review.coreboot.org/c/coreboot/+/83274 and supported by libreboot. But reality here is that it is not supported by coreboot today. So no. I cannot guarantee you that flashing that tb.bin will not make that controller not work again. But if we stay logical, and you get a backup before flashing, you should not be scared of flashing nor reverting things, otherwise there is no technical enough board owners behind this port for the t480s. Again, nothing personal here. But if its the case, we need someone else to stand up that woun't be scared of flashing, causing bricks, and reverting to backups. Otherwise this PR won't get merged.

Thanks for the review @tlaurion, exactly the kind of feedback I was hoping for. Much appreciated.

Will try to fix most if not all of this today.

I reviewed the libreboot docs and their tb.bin implementation. They are using different tb.bins for each board, and they also say "Please make sure to flash the correct one for your board". Goes without saying that The tb.bins have different hashes too. I see no reason to test the t480 tb.bin on my only remaining t480s board unless you can guarantee it won't brick the board...

Awesome progress with the other commits. Hope my previous comment facts reached you and what needs to be done prior of merging this pr which now builds from CircleCI and should produce same roms loally and from CircleCI. Please confirm and let me know if you can be that responsive technical board owher willing to risk a brick and unbrick/be on the libreboot channel until https://review.coreboot.org/c/coreboot/+/83274 gets merged, otherwise this PR will bitrot until someone else show up and is willing to create SPI content backups/flash/revert to backup any future PR related to the t480s, as for any supported boards under Heads.

Updated OP TODOs

t480s/t480 vulnerable to qsb-107 #1975 #1976

Apologies for my slow reply here -- Just catching up.

@gaspar-ilom thanks for your input!

thickfont happy to flash using the guide and can provide feedback on it as you suggest. Will report back :)

Edit: @thickfont btw, is your t480s of type 20L8(-SCX800) with an i5-8350U? If so, and you took a backup dump of your stock BIOS before flashing heads, any chance I could have a copy? I didn't realise my backup was corrupt until I needed it :')

The coreboot PR is apparently raising from the dead, on patchset 35 currently. Mb worth taking a look at.

Port upstreamed

Port upstreamed

Upstream patched 25.06 which was merged.

I attempted to apply newer patches to 24.12 unsuccessfully at #1989

PR welcome!

@thickfont this PR was modified to be par with master and t480s boards renamed with EOL in name to reflect CVE-2017-5715 vulnerable state (see e6ba702)

When Heads tries to use the tpm, it seems to fail. Not sure how to debug this further but I have the hardware if you need a tester/someone to debug it. I've done a OEM reset fyi.

(fyi, I have a external flasher and am technical enough (I think?) Happy to compile and all of that)

EDIT: I have added some logs I was told to get on matrix. (dmesg + cbmem)
cbmem.txt
dmesg.txt

When Heads tries to use the tpm, it seems to fail. Not sure how to debug this further but I have the hardware if you need a tester/someone to debug it. I've done a OEM reset fyi.

(fyi, I have a external flasher and am technical enough (I think?) Happy to compile and all of that)

EDIT: I have added some logs I was told to get on matrix. (dmesg + cbmem)
cbmem.txt
dmesg.txt

@HarleyGodfrey confirmed TPM working on matrix channel, as showed working per logs provided here.

After flashing, per docs, TPM needed to be initialized at least once for ownership (TPM reset or factory reset) and then secret sealed in TPM per proposed option (or through Options-> TPM menu).

@thickfont

• update BOARD_TESTERS.md with confirmed end users having external programmers, technical enough to backup/revert in a responsive manner for this PR and other PRs; minimally the ones being coreboot version bumps and kernel version bumps, or other PR known to possibly affect this board for one reason or the other.

Waiting for testers report :)
Matrix room thread: https://matrix.to/#/!DuZPJBBoKAZyvrWmpv:matrix.org/$3ZuRUOWCHKxVrrDqfhbyxDu4flkii_k_q6VBs0_wia8?via=matrix.org&via=nitro.chat&via=tchncs.de

@HarleyGodfrey ping. On matrix you seem to say everything works? Please confirm here.

@tlaurion i tested this with a t480s and it works you can me list as a board tester.
Only 2 small (known) issues:

1. Headphones must be chosen with in the OS as output to work (for unclear reasons the detection that they are connected is not working). Tested with Qubes 4.2 and ubuntu 24.04
2. we tested the TB port only for power supply not for general TB functionality, as powersupply (also fast charging) it works

#2014 is also a Problem for the t480s will test see here for the fix master...Nitrokey:heads:fix-mac-t480

Hey! Appoliges for not getting back to this sooner. Just started a new job so have been a bit distracted. Also, the motherboard on my t480s died, well the display part did.

As far as I can tell everything is working. That being said, I think I was testing on my own build. I can't seem to find a build for this mr and I am having a little trouble compiling. I broke my machine that I was building heads on so in a little bit of a bad spot.

Any chance you have a rom I can test with. I will continue trying to build it and let you know if I succseed and check that all is working.

(Sorry for the badly writen message. Just got back from a lot of driving and traveling so brain really mush)

[EDIT]
Just moved over to the laptop and it appears that there is a issue with headphone jack not working at all with pipewire and with pulse audio you have to manually change it over. On libreboot's website they talk about it here: https://libreboot.org/docs/install/t480.html#how-to-use-the-headphone-jack

I assume some sort of patch needs to be made for this to work? Or replacing with vendor firmware.

As far as I can tell everything is working. That being said, I think I was testing on my own build. I can't seem to find a build for this mr and I am having a little trouble compiling. I broke my machine that I was building heads on so in a little bit of a bad spot.

Any chance you have a rom I can test with. I will continue trying to build it and let you know if I succseed and check that all is working.

@HarleyGodfrey CircleCI says:

After 30 days, all artifacts associated with a build automatically expire. Since this run is over 30 days old, the artifacts may have been deleted.

So you can just re-run if you have setup CircleCI for your own repo (here's a guide that worked for me when creating CircleCI account logging in via GitHub: #1923 (comment) ) or you force push to the branch to trigger a new CI run.

Either way, IMHO testing only makes sense really after rebasing this on master as coreboot was bumped and support for T480/s was merged upstream and is now integrated into Heads. Also there are a few changes regarding USB/ Thunderbolt that affect this board #2007

Not sure if the T480s has Thunderbolt but if so, please test it too after the rebase and report back. Would like to know whether #2007 actually fixed Thunderbolt on these boards.

[EDIT] Just moved over to the laptop and it appears that there is a issue with headphone jack not working at all with pipewire and with pulse audio you have to manually change it over. On libreboot's website they talk about it here: https://libreboot.org/docs/install/t480.html#how-to-use-the-headphone-jack

I assume some sort of patch needs to be made for this to work? Or replacing with vendor firmware.

It should just be listed as a known issue or better refer to the documentation of known issues upstream as done for the T480: 990e82a If you make a fix for the headphone jack you should integrate it upstream and not maintain it here. I would appreciate such an effort but the board is very usable without it as there are workarounds.

The problem with the headphone jack is a known issue of the coreboot and not heads. It will probably be fixed soon for both boards t480 and t480s.

90023: mb/lenovo/t480: Fix headphone jack | https://review.coreboot.org/c/coreboot/+/90023

Hey! Awsome! I will try to rebuild with circleci and give the current version a test. When the new patches are merged and all that, I will give it another test. Currently I don't have any thunderbolt devices but I can probably pick up something online or find someone with a eGPU or smt.

Hey! Awsome! I will try to rebuild with circleci and give the current version a test. When the new patches are merged and all that, I will give it another test. Currently I don't have any thunderbolt devices but I can probably pick up something online or find someone with a eGPU or smt.

There was a little bit more than rebuilding from circleci needed. There ws merging master (coreboot 25.09 version) plus changing oldconfig file with new defaults (see commits log for repro details). The past ports should be enough for anyone to reproduce at this point.

See 31f6364 and 61b5cf5

The problem with the headphone jack is a known issue of the coreboot and not heads. It will probably be fixed soon for both boards t480 and t480s.

90023: mb/lenovo/t480: Fix headphone jack | https://review.coreboot.org/c/coreboot/+/90023

The missing patch was added, affecting both t480 and t480s.

• t480: @gaspar-ilom if you could check jack
• t480s @thickfont @kjkent @HarleyGodfrey @nestire retest all t480s. We need thunderbold tests as well. Come on people :)
  (Added yous into BOARD_TESTERS.md at 024c069)

The firmware images should be produces by last commit's circleci artifacts, follow download instructions of docs but apply for this PR.