December 2025 - 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 #598] (New) Lenovo m920x RAM compatibility issue
by Dawid Wrobel April 6, 2026

April 6, 2026

Issue #598 has been reported by Dawid Wrobel. ---------------------------------------- Bug #598: Lenovo m920x RAM compatibility issue https://ticket.coreboot.org/issues/598 * Author: Dawid Wrobel * Status: New * Priority: Normal * Target version: none * Start date: 2025-06-04 * Affected versions: main ---------------------------------------- Hi there, I recently flashed my m902x with coreboot (25.03-643-g69a067a9d62c-dirty). Everything seemed to work fine until I tried upgrading the memory from a single 8GB stick to 2 x 32GB (Crucial CT2K32G4SFD832A, https://eu.crucial.com/memory/ddr4/CT2K32G4SFD832A) The system won't boot in any configuration (a single stick in either slot or both). I get no display out, the system stays on and stuck, apparently, with high CPU usage causing fans to kick in. I have no serial port in this system at the moment (backordered an extension module), but am wondering if it will be of any help and if there's any other way to debug it? Do note that the system *is* capable of running 64GB memory, as it was reported already, so I wonder if this is a matter of some SPD misconfiguration? Crucial lists the 2x16GB modules as compatible with this system (https://eu.crucial.com/compatible-upgrade-for/lenovo/thinkcentre-m920x-tiny…) and they have seemingly identical specs as the 2x32GB ones. -- 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 5

