June 2026 - coreboot - mail.coreboot.org

[coreboot - Bug #576] (New) GPIO locking is broken on Kaby Lake and possibly other platforms
by Mate Kukri Oct. 8, 2026

Oct. 8, 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

5 11

[coreboot - Bug #642] (New) x201t Turbo boost not working, CPU running hot
by Janez Novak Oct. 4, 2026

Oct. 4, 2026

Issue #642 has been reported by Janez Novak. ---------------------------------------- Bug #642: x201t Turbo boost not working, CPU running hot https://ticket.coreboot.org/issues/642 * Author: Janez Novak * Status: New * Priority: Normal * Category: chipset configuration * Target version: main * Start date: 2026-05-03 * Affected versions: main * Affected hardware: Lenovo X201 Tablet * Affected OS: All ---------------------------------------- Hello, i installed Coreboot on my x201t but turbo boost isn’t working and cpu won’t go past 2.1 GHz. My processor is an i7 640LM. Something i also noticed is that the system runs hotter with coreboot than with stock bios but i don’t know what’s causing that. -- 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 13

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

Oct. 3, 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 5

[coreboot - Bug #623] (New) On T480/S, missing P-state data from ACPI tables prevents Xen from performing frequency scaling
by herme herme Oct. 3, 2026

Oct. 3, 2026

Issue #623 has been reported by herme herme. ---------------------------------------- Bug #623: On T480/S, missing P-state data from ACPI tables prevents Xen from performing frequency scaling https://ticket.coreboot.org/issues/623 * Author: herme herme * Status: New * Priority: Normal * Target version: none * Start date: 2026-01-16 * Affected versions: main * Affected hardware: T480/S * Affected OS: QubesOS ---------------------------------------- Hello Currently, P-state data is missing from ACPI tables on T480/S. On my T480S running libreboot, this was confirmed by using the iasl command to decompile the tables at `/sys/firmware/acpi/tables/`; grepping for `_PSS`, `_PCT` and `_PPC` didn't return any results. (Another user)[https://codeberg.org/libreboot/lbmk/issues/394] has confirmed that this is also the case for the similar T480 device, with latest release build of libreboot (26.01 RC1). Meanwhile, in the vendor T480S BIOS, this data is present (contributed by @henk on #coreboot IRC channel): ``` # grep -r -e _PCT -e _PPC -e _PSS *.dsl DSDT.dsl: If (CondRefOf (\_PR.PR00._PPC)) DSDT.dsl: If ((CondRefOf (\_PR.PR00._PSS) && CondRefOf (\_PR.PR00._PPC))) SSDT1.dsl: External (_PR_.PR00._PSS, MethodObj) // 0 Arguments SSDT1.dsl: Name (_PPC, Zero) // _PPC: Performance Present Capabilities SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT1.dsl: Method (_PSS, 0, NotSerialized) // _PSS: Performance Supported States SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT1.dsl: Return (\_PR.PR00._PSS ()) SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT8.dsl: If (CondRefOf (\_PR.PR00._PSS)) ``` The Linux kernel doesn't rely on this data to perform frequency scaling, because native support is provided by the intel_pstate driver. However, the Xen kernel lacks this native support. When the data is missing, as in my case, the Xen-based QubesOS runs underclocked and is only barely usable. -- 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 8

[coreboot - Support #594] (New) "[EMERG] FspMemoryInit error, status=0x80000007" on Dell Optiplex 5040 SFF (0T7D40) using optiplex_3050 port code
by Walter Sonius Sept. 10, 2026

Sept. 10, 2026

Issue #594 has been reported by Walter Sonius. ---------------------------------------- Support #594: "[EMERG] FspMemoryInit error, status=0x80000007" on Dell Optiplex 5040 SFF (0T7D40) using optiplex_3050 port code https://ticket.coreboot.org/issues/594 * Author: Walter Sonius * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-28 * Affected versions: 25.03 * Affected hardware: Dell Optiplex 5040 SFF ---------------------------------------- To further test the "deguard", just tried to flash this unsupported `optiplex_3050` code on the Dell Optiplex 5040 SFF and results in this error. **[EMERG] FspMemoryInit error, status=0x80000007** The Dell Optiplex 3050 micro shares the same OEM BIOS file as the Optiplex 3050 SFF. Since the later board looks very similar tot the Optiplex 5040 SFF except for these obvious differences: 2 DDR4 (DDR4-sodimm on the micro) slots vs 4 DDR3L slots 1 PCIe 1x length (closed) vs 4x length (open) black slots 2 SATA (black missing) vs 3 SATA connectors 2 USB3 vs 4 USB3 back ports 1 DisplayPort vs 2 DisplayPorts 0 serial vs 1 serial port 0 VGA vs 1 VGA(using motherboard header) 0 PS2 vs 2 PS2 ports B250 chipset vs Q170 chipset I took the gamble and flashed the 3050 micro port, just by adding the "Flash descriptor", "ME" and "Igbe" regions of the working [Optiplex 5040 SFF deguarded ROM](https://ticket.coreboot.org/issues/588) and only inserting pci 1f6 and peg0 to the devicetree.cb all other code is untouched. ``` ... device domain 0 on + device ref peg0 on + register "Peg0MaxLinkWidth" = "Peg0_x16" + + # Configure PCIe clockgen in PCH + register "PcieRpClkReqSupport[0]" = "1" + register "PcieRpClkReqNumber[0]" = "0" + register "PcieRpClkSrcNumber[0]" = "0" + end device ref igpu on register "PrimaryDisplay" = "Display_iGFX" end ... ... device ref hda on end device ref smbus on end + device pci 1f.6 on end # GbE <--- Extra port which contains I219-V but disabled also works on Asrock H110 Pro BTC+ end ... ``` The boards serial output works and it detects RAM only in 2 of 4 slots that resemble the 3050 SFF. Also correct sizes 2GB, 4GB, 8GB and variants including DDR3 vs DDR3L gets correctly detected. Different CPU's will also run Skylake i3-6100T, Kabylake G3950 and Coffeelake G4900T. ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32. [DEBUG] CPU: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz [DEBUG] CPU: ID 506e3, Skylake H R0, ucode: 000000ef [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 190f (rev 07) is Skylake-S (2 Core) [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 1912 (rev 06) is Skylake DT GT2 [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route frr [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 87 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32. [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0900 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0050200 00003008 [DEBUG] GBLRST_CAUSE: 00000002 00000000 [DEBUG] prev_sleep_state 0 (S0) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [DEBUG] SPD @ 0x52 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 ``` Kabylake just with one Dimm inserted: ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) CPU G3950 @ 3.00GHz [DEBUG] CPU: ID 906e9, Kabylake H B0, ucode: 000000f7 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 590f (rev 06) is Kabylake-S [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 5902 (rev 04) is Kaby Lake DT GT1F [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 88 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A4 [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 ``` Coffeelake with just 1 Dimm inserted: ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) G4900T CPU @ 2.90GHz [DEBUG] CPU: ID 906eb, Unknown, ucode: 000000f5 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 3e0f (rev 08) is Unknown [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 3e93 (rev 00) is Unknown [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 86 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A4 [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 No Dimms at all inserted or other 2 unsupported banks used [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) G4900T CPU @ 2.90GHz [DEBUG] CPU: ID 906eb, Unknown, ucode: 000000f5 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 3e0f (rev 08) is Unknown [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 3e93 (rev 00) is Unknown [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 86 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A0 [INFO ] No memory dimm at address A4 [EMERG] FspMemoryInit error, status=0x80000007 ``` Will upload autoport logs soon, anyone already some obvious edits/hints to the existing [optiplex_3050 code](https://github.com/coreboot/coreboot/tree/main/src/mainboard/dell/opt… get me past this [EMERG] FspMemoryInit error, status=0x80000007 error? -- 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 14

[coreboot - Bug #631] (New) Topton X2E (N150) instabilities/timer issues
by Victor Bessonov Sept. 2, 2026

Sept. 2, 2026

Issue #631 has been reported by Victor Bessonov. ---------------------------------------- Bug #631: Topton X2E (N150) instabilities/timer issues https://ticket.coreboot.org/issues/631 * Author: Victor Bessonov * Status: New * Priority: Normal * Target version: none * Start date: 2026-02-23 * Affected versions: main * Affected hardware: Topton X2E * Affected OS: Linux, BSD ---------------------------------------- Image built from master (c9578eac246) as 25.12 does not support iPXE with SecureBoot in edk2 payload. After flashing the image a few bugs were discovered (all may be related to the same root cause) 1. Some USB drives and NVMes may be not detected in edk2 on boot - setting port speed to Gen3 manually and turning off power saving mostly helps with NVMes, however some flash drives may still need to be unplugged and re-plugged back 2. Booting from Ventoy USB mostly doesn't work - some linux images wait for mount and then fail with timout, others will just hang. Ventoy itself boots quickly and reliably. 3. USB booting from images written directly to flash mostly works, however BSD may still hang or panic out with spinlock timeout panic (OpnSense/FreeBSD) 4. Linux kernel reports about broken IRQ 9 (acpi_sci=low seemingly removes the message from dmesg) 5. After several tries to boot, BSD system got installed without any issues, however after rebooting into it the system became extremely laggy (even printing to the console worked word-by-word, high LA without any userspace CPU-loading process), switching the timer from LAPIC to HPET on running system seemingly resolved all the laginess instantly 6. Linux kernel reports that HPET is dysfunctional in PC10 (shouldn't it be fine on Alder Lake?) Build config (I tried both with default xApic and x2Apic - doesn't seem to change anything): ``` shell CONFIG_VENDOR_TOPTON=y # CONFIG_POST_DEVICE is not set # CONFIG_POST_IO is not set CONFIG_TPM_MEASURED_BOOT=y CONFIG_BOARD_TOPTON_X2E_N150=y # CONFIG_FSP_HYPERTHREADING is not set CONFIG_X2APIC_ONLY=y CONFIG_TPM2=y CONFIG_TPM_MEASURE_MRC_CACHE=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_EDK2=y CONFIG_EDK2_ENABLE_IPXE=y ``` The majority of these problems can be explained by faulty timer - the reason for a single ticket I'm also attaching the patch suggested in Discord channel for reference - doesn't seem to solve the issue ---Files-------------------------------- coreboot.log (63.9 KB) linux-boot.log (274 KB) gpio.patch (3.1 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

5 13

[coreboot - Bug #655] (New) m920q fails to do_global_reset() after 25.06
by Dawid Wrobel Aug. 23, 2026

Aug. 23, 2026

Issue #655 has been reported by Dawid Wrobel. ---------------------------------------- Bug #655: m920q fails to do_global_reset() after 25.06 https://ticket.coreboot.org/issues/655 * Author: Dawid Wrobel * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2026-06-30 * Affected versions: none * Affected hardware: m920q ---------------------------------------- I attempted to upgrade 25.06 to 26.06 and the system fails to reboot. Serial console shows: ``` [DEBUG] Starting cbfs_boot_device [INFO ] CBFS: Found 'fallback/payload' @0x186200 size 0x16f875 in mcache @0x89ced394 [DEBUG] Checking segment from ROM address 0xff91722c [DEBUG] Checking segment from ROM address 0xff917248 [DEBUG] Loading segment from ROM address 0xff91722c [DEBUG] code (compression=1) [DEBUG] New segment dstaddr 0x00800000 memsize 0xa00000 srcaddr 0xff917264 filesize 0x16f83d [DEBUG] Loading Segment: addr: 0x00800000 memsz: 0x0000000000a00000 filesz: 0x000000000016f83d [DEBUG] using LZMA [INFO ] Timestamp - starting LZMA decompress (ignore for x86): 12649673533 [INFO ] Timestamp - finished LZMA decompress (ignore for x86): 13078746300 [DEBUG] Loading segment from ROM address 0xff917248 [DEBUG] Entry Point 0x00803ac5 [DEBUG] BS: BS_PAYLOAD_LOAD run times (exec / console): 230 / 91 ms [INFO ] Timestamp - calling FspNotify(ReadyToBoot): 13124864519 [INFO ] Timestamp - returning from FspNotify(ReadyToBoot): 13157210020 [DEBUG] GLOBAL RESET! [INFO ] global_reset() called! [DEBUG] HECI: Global Reset(Type:1) Command [DEBUG] HECI: Global Reset success! ``` Everything seems just fine here, except the reset actually does *not* happen at this point, but it did with 25.06. This most likely has something to do with changes made `do_global_reset()` sometime after 25.06: ``` ~/coreboot-builder-scripts/m920q/build# git log 25.06..25.12 --oneline -- src/soc/intel/cannonlake/ src/mainboard/lenovo/m920q/ src/soc/intel/common/block/cse/ 7f93e2fe29 soc/intel/*: Add CFR option to enable/disable the Intel iGPU d5ea359347 soc/intel/**/cfr.h: Fix typo of "ACPI" in UI help text 84a4cdc6a5 soc/intel/*: Only skip PMC fallback on successful CSE reset 4f52ca6ba6 soc/intel/common/cse: Return usable error codes 50a59d4464 device: Add Kconfig to prepare for reworked verb table implementation fbc2d76ab3 soc/intel/*: Select 'DRAM_SUPPORT_DDRx' as appropriate da49da6c82 soc/intel: Add Arrow Lake-S/HX IDs 626c5364b8 tree: Use boolean for PcieRpSlotImplemented[] ``` and the candidate that stands out is `84a4cdc6a5`: ``` commit 84a4cdc6a533dc909a25fde25d99dca13ad2d28c Author: Sean Rhodes <sean(a)starlabs.systems> Date: Sat Nov 29 20:41:03 2025 +0000 soc/intel/*: Only skip PMC fallback on successful CSE reset cse_request_global_reset() returns CSE_TX_RX_SUCCESS on success. Make do_global_reset() explicatly check for that, and fall back CF9 for any other value. Test=Disable and enable the Intel ME on starbook_mtl and verify the system actually resets, rather than hanging. Change-Id: I4c3fb7995bca8e7fe3793b9aee021e4004ace933 Signed-off-by: Sean Rhodes <sean(a)starlabs.systems> Reviewed-on: https://review.coreboot.org/c/coreboot/+/90273 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier(a)gmail.com> diff --git a/src/soc/intel/alderlake/reset.c b/src/soc/intel/alderlake/reset.c index bc5815ac7a..3c13f6dfe5 100644 --- a/src/soc/intel/alderlake/reset.c +++ b/src/soc/intel/alderlake/reset.c @@ -8,7 +8,7 @@ void do_global_reset(void) { /* Ask CSE to do the global reset */ - if (cse_request_global_reset()) + if (cse_request_global_reset() == CSE_TX_RX_SUCCESS) return; /* global reset if CSE fail to reset */ diff --git a/src/soc/intel/cannonlake/reset.c b/src/soc/intel/cannonlake/reset.c index bc5815ac7a..3c13f6dfe5 100644 --- a/src/soc/intel/cannonlake/reset.c +++ b/src/soc/intel/cannonlake/reset.c @@ -8,7 +8,7 @@ void do_global_reset(void) { /* Ask CSE to do the global reset */ - if (cse_request_global_reset()) + if (cse_request_global_reset() == CSE_TX_RX_SUCCESS) return; /* global reset if CSE fail to reset */ diff --git a/src/soc/intel/elkhartlake/reset.c b/src/soc/intel/elkhartlake/reset.c index bc5815ac7a..3c13f6dfe5 100644 (...) ``` and 4f52ca6ba6: ``` commit 4f52ca6ba666dbebc7cc4e299d7b49796ac297d8 Author: Sean Rhodes <sean(a)starlabs.systems> Date: Sat Nov 29 20:37:06 2025 +0000 soc/intel/common/cse: Return usable error codes Currently, cse_request_reset() returns 0 if the reset type is unsupported or CSE isn’t ready. This is the same as CSE_TX_RX_SUCCESS, which makes failures impossible to detect. Return CSE_TX_ERR_INPUT or CSE_TX_ERR_CSE_NOT_READY respectively, so we can detect errors. Change-Id: Idede7342157901946ba62ba6fcda6f304a4a3fd0 Signed-off-by: Sean Rhodes <sean(a)starlabs.systems> Reviewed-on: https://review.coreboot.org/c/coreboot/+/90272 Reviewed-by: Jérémy Compostella <jeremy.compostella(a)intel.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier(a)gmail.com> diff --git a/src/soc/intel/common/block/cse/cse.c b/src/soc/intel/common/block/cse/cse.c index 1f519312ce..d02bb85b37 100644 --- a/src/soc/intel/common/block/cse/cse.c +++ b/src/soc/intel/common/block/cse/cse.c @@ -737,12 +737,12 @@ static int cse_request_reset(enum rst_req_type rst_type) if (!(rst_type == GLOBAL_RESET || rst_type == CSE_RESET_ONLY)) { printk(BIOS_ERR, "HECI: Unsupported reset type is requested\n"); - return 0; + return CSE_TX_ERR_INPUT; } if (!cse_is_global_reset_allowed() || !is_cse_enabled()) { printk(BIOS_ERR, "HECI: CSE does not meet required prerequisites\n"); - return 0; + return CSE_TX_ERR_CSE_NOT_READY; } heci_reset(); (...) ``` -- 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 - Refactoring #651] (New) grub version 2.14
by Ijon Kalufit Aug. 10, 2026

Aug. 10, 2026

Issue #651 has been reported by Ijon Kalufit. ---------------------------------------- Refactoring #651: grub version 2.14 https://ticket.coreboot.org/issues/651 * Author: Ijon Kalufit * Status: New * Priority: Low * Category: Payloads * Target version: none * Start date: 2026-06-01 ---------------------------------------- Please bump grub version to stable 2.14 release: https://lists.gnu.org/archive/html/grub-devel/2026-01/msg00029.html Development repository moved to freedesktop: https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=14949bbd1f1c6a36… -- 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 3

[coreboot - Bug #654] (New) crossgcc toolchain cannot be built - Intel acpica download broken
by Keith Hui July 11, 2026

July 11, 2026

Issue #654 has been reported by Keith Hui. ---------------------------------------- Bug #654: crossgcc toolchain cannot be built - Intel acpica download broken https://ticket.coreboot.org/issues/654 * Author: Keith Hui * Status: New * Priority: Urgent * Category: build system * Target version: main * Start date: 2026-06-17 * Affected versions: main * Related links: acpica Github: https://github.com/acpica/acpica/releases ---------------------------------------- I was not able to build the crossgcc toolchain because it was not able to download acpica-unix-20251212 from Intel. I cannot download from Github either because the script checks the hash and my own download won't match. When I attempt to access the Intel download directly using firefox, it apparently entered an infinite loop. wget gives me a zero length file. This leads me to believe this source is permanently gone. I then downloaded acpica-20251212 from Github and modified the checksum file to force it to match, then the patching failed because the source folder no longer has "unix" in the name. This is becoming much too involved in an area I don't usually operate in, hence this ticket. We'll need to quickly migrate to downloading acpica from Github. While we're at it, we should also validate release 20260408 (it has seen a newer release). -- 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

[RFC] Platform-Level Device Reset (_PRR) for CNVi Bluetooth over USB
by Sebastian Müller July 2, 2026

July 2, 2026

Hi all, While bringing up an Alder Lake-N board I hit a small gap in the CNVi Bluetooth support and would like to sanity-check an approach before writing the patch, since it touches a generic driver and has a couple of design choices a maintainer should steer. Problem ------- Intel CNVi Bluetooth reaches the host in one of two ways depending on the SoC/PCH configuration: * as a PCI function (Tiger Lake, Panther Lake, Nova Lake, ... - the IDs in bt_pci_device_ids[]), or * as a USB device on an internal XHCI port (Alder Lake-N and other IoT / "-N" configurations, where the BT companion is CNVi-over-USB). coreboot implements the CNVi Bluetooth Platform-Level Device Reset (PLDR) - the CNVP power resource with the _RST method, plus the _PRR object the kernel looks for - in src/soc/intel/common/block/cnvi/cnvi.c (cnvb_fill_ssdt()), and it is emitted only by the PCI Bluetooth driver (cnvi_bt_ops, bound to bt_pci_device_ids[]). When CNVi Bluetooth is on USB there is no PCI BT function, so cnvb_fill_ssdt() never runs and no _PRR is generated. The kernel logs: Bluetooth: hci0: No support for _PRR ACPI method and cannot perform the platform-level reset. (The stock vendor firmware on these boards also omits it, so this is not a regression - but coreboot already has the PLDR logic and could provide the _PRR here too.) What the reset actually is (hardware-verified, Alder Lake-N) ----------------------------------------------------------- On the board the CNVi Bluetooth companion enumerates as a USB2 device under \_SB.PCI0.XHCI.RHUB.HS10. The PLDR is a CNVi-sideband PCR write: * reset register = PCR port 0x73, offset 0x80 (0xfd730080 MMIO), CNVI_ABORT_PLDR value 0x80 (non-PCH-S) - matching the constants already in cnvi.c (CNVI_ABORT_PLDR, PID_CNVI). * readback reports CNVI_READY (0x04) at idle and PRRS reports completion - identical semantics to the PCI path. So the reset operation is the same as the existing PCI PLDR; only the ACPI device scope that carries the _PRR differs (a USB device node instead of the PCI BT function). I currently work around this with a hand-written power resource in the board dsdt.asl (a Scope(HS10) with a _RST doing PCRO(0x73, 0x80, 0x03) plus Name(_PRR)). It works, but every USB-CNVi-BT board would re-implement the same ASL by hand. Proposed mechanism ------------------ Let a board mark the USB port that carries the CNVi Bluetooth companion, and have coreboot emit the existing PLDR power resource + _PRR under that USB device's ACPI scope, reusing the PCI path's logic: 1. Refactor the PLDR acpigen out of cnvb_fill_ssdt() into a reusable helper in soc/intel/common/block/cnvi, e.g. cnvi_acpi_write_bt_pldr(), called by both the PCI BT driver and the new USB path (single source of truth for the PLDR ASL). 2. Add an opt-in to drivers/usb/acpi config (struct drivers_usb_acpi_config), e.g. bool is_intel_cnvi_bluetooth; 3. In drivers/usb/acpi/usb_acpi.c, when the flag is set, call the helper inside the USB device's scope (alongside the _DSD/_PRW it already emits). 4. The board enables it on the BT USB port in devicetree: chip drivers/usb/acpi register "is_intel_cnvi_bluetooth" = "1" device usb x.y on end # the CNVi BT companion port end The PLDR is already pure acpigen, and the SoC exposes the PCRO/PCRR sideband ASL helpers (src/soc/intel/common/acpi/pch_pcr.asl), so the helper is pure ACPI generation with no SoC C callback - it writes a method that calls the existing PCRR/PCRO (exactly what the board workaround does today). drivers/usb/acpi only needs to know whether to emit the resource, not how the reset works. Alternatives considered ----------------------- * Board-local DSDT (status quo): works, but duplicates the PLDR ASL per board and drifts from cnvi.c. * A dedicated drivers/intel/cnvi_usb_bt chip: heavier; drivers/usb/acpi already owns the USB device's ACPI node, so a flag there is lighter. * Auto-detection of the BT USB port: not feasible generically - which internal port carries the companion is board-specific. Open questions -------------- 1. Is drivers/usb/acpi the right home for the flag, or would you prefer a thin shim driver? 2. Should the flag instead be derived from the existing CNVi devicetree config so a board describes "CNVi BT is on USB port X" in one place? 3. Naming: is_intel_cnvi_bluetooth vs cnvi_bt_pldr vs reusing a CNVi enum. 4. Should the shared PLDR acpigen helper live in the common CNVi block or in a small ACPI helper next to pch_pcr.asl? If the direction is agreeable I'll send a patch (with the refactor + a board using it) and verify on the hardware. Thanks, Sebastian

3 4