Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state)

[tlaurion]

• Based and superseeds Heads t480 community port effort under t480 port #1906

---

• t480 WiP upstream https://review.coreboot.org/c/coreboot/+/83274 disabled thermal control and broke build of all other thinkpads
  • fixed by @gaspar-ilom under f765586 which affects all skylake+ and still need proper fixes upstream by coreboot devs.

Leah blocked me on mastodon because I urged to work upstream and lbmk stop building things in bubble, since this harms ecosystem, including coreboot upstream which won't participate much in review process if patchset proposed cause regressions. Oh well.

---

Since f765586 now permits to version bump all prior 24.02.01 boards to 24.12, including t480, we need to retest all boards prior of merging:

• Optiplex 7010/9010 SFF/DT: @tlaurion (owns DT variant)
  • Thanks @tlaurion for testing report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• x230t : @fhvyhjriur
  • from coreboot perspective, its a x230. No testing expected needed here
• t530 (xx30): @fhvyhjriur @3hhh (Opportunity to mainstream and close Bring back Lenovo Thinkpad T530 to supported/tested - images are working fine #1682)
  • moved to untested per Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• x230-fhd/edp variant: @n4ru @computer-user123 (nitro caster board) @Tonux599 @househead @pcm720 (eDP 4.0 board and 1440p display) @doob85 https://matrix.to/#/@rsabdpy:matrix.org (agan mod board)
  • tested in prior version of this pr, changes following not expected to impact edp, should be equal as tested x230
• z220-cmt (HP Z220 CMT): @d-wid
  • moved to untested per Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• t420 (xx20): @notgivenby @alexmaloteaux @akfhasodh @doob85
  • Thanks @notgivenby for test report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• x220 (xx20): @srgrint @Thrilleratplay
  • Thanks @srgrint for testing report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• t430 (xx30): @notgivenby @nestire(t430-legacy, t430-maximized) @Thrilleratplay @alexmaloteaux @lsafd
  @bwachter(iGPU maximized) @shamen123 @eganonoa(iGPU) @nitrosimon @jans23 @icequbes1 (iGPU) @weyounsix (t430-dgpu)
  • Thanks @notgivenby for test report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• w530 (xx30): @eganonoa @zifxify @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU) @tlaurion
  • Thanks @tlaurion for test report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• x230 (xx30): @nestire(x230-legacy, x230-maximized) @tlaurion(maximized) @osresearch @merge @jan23 @MrChromebox @shamen123 @eganonoa @bwachter @Thrilleratplay @jnscmns
  • Thanks @tlaurion for test report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• t440p: @fhvyhjriur @ThePlexus @srgrint @akunterkontrolle @rbreslow
  • thanks @MattClifton76 for trust report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• w541 (similar to t440p): @ResendeGHF @gaspar-ilom (Always tested late: Needs more responsive board testers or risk to become unmaintained.)
  • Thanks @gaspar-ilom for testing report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
• t480: @gaspar-ilom @doritos4mlady @MattClifton76 @notgivenby @akunterkontrolle.
  • Thanks @gaspar-ilom for testing report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
  • Thanks @MattClifton76 for testing report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
  • Thanks @notgivenby for test report under Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)

---

Old, prior of f765586

t480 REMOVED FROM THIS PR

• t480: have lost thermal control which CAUSES A BRICK: upstream patchset disabled it for all other thinkpads. T480 BRICKED BY LACK OF THERMAL CONTROL READDED FOR ALL OTHER THINKPADS
  • t480 removed from this PR at Coreboot version bump 24.02.01 -> 24.12 for most board + Thinkpad T480 addition (coreboot upstream in WiP state) #1908 (comment)
  • Needs to be fixed upstream under https://review.coreboot.org/c/coreboot/+/83274
  • @notgivenby : share picture upstream. This cannot be merged under coreboot as is: its either all other thinkpads or t480: per patchwork, its t480 and all other boards not building as proven in this PR.
    • If easier for upstream, I could create another branch and PR just to show that using https://review.coreboot.org/c/coreboot/+/83274 breaks other boards. Will do

---

This depends on #1906 being merged first.

This depends on patches adding t480 which are not merged upstream yet, which https://review.coreboot.org/c/coreboot/+/83274/25/src/ec/lenovo/h8/acpi/ec.asl#b334 is a blocker otherwise breaking other thinkpads in CircleCI as can be seen prior of removing the line at aa2b15d

• Only relevant commits here are 67a027d ++