[coreboot - Bug #592] (New) Lenovo M920q can't use DIMM2 RAM slot
by Coreboot Enjoyer April 6, 2026

April 6, 2026

Issue #592 has been reported by Coreboot Enjoyer. ---------------------------------------- Bug #592: Lenovo M920q can't use DIMM2 RAM slot https://ticket.coreboot.org/issues/592 * Author: Coreboot Enjoyer * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2025-04-15 * Affected versions: main * Related links: https://github.com/Thrilleratplay/coreboot-builder-scripts/issues/33 Also, it looks like a similar issue to https://ticket.coreboot.org/issues/462 * Affected hardware: Lenovo M920q ---------------------------------------- Building the current coreboot source, as well as commits 497298708c330deb479fbf3ee6a3acc8bff2a102, 640a41f3ee938b794b140218921e0fd63b1d9235 and 7945a31e9172ec2939cc1abc6036962a6efb601b, produces the firmware, that allows to initialize the motherboard if only DIMM1 RAM slot is filled. It fails to initialize, if DIMM1 RAM slot is empty and DIMM2 is filled, as well as if both DIMM1 and DIMM2 are filled. The issue is reproducible with different RAM sticks. I tried every possible combination with Kingston 32GB (2666MHz, CL 19-19-19-43) and Samsung 8GB (2400MHz, CL 17-17-17-39) -- the motherboard recognizes RAM sticks correctly, but still fails when the DIMM2 is filled with any RAM stick. I have also attached the build config file, which uses most of the default options. ---Files-------------------------------- m920q-dimm2-config.txt (27.6 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

6 8

[coreboot - Bug #620] (New) X230(t) does not work since commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 was merged
by Hustler One March 22, 2026

March 22, 2026

Issue #620 has been reported by Hustler One. ---------------------------------------- Bug #620: X230(t) does not work since commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 was merged https://ticket.coreboot.org/issues/620 * Author: Hustler One * Status: New * Priority: High * Category: coreboot common code * Target version: main * Start date: 2025-12-31 * Affected versions: main * Related links: https://www.reddit.com/r/coreboot/comments/1pu5vlp/x230t_does_not_get_past_… https://www.reddit.com/r/coreboot/comments/1pyzcvf/no_video_output_with_upd… * Affected hardware: x230t ---------------------------------------- Releases 25.09, 25.12 are affected. 25.06 works. The commit 97dbfd3098ae12ef3f51e5f95cd6d66c25214205 prevents the x230t from going past the `postcar` stage, hence it being inoperable since it won't load into the main payload. I have attempted to debug using flashconsole but the trail runs cold after `postcar`. Credit to iam_tj for finding the commit. Also, Libreboot is somehow unaffected by this. I don't know if lbmk undoes this commit or not at this time. -- 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 4

[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 #576] (New) GPIO locking is broken on Kaby Lake and possibly other platforms
by Mate Kukri Jan. 25, 2026

Jan. 25, 2026

Issue #576 has been reported by Mate Kukri. ---------------------------------------- Bug #576: GPIO locking is broken on Kaby Lake and possibly other platforms https://ticket.coreboot.org/issues/576 * Author: Mate Kukri * Status: New * Priority: Normal * Target version: none * Start date: 2025-01-30 ---------------------------------------- Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to [TPM GPIO reset attacks](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html). Trying to fix this by marking the affected GPIOs as locked in gpio.h and even also selecting `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` does not work. This was discovered last year and briefly discussed on #coreboot, but it came up again on the Heads matrix group in relation to supporting the TPM on the in-progress ThinkPad T480 port. -- 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 2

coreboot architecture with signed FSP
by Werner Zeh Jan. 1, 2026

Jan. 1, 2026

Dear coreboot community, as some of you may have heard from the OSFC already, there are plans at Intel to restructure the way FSP is executed [1]. The main goal is to switch to an operation mode where only Intel signed FSP binaries can be executed. This comes, according to the current plans, with an architectural change that will affect coreboot's execution flow. In this proposed, changed execution flow a new FSP component will be loaded at reset vector and do the verification of the following FSP components like FSP-T, FSP-M and FSP-S. Then, the execution flow will continue in FSP and calls to coreboot code shall happen. In this new flow, no self-built FSP binaries can be executed anymore as they are not signed by Intel. I want to start a discussion with the community and Intel to see if we can come up with something better than this approach which will not heavily change the coreboot architecture but nevertheless provide a level of confidentiality for Intel's FSP blobs. You all are warmly welcome to participate in this discussion. Feel free to forward this invitation to anyone who might be interested. The call is planned for December 3th at 7 pm CET and will be hosted on Google Meet [2]. Feel free to join and let's have a constructive discussion. Werner [1] https://www.osfc.io/2025/talks/intel-r-signed-fsp-and-verified-boot/ [2] https://meet.google.com/kgh-nquh-usm

4 3

[coreboot - Bug #528] Building `emulation/qemu-i440fx` with `CONFIG_CBFS_VERIFICATION=y` fails
by Nicholas Chin Dec. 27, 2025

Dec. 27, 2025

Issue #528 has been updated by Nicholas Chin. It looks like this affects more than just QEMU. The commit message in CB:74243 does alludes to this; anything that uses `MICROCODE_UPDATE_PRE_RAM` will be affected. This is selected by default for systems that don't select `CPU_INTEL_FIRMWARE_INTERFACE_TABLE`, which seems to be everything pre-Haswell. Those boards do still get a fair amount of activity (especially Sandy Bridge/Ivy Bridge). ---------------------------------------- Bug #528: Building `emulation/qemu-i440fx` with `CONFIG_CBFS_VERIFICATION=y` fails https://ticket.coreboot.org/issues/528#change-2202 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2024-03-01 ---------------------------------------- Building a coreboot image for `emulation/qemu-i440fx` with `CONFIG_CBFS_VERIFICATION=y` fails. ``` $ git log --oneline --no-decorate -1 ff2d863515 drivers/intel/gma: Allow SPARK function with side effects $ make savedefconfig $ more defconfig CONFIG_ANY_TOOLCHAIN=y # CONFIG_SEPARATE_ROMSTAGE is not set CONFIG_TIMESTAMPS_ON_CONSOLE=y # CONFIG_USE_BLOBS is not set CONFIG_NO_POST=y CONFIG_USE_EXP_X86_64_SUPPORT=y # CONFIG_PCI_ALLOW_BUS_MASTER is not set CONFIG_CBFS_VERIFICATION=y CONFIG_CONSOLE_SERIAL_921600=y # CONFIG_CONSOLE_QEMU_DEBUGCON is not set CONFIG_PAYLOAD_FILO=y CONFIG_FILO_HEAD=y CONFIG_FILO_USE_AUTOBOOT=y CONFIG_FILO_AUTOBOOT_FILE="hda1:/vmlinuz initrd=hda1:/initrd.img root=/dev/sda1 ro quiet" $ make -j4 […] CC ramstage/arch/x86/boot.o CC ramstage/arch/x86/breakpoint.o LINK cbfs/fallback/postcar.debug LINK cbfs/fallback/bootblock.debug x86_64-linux-gnu-ld.bfd: warning: build/postcar/mainboard/emulation/qemu-i440fx/exit_car.o: missing .note.GNU-stack section implies executable stack x86_64-linux-gnu-ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker x86_64-linux-gnu-ld.bfd: warning: build/cbfs/fallback/postcar.debug has a LOAD segment with RWX permissions HOSTCC cbfstool/ifittool (link) HOSTCC cbfstool/ifwitool (link) HOSTCC cbfstool/cse_fpt (link) x86_64-linux-gnu-ld.bfd: warning: build/bootblock/cpu/x86/reset16.o: missing .note.GNU-stack section implies executable stack x86_64-linux-gnu-ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker x86_64-linux-gnu-ld.bfd: warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with RWX permissions x86_64-linux-gnu-ld.bfd: build/bootblock/cpu/qemu-x86/cache_as_ram_bootblock.o: in function `cache_as_ram': /dev/shm/coreboot/src/cpu/qemu-x86/cache_as_ram_bootblock.S:46:(.init+0x1f): undefined reference to `walkcbfs_asm' /dev/shm/coreboot/src/cpu/qemu-x86/cache_as_ram_bootblock.S:46:(.init+0x1f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `walkcbfs_asm' make: *** [src/arch/x86/Makefile.mk:101: build/cbfs/fallback/bootblock.debug] Fehler 1 make: *** Es wird auf noch nicht beendete Prozesse gewartet.... ``` -- 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 0

2025-12-24 coreboot Leadership Meetings Canceled
by mina＠coreboot.org Dec. 23, 2025

Dec. 23, 2025

Dear coreboot community, Kindly note that the leadership meetings scheduled for December 24, have been canceled because it falls within the Christmas break. Wishing everyone a Merry Christmas! Thank you. Best regards, Mina. (https://docs.google.com/document/d/17pKpjnAbmxIidKO4YbntT2slqXa4NjQ80abUsjM…)

1 0

[coreboot - Bug #619] (New) Lenovo T480s headphone jack detection is inconsistent - fix for T480 can be applied.
by Oberon 4071 Dec. 23, 2025

Dec. 23, 2025

Issue #619 has been reported by Oberon 4071. ---------------------------------------- Bug #619: Lenovo T480s headphone jack detection is inconsistent - fix for T480 can be applied. https://ticket.coreboot.org/issues/619 * Author: Oberon 4071 * Status: New * Priority: Normal * Target version: none * Start date: 2025-12-09 * Affected versions: 24.12 * Affected hardware: Lenovo T480s * Affected OS: Linux ---------------------------------------- The headphone jack detection on the Lenovo T480s is inconsistent, where at least in the GNOME desktop, the audio doesn't always automatically switch to the headphone jack. There was a recent fix for this issue on the T480 with [Gerrit Change 90023](https://review.coreboot.org/c/coreboot/+/90023) . On my own coreboot builds, I applied the same changes from this Gerrit commit from the file `src/mainboard/lenovo/sklkbl_thinkpad/variants/t480/hda_verb.c` to the file `src/mainboard/lenovo/sklkbl_thinkpad/variants/t480s/hda_verb.c`, and the headphone jack is now working properly on my laptop. It would be great to integrate this change for the T480s into the mainline coreboot sources. -- 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