February 2024 - coreboot - mail.coreboot.org

[coreboot - Bug #448] (New) Thinkpad T440P ACPI Battery Value Issues
by Karsten Schnier May 5, 2026

May 5, 2026

Issue #448 has been reported by Karsten Schnier. ---------------------------------------- Bug #448: Thinkpad T440P ACPI Battery Value Issues https://ticket.coreboot.org/issues/448 * Author: Karsten Schnier * Status: New * Priority: Normal * Target version: none * Start date: 2023-01-11 * Affected versions: master * Related links: [[https://github.com/linrunner/TLP/issues/657]] * Affected hardware: Thinkpad T440p * Affected OS: Artix / Arch Linux ---------------------------------------- Hello, I have been having some issues with TLP on my corebooted T440p. I am running artix linux with grub on top of coreboot (self compiled libreboot). I have had issues with the ACPI battery readings. Coreboot does not provide power readings, but instead only current readings. More details can be found in the TLP github issue: [[https://github.com/linrunner/TLP/issues/657#issuecomment-1293730559]] This causes TLP to not recognize the thinkpad and go to default mode. Additional, it prevents recalibration of the battery even when the thinkpad battery driver is forced. Is this due to misconfiguration in the coreboot build or issues with coreboot itself? Thank you! -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 1

[coreboot - Bug #449] (New) ThinkPad T440p fail to start, continous beeping & LED blinking
by Crazy Fox Feb. 21, 2026

Feb. 21, 2026

Issue #449 has been reported by Crazy Fox. ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449 * Author: Crazy Fox * Status: New * Priority: Normal * Category: coreboot common code * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.18 * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 5

[coreboot - Bug #439] (New) Lenovo X201 Turbo Boost not working
by Lukas Karg Nov. 17, 2025

Nov. 17, 2025

Issue #439 has been reported by Lukas Karg. ---------------------------------------- Bug #439: Lenovo X201 Turbo Boost not working https://ticket.coreboot.org/issues/439 * Author: Lukas Karg * Status: New * Priority: High * Target version: none * Start date: 2022-11-18 * Affected versions: master * Affected hardware: Lenovo X201 * Affected OS: Linux, Windows, ... ---------------------------------------- -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 7

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski Sept. 7, 2025

Sept. 7, 2025

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

5 7

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes May 2, 2025

May 2, 2025

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 6

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel Aug. 7, 2024

Aug. 7, 2024

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 12

Critical bug in RTC code for a leap year
by Michał Żygowski Feb. 29, 2024

Feb. 29, 2024

Hi folks, Another leap year, another problem with RTC in firmwares :) This time, unfortunately, this kind of bugs hit coreboot. I have issued a patch that fixes off-by-one error in the days count in month for a leap year: https://review.coreboot.org/c/coreboot/+/80790 It is quite critical, because depending on build date, it may revert to some very old date, like January 2023 or even older (depending on how long you run on current firmware). That said, the consequences are enormous: from false-negative expired certificates, to problems with filesystems, etc. It is worth considering an emergency coreboot release, is it not? Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

2 1

Re: Are we running libpayload unit tests in the CI?
by Martin Roth Feb. 28, 2024

Feb. 28, 2024

Hey Julius, Here's what we running: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… Martin Feb 27, 2024 at 18:31 by jwerner(a)chromium.org: > Hi, > > We've had unit test support in libpayload for over two years now, but > I just noticed that it doesn't look like we're actually running them > in the CI? E.g. if I look through a test run like this > https://qa.coreboot.org/job/coreboot-gerrit/252761/testReport/(root)/ > I can't find them anywhere (most of them have confusingly similar > names with coreboot unit tests, but "fmap_locate_area-test" is a > unique one). > > Is that intended or an oversight? Would it be easy to fix? (I'm not > super familiar with how the tests are integrated into Jenkins, but the > libpayload framework is pretty much a direct copy of the coreboot > framework, so if we can run the coreboot ones hopefully it should be > easy to run the libpayload ones as well?) > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

The road towards LTO: an update and a few question
by Arthur Heymans Feb. 28, 2024

Feb. 28, 2024

Hi community I picked up the good work done by Jacob Garber to implement link time optimization. The size gains are very substantial, with sometimes up to 15% reduction in binary size! Besides the size benefit it can make us a bit more lazy programmers: for instance we often put static inline functions in headers guarded by preprocessing depending on Kconfig options to not generate code we won't use. With LTO that can be relaxed a bit and the condition to do nothing can come from a separate linked object (at least I presume, I haven't tested). So to do LTO, both with clang and GCC, you use the compiler as a linker frontend, rather than invoke the linker directly. Object files that are optionally generated with the -flto flag to generate LTO optimized binaries. See https://review.coreboot.org/c/coreboot/+/40811 Jacob's patches dealt with GCC. I toyed around with clang. The clang linker frontend only works with LTO if using the GOLD or LLD linker. GCC can use the BFD linker we currently use, so that's an easy transition. Both those linkers, GOLD and LLD are less capable at parsing linker scripts than the BFD linker. Especially for the x86 bootblock, in which we do a lot of stuff, like ID, FIT pointer, ECFW pointer, early 16 bit code, ..., is complicated and those linkers fail on the arithmetics doing all that optimized linking. So my question would be, whether we want to support non BFD linkers and therefore not support all the magic in linker scripts we currently have. At most we are a few bytes less optimal than possible by for instance setting a good hardcoded size and offset of the early 16bit code rather than have the linker script optimize that. As a side note, LTO size gainz are bigger than what would be lost, by a large margin. https://review.coreboot.org/c/coreboot/+/80724/1/src/arch/x86/bootblock.ld is a crude example of how I got lld to be happy with the script. If non BFD linkers are acceptable, how do you propose we deal with it? When not using LTO you could in principle use a different linker of your choosing. Should we just move to lld to make sure CI is happy about linker scripts? Should it be an option, but then we won?t have CI being able to test it except on a few boards put in configs/ ? Maybe have both, but then change the default once LLD is known to work well enough? Sidenote: LLD is faster than BFD but linking is not an expensive step in coreboot anyway. Other more typical linker scripts like the ones you find on ARM and ARM64 platforms work just fine. There are some subtle differences e.g. https://review.coreboot.org/c/coreboot/+/80735 where the heap needs to be declared to not be loaded. There are a few issues though. LLD does not like the RISCV relocation symbols of libgcc.a... I read upstream bugreports about this issue, so maybe that will resolve itself. Same questions with LTO and CI. Should it be an option (IMO yes, as that's what both Linux and u-boot do) and which default settings do we want. For CI reasons LTO is a bit more strict and therefore useful, as the compiler frontend does throw more warnings than the plain linker when linking. What are your thoughts? Are there some caveats about linkers and LTO that are worth knowing, before moving forward? Kind regards Arthur

3 3

Need help from anyone at Meraki/Cisco
by David Hendricks Feb. 28, 2024

Feb. 28, 2024

Hi folks, As discussed in the Feb. 21 coreboot leadership meeting [1][2], concerns have been raised about coreboot source code releases for certain Meraki switch products. Requests have been made to open-source(a)meraki.com (mailto:open-source@meraki.com) about this with limited success in the past (MX84, MX250), though current requests for MS350 have gone practically unanswered. Since this problem scales with the product line-up, it seems an engineering approach to get code published - preferably upstream - will be a better way to solve it rather than repeated requests or escalation to the SFC. We're looking for anyone from Meraki/Cisco who would like to solve this by getting the code published. Several members of the coreboot community have experience working at (or with) companies in similar situations, and we're willing to help with this process. A few quick ideas mentioned in the recent meeting include a packaging tool to remove unused modules, a repo or branch on coreboot.org to host Meraki changes if they can't be mainlined easily, a license package that can integrate with Meraki's OS installer, etc. It's great that coreboot is used on these products and we believe that the coreboot community and corporate users such as Meraki mutually benefit when everyone's rights are respected. We strongly prefer an engineering approach to compliance with the GPLv2, but will look to other options if progress can't be made. If anyone at Meraki/Cisco happens to be reading this, feel free to contact me privately. [1] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…) [2] https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html (https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html)

1 0