August 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

ThinkPad T440p / coreboot 26.06: Intel ME initialization failure and ~30 minute reset
by ikattana Sept. 6, 2026

Sept. 6, 2026

Hello coreboot community, I'm ikattana and this is my currently diagnosing in my Lenovo ThinkPad T440p running with coreboot 26.06 & an EDK2 payload. I want to be transparent about the methodology: I am doing the diagnostic work with ChatGPT as an assistant. I use it mainly to organize the investigation, understand firmware layers, prepare read-only commands and interpret results. Important distinction: all logs, register values, hashes, firmware dumps and .config values listed below are real outputs obtained directly from my T440p or from firmware images that I previously read from its SPI chips. The explanations and interpretations of those values are provisional and may be wrong, so I would especially appreciate review from people familiar with Haswell/Lynx Point and Intel ME. I am deliberately avoiding further firmware writes until the cause is better understood. Main symptom The T440p boots coreboot, EDK2 and Ubuntu successfully, but the entire system resets abruptly after approximately 30 minutes. I also tested leaving the T440p inside EDK2 without booting Linux. The reset still occurs at approximately the same time. Because of that, I currently consider Linux unlikely to be the primary cause of the reset. Hardware / firmware - Lenovo ThinkPad T440p - Haswell / Lynx Point - coreboot 26.06 - EDK2 payload SPI flash: - U113: Winbond W25Q64FV, 8 MiB - U49: Winbond W25Q32FV, 4 MiB Coreboot was flashed only to the 4 MiB U49 chip. U113 was read and backed up, but was not written during this process. Observed Intel MEI / HECI runtime failure PCI: 00:16.0 Communication controller: Intel 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] Subsystem: Lenovo ThinkPad T440p [17aa:220e] Kernel output: mei mei0: H_RST is set = 0x80000015 mei mei0: wait hw ready failed mei mei0: hw_start failed ret = -62 fw status = 00003026 00080000 ... mei mei0: reset: reached maximal consecutive resets: disabling the device mei_me 0000:00:16.0: init hw failure mei_me 0000:00:16.0: initialization failed /dev/mei0 is not created. Direct PCI register reads These values were read directly from PCI configuration space: 0x40 = 0x00003026 0x44 = 0x80010020 0x48 = 0x00080000 0x4c = 0x70000001 My current interpretation is that ME does not complete initialization and HECI/MEI never reaches a usable HW READY state, but I would like this interpretation reviewed. Stored U113 / Intel ME evidence The following checks were performed only against firmware images backed up from U113. Intel Flash Descriptor: IFD signature = 0x0FF0A55A Region map: IFD 0x000000-0x000fff GbE 0x001000-0x002fff ME 0x003000-0x4fffff BIOS 0x500000-0xbfffff The ME region contains: - $FPT at ME + 0x10 - FPT checksum = 0x00 - 27 FPT entries - all parsed partition boundaries remain within the ME region - FTPR at 0x160000, size 0x0b0000 - NFTP at 0x210000 - $MN2 manifests present - reported ME version 9.0.31.1487 - FTPR RSA signature validated successfully - AltMeDisable bit not set Flash Master permissions also appear to allow Intel ME to read its own ME region. UMA / memory-related values also appear coherent from the checks performed so far. Again, these are observed values and validation results. Any conclusion that the complete ME image is healthy is still only an interpretation, not something I want to claim as proven. Backup consistency The saved physical U113 dump and the first 8 MiB of the reconstructed 12 MiB full image have identical SHA256 values. The ME regions extracted from both also have identical SHA256 values. The generated coreboot.rom, however, does not contain the same lower 8 MiB/ME contents, which appears consistent with the fact that the build was intended to provide the BIOS/Coreboot region while U113 was left untouched. Recovered coreboot build configuration From the actual saved .config: CONFIG_BOARD_LENOVO_THINKPAD_T440P=y CONFIG_ROM_SIZE=0x00c00000 CONFIG_CBFS_SIZE=0x700000 CONFIG_SOUTHBRIDGE_INTEL_LYNXPOINT=y CONFIG_DISABLE_ME_PCI=y CONFIG_MAINBOARD_USES_IFD_GBE_REGION=y # CONFIG_HAVE_IFD_BIN is not set I did not find ME_CLEANER, HAVE_ME_BIN, or an explicit ME replacement option in that saved configuration. Current working hypothesis This is the part I consider interpretation, not established fact: The stored ME region appears structurally coherent from the checks above, while the runtime ME state is abnormal very early during initialization. I therefore currently suspect either: - an ME internal/state/configuration problem not detected by the structural checks, - a Lynx Point / coreboot ME initialization issue, - or some interaction between the existing ME state and the coreboot 26.06 initialization path. I am also investigating whether that ME failure could explain the approximately 30-minute platform reset, especially because the same reset happens while staying in EDK2 before Linux is started. I do not want to claim that causality has been proven yet. Questions - How should HFS=0x00003026 and HFS2=0x00080000 be interpreted on Lynx Point / ME9? - Do these values point to a known ME9 failure state? - Could coreboot 26.06's Lynx Point ME initialization path contribute to this state? - Is CONFIG_DISABLE_ME_PCI=y relevant here, or would that normally only be acted upon after ME has initialized successfully? - Is ME firmware 9.0.31.1487 appropriate for this T440p? - Is there another ME partition/state check you would recommend before considering any rewrite of U113? - Does the approximately 30-minute reset pattern fit a known ME initialization failure on this generation? My priority is to recover stable operation while keeping coreboot if possible. Before writing U113 or changing the ME region, I would like to understand whether the evidence above points to an ME image/state problem or to coreboot/Lynx Point initialization. Any corrections to my interpretation are very welcome. The raw outputs and firmware evidence are the part I consider authoritative here; the diagnostic conclusions are still open for review. Thanks for your help. Enviado desde un correo electrónico seguro de [Proton Mail](https://proton.me/mail/home).

3 2

[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 Meetings Announcement And Agenda Call
by mina＠coreboot.org Aug. 31, 2026

Aug. 31, 2026

Dear coreboot Community, Please be reminded that our upcoming coreboot leadership meeting is scheduled for Wednesday, September 2, 2026. [1] Kindly update the meeting agenda with any issues you'd like to discuss during the meeting. [2] Thank you. Best regards, Mina. ## Current Agenda Items * No active issues on the agenda yet. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[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