This is early bump, simply because t480 depends on 24.12+libreboot patches and it seems logical to bump most of supported boards to 24.12 coreboot (we are on 24.02.01 which means a year old coreboot version on most boards).

Will rebase on master once #1908 is/if merged

---

tested

• nv41 (unrelated to this PR but good for regression test of battery info)
• qemu boards
• t420 (xx20): @notgivenby @alexmaloteaux @akfhasodh @doob85
• x220 (xx20): @srgrint @Thrilleratplay
• t430 (xx30): @notgivenby @nestire(t430-legacy, t430-maximized) @Thrilleratplay @alexmaloteaux @lsafd @bwachter(iGPU maximized) @shamen123 @eganonoa(iGPU) @nitrosimon @jans23 @icequbes1 (iGPU) @weyounsix (t430-dgpu)
• w530 (xx30): @eganonoa @zifxify @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU) @tlaurion
• x230 (xx30): @nestire(x230-legacy, x230-maximized) @tlaurion(maximized) @osresearch @merge @jan23 @MrChromebox @shamen123 @eganonoa @bwachter @Thrilleratplay @jnscmns
• x230-fhd/edp variant: @n4ru @computer-user123 (nitro caster board) @Tonux599 @househead @pcm720 (eDP 4.0 board and 1440p display) @doob85 https://matrix.to/#/@rsabdpy:matrix.org (agan mod board)
• x230t : @fhvyhjriur
• t530 (xx30): @fhvyhjriur @3hhh (Opportunity to mainstream and close Bring back Lenovo Thinkpad T530 to supported/tested - images are working fine #1682)
• t440p: @fhvyhjriur @ThePlexus @srgrint @akunterkontrolle @rbreslow
• w541 (similar to t440p): @ResendeGHF @gaspar-ilom (Always tested late: Needs more responsive board testers or risk to become unmaintained.)
• z220-cmt (HP Z220 CMT): @gaspar-ilom

[gaspar-ilom]

@gaspar-ilom amazing news yesterday on that front: NRI got merged upstream, meaning that the merge patch train is 24.12 + a lot of patches, but, if the patch trail splitted in small commits patches under Heads, and those individual patches adapted to be applied cleanly on top of this PR (later work), then we will have NRI for t440p w541, finally.

I think there are different options:

1. Pull in all the patches and maintain them under 24.12. as you suggested.
2. We could also wait for the next coreboot release which is not far away (25.03!?) and bump all boards again or will the testers just hate us too much?
3. Or we put this PR on hold yet again and reset the coreboot commit to fetch 24.12 from to 5d291de6011a56bfd767c4bcdfdc3aa6ee87a2dd (current HEAD of main after haswell NRI was merged). Coreboot 24.12 in Heads is anyway pulling an arbitrary commit 70 commits ahead of the release right now: git log 24.12..2f1e4e5e8515dd350cc9d68b48d32a5b6b02ae6a

Personally, I have no strong preference. I just thought that 2 and 3 might be cleaner and less maintenance work as we could ideally just forget about haswell NRI. 1. might have the advantage that we only need to test haswell boards (just W541 and T440p iirc).

[tlaurion]

@gaspar-ilom On reply for previous comment, it's gonna be a seperate effort.

Discussion continues at

#1711 (comment)

[tlaurion]

EDIT: 4cb6985 should probably be merged into #1908 as a cleanup

@gaspar-ilom done

Originally posted by @tlaurion in #1923 (comment)

[tlaurion]

4cb6985 doesn't change anything and doesn't invalidate past test reports: it just prepares for Haswell NRI separate effort under #1923 which @gaspar-ilom being in fire is already preparing for merge once we confirm no regression for other boards here!

[notgivenby]

@tlaurion @gaspar-ilom t420, t430, t480 no regression. All booted:-)

[tlaurion]

Of all boards needing testing in OP(modified)

• t530 (xx30): @fhvyhjriur @3hhh
• z220-cmt (HP Z220 CMT): @d-wid

