July 2026 - coreboot - mail.coreboot.org

[coreboot - Bug #601] (New) superio/nuvoton/npcd378:379 FAN issue sandy/ivy-bridge & haswell on HP
by Walter Sonius Oct. 15, 2026

Oct. 15, 2026

Issue #601 has been reported by Walter Sonius. ---------------------------------------- Bug #601: superio/nuvoton/npcd378:379 FAN issue sandy/ivy-bridge & haswell on HP https://ticket.coreboot.org/issues/601 * Author: Walter Sonius * Status: New * Priority: Normal * Assignee: Patrick Rudolph * Category: board support * Target version: main * Start date: 2025-07-05 * Affected versions: 25.03 * Affected hardware: compaq_8200_elite_sff, compaq_8300_elite_sff, compaq_pro_6300_sff, 260_g1_dm, prodesk_600_g1_sff ---------------------------------------- The NPCD378 HWM FAN control is limited to the PSU FAN only but should work for the "compaq_8200_elite_sff" according to its [commit and instruction](https://review.coreboot.org/c/coreboot/+/26050), which states "... the SuperIO has to be notified that a write is ongoing. After clearing the write-lock bit all changes are applied...". Is there a special command that I missed that "clears the write-lock" or is there a bug and is its current implementation broken? Since adjusting the nvram parameter `sudo nvramtool -w psu_fan_lvl=1-7`and doing a reboot or cold powerup does show that the nvram parameter changes (can be confirmed by coreboot log or reading the nvram parameter after boot again) it never changes the actual PSU FAN speed! Tried multiple coreboot/seabios/edk2 versions the last 3 months on 5 different HP machines and came to the following conclusion. The following nvramtool `psu_fan_lvl=values` reflect the following PWM feedback from the coreboot log: ``` =1 [INFO ] NPCD378: PSU fan PWM 0x37 =2 [INFO ] NPCD378: PSU fan PWM 0x57 =3 [INFO ] NPCD378: PSU fan PWM 0x77 =4 [INFO ] NPCD378: PSU fan PWM 0x97 =5 [INFO ] NPCD378: PSU fan PWM 0xb7 =6 [INFO ] NPCD378: PSU fan PWM 0xd7 =7 [INFO ] NPCD378: PSU fan PWM 0xf8 ``` The following 3 supported sandy/ivy bridge HP variants share the same issue that nvram parameters and coreboot log show the requested manual `psu_fan_lvl` values but its PSU FAN speed won't change according to these values, atleast its FANs keep spinning after post/boot on these machines: ``` VALUE FAN SPEED compaq_8200_elite_sff NPCD378 adjusts remains same compaq_8300_elite_sff NPCD379 adjusts remains same compaq_pro_6300_sff NPCD379 adjusts remains same ``` The following 2 yet uncommited HP Haswell coreboot variants, "HP 260 G1 DM (Desktop Mini) Business PC" and "HP Prodesk 600 G1 SFF" both come with a NPCD379 and both share the same issue with the former 3 variants that the `psu_fan_lvl` value's can be adjusted by nvramtool(if cmos backend is added to the code) and verified during boot or nvramtool that these values have changed with affecting the PSU FAN speed in a undesired way: ``` VALUE FAN SPEED 260_g1_dm NPCD379 adjusts stops spinning prodesk_600_g1_sff NPCD379 adjusts stops spinning ``` These 2 Haswell machines will halt "and stop spinning" the PSU FAN as soon as during post the "PSU fan PWM" value kicks in!!! A side note is needed for the HP 260 G1 DM since it only has a single FAN, so I'm not sure if its CPU or its PSU FAN technically and its OEM BIOS misses a option the adjust FAN speed compared to the other 4 HP models! Another side note for the Prodesk 600 G1 SFF is that I'm forced to use a aftermarket non HP CPU FAN(old Intel CPU FAN), but it keeps spinning after coreboot post. Removing the FAN/HWM code from the superio NPCD378 source, leads to the opposite it will force the PSU FAN to its MAXIMUM speed after poweron but atleast keeps the FAN spinning. This maximum forced full speed FAN behaviour can also be replicated by removing one of the 4 FAN wires, red or white cable not sure anymore. Interesting FAN notes: In case of the "Prodesk 600 G1", swapping its PSU with the PSU from the "compaq_8300_elite_sff" keeps the PSU fan spinning during and after coreboot post but it will still not adjust its PSU FAN speed to its requested values! Also the other way around, putting the PSU of the "Prodesk 600 G1" inside the "compaq_8300_elite_sff" stops the PSU FAN during coreboot post, but running the OEM firmware, keeps the fan spinning and let it adjust to all requested values on its donor FAN. So it seems there is a certain PWM compatibility to control these FAN's in similar ways between these boards. It seems the the newer PSU FAN from the Haswell generation can actually disable / stop spinning on a certain PWM value while older FAN keep spinning on these lower/ same PWM values. Compared to the [initial support commit](https://review.coreboot.org/c/coreboot/+/26050) by Patrick Rudolph, around April 2021 there were some [code](https://review.coreboot.org/c/coreboot/+/52511) [fixes](https://review.coreboot.org/c/coreboot/+/52671) but after that the last time this `psu_fan_lvl` code was verified functional was between 2023-05-02 and 2023-07-03 noted in the [boardsupport commit](https://review.coreboot.org/c/coreboot/+/74906) of the variant `compaq_8300_elite_sff_usdt` by Riku Viitanen. History for "coreboot/src/superio/nuvoton/npcd378" shows [6 patches](https://github.com/coreboot/coreboot/commits/main/src/superio/nuvo… from november 2023 till today. Any tips hints welcome. -- 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 5

[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 #658] (New) asus p5g41c-m-lx pcie discovery of realtek 10ec:8168
by Gabriel Turlea Aug. 30, 2026

Aug. 30, 2026

Issue #658 has been reported by Gabriel Turlea. ---------------------------------------- Bug #658: asus p5g41c-m-lx pcie discovery of realtek 10ec:8168 https://ticket.coreboot.org/issues/658 * Author: Gabriel Turlea * Status: New * Priority: Normal * Target version: none * Start date: 2026-07-14 ---------------------------------------- I have tried to port coreboot to asus-p5g41c-m-lx by using the existing pg541t-m-lx variant. Everything works great except I cannot get the onboard lan realtek 10ec:8168 to be detected by coreboot. The card shows up and works once linux boots. Adding some register values in the overridetree.cb seems to disable the card even in linux. Please let me know what supporting info I should provide. 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

5 21

[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