Were not tested yet nor sign of life of when it could be tested soon. Since helpers are now in tree, I will push commit to move those back to untested, while still maintained (Someone will have to open issue to say they were tested when they are; the goal of which is not to say that those boards can be internally flashed by silent board owners without an external programmer to unbrick, as previously discussed under #1682 (comment) and led to notes added to https://osresearch.net/Prerequisites#supported-devices

EDIT:
related to 876e37e and a65a36f below.

Board owners could revert the commit in subsequent PR when tested, or open an issue saying it was tested. Those boards, once again, need more declared board owners with external programmers in case of bricking on important version bumps like these where coreboot might affect platform initialization and cause bricks.

[tlaurion]

I commented upstream at https://review.coreboot.org/c/coreboot/+/83274/comment/cf07c1ed_e35c2724/

[gaspar-ilom]

Thanks @tlaurion for all the work you have put in in guiding us though the port of the T480 and in the coreboot version bump.

I have not gone through every coreboot and board config file for this review. I had already reviewed the new files under these directories for #1906 so I hope that this is fine.

[tlaurion]

Tested working on Optiplex 9010 DT (board added under 10f854c)

Testing added in OP crosslinking here

[tlaurion]

Thanks @tlaurion for all the work you have put in in guiding us though the port of the T480 and in the coreboot version bump.

I have not gone through every coreboot and board config file for this review. I had already reviewed the new files under these directories for #1906 so I hope that this is fine.

Wating for 10f854c to build and its a merge.

TODO:

• rebase/merge into Use Native Ram Init (NRI) on haswell boards (not chromebox's preppy borrowed MRC blob) #1923

[tlaurion]

@notgivenby agreeing with @gaspar-ilom, ideally linuxboot/heads-wiki#174 is ready to merge at the same time :)

[d-wid]

Of all boards needing testing in OP(modified)

* [ ]  t530 (xx30): @fhvyhjriur @3hhh

* [ ]  z220-cmt (HP Z220 CMT): @d-wid

Were not tested yet nor sign of life of when it could be tested soon. Since helpers are now in tree, I will push commit to move those back to untested, while still maintained (Someone will have to open issue to say they were tested when they are; the goal of which is not to say that those boards can be internally flashed by silent board owners without an external programmer to unbrick, as previously discussed under #1682 (comment) and led to notes added to https://osresearch.net/Prerequisites#supported-devices

EDIT: related to 876e37e and a65a36f below.

Board owners could revert the commit in subsequent PR when tested, or open an issue saying it was tested. Those boards, once again, need more declared board owners with external programmers in case of bricking on important version bumps like these where coreboot might affect platform initialization and cause bricks.

Hi @tlaurion , either the message missed me or I forgot (I was in the middle of something at that point last month), but I've just tested the latest master/main artifact on my Z220 CMT and found it to work fine.

Apologies for the delay.

[tlaurion]

Of all boards needing testing in OP(modified)

* [ ]  t530 (xx30): @fhvyhjriur @3hhh

* [ ]  z220-cmt (HP Z220 CMT): @d-wid

Were not tested yet nor sign of life of when it could be tested soon. Since helpers are now in tree, I will push commit to move those back to untested, while still maintained (Someone will have to open issue to say they were tested when they are; the goal of which is not to say that those boards can be internally flashed by silent board owners without an external programmer to unbrick, as previously discussed under #1682 (comment) and led to notes added to https://osresearch.net/Prerequisites#supported-devices

EDIT: related to 876e37e and a65a36f below.

Board owners could revert the commit in subsequent PR when tested, or open an issue saying it was tested. Those boards, once again, need more declared board owners with external programmers in case of bricking on important version bumps like these where coreboot might affect platform initialization and cause bricks.

Hi @tlaurion , either the message missed me or I forgot (I was in the middle of something at that point last month), but I've just tested the latest master/main artifact on my Z220 CMT and found it to work fine.

Apologies for the delay.

I will gently ask for a PR putting it back to tested from board owners @d-wid.

Two months delay between PR and it's actual testing grants untested title properly in my opinion, this title being aimed to protect end users not owning an external programmer and not willing to risk a brick because no internally flashing untested built rom from master, untested because no board owners are willing to promptly test pull request in a timely manner when needed prior of changes reaching master (sorry but here this is you alone for z220-cmt, which is not planned to become more populair anytime soon, @d-wid ).

You can open an issue to put that board out of untested status if unwilling to provide a PR l, using main Makefile helper to switch untested board to tested, sign commit and create a pull request of of that change.

I'm not willing to play those games anymore. If a board is not used enough, and consequently has no tester when needed, I cannot maintain it blindly, risking end users without external flashers to risk bricking their platform. If the board is important to you, you should donate, test in timely manner, or be able to out the board back ingested state since you haven't tested it when needed.

You should understand. Thank you. Do not expect me to switch it back to tested. Nobody else is know to own that platform and this is problematic.