July 2025 - coreboot - mail.coreboot.org

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

Nov. 17, 2025

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

1 7

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

Nov. 13, 2025

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 4

[coreboot - Bug #592] (New) Lenovo M920q can't use DIMM2 RAM slot
by Coreboot Enjoyer Nov. 8, 2025

Nov. 8, 2025

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

6 6

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

Sept. 7, 2025

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

5 7

[coreboot - Bug #538] (New) [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction
by Brian L Sept. 7, 2025

Sept. 7, 2025

Issue #538 has been reported by Brian L. ---------------------------------------- Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction https://ticket.coreboot.org/issues/538 * Author: Brian L * Status: New * Priority: High * Target version: none * Start date: 2024-05-14 * Affected hardware: Lenovo x230 ---------------------------------------- Environment: - Lenovo x230 - Stock screen replaced with Pixel Qi (not sure if relevant) (plug & play LVDS) - Coreboot using Heads (coreboot + linuxboot) - Official lenovo docking station connected to external monitor via DisplayPort Bug Trigger: Using Heads/coreboot fine for years with my Pixel Qi screen modded x230. I then bought a Lenovo docking station. Booted up, everything worked fine. Disconnected from dock, booted up, and there was no bios screen. Screen did not turn on until taken over by Linux Kernel. Once in userspace, wayland could no longer identify the monitor as a Pixel Qi or its proper resolution. EDID is blank. Booting with docking station allows bios to show on external display. Restarting did *not* fix the issue, reflashing heads did *not* fix the issue, flashing skulls (coreboot + seabios) did *not* fix the issue. Flashing stock bios *did fix* the issue. I can now see BIOS screen and get proper EDID in userspace whether on the dock or not. *However* reflashing coreboot again, even coming from stock bios working state, and I immediately now no longer get a BIOS screen or EDID, even without ever introducing the dock again. Essentially now bricked with anything but stock bios. -- 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 20

[coreboot - Bug #535] (New) T420: Power light stays off after reboot
by frantic from xboot Sept. 7, 2025

Sept. 7, 2025

Issue #535 has been reported by frantic from xboot. ---------------------------------------- Bug #535: T420: Power light stays off after reboot https://ticket.coreboot.org/issues/535 * Author: frantic from xboot * Status: New * Priority: Low * Target version: master * Start date: 2024-04-24 * Affected hardware: Lenovo ThinkPad T420 ---------------------------------------- I have recently encountered a bug in coreboot where if you reboot the computer, the keyboard power light will stay turned off after it turns back on. Where if you do a clean boot, the light turns on. I am unsure whether this is a coreboot or payload issue. I am using GRUB as my payload. Just run the `reboot` command in Linux and it should be reproducible. Priority set to `Low` as it doesn't affect usability all too much. -- 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 4

[coreboot - Bug #552] (New) X201 not booting with edk2 payload
by Maya Matuszczyk Sept. 7, 2025

Sept. 7, 2025

Issue #552 has been reported by Maya Matuszczyk. ---------------------------------------- Bug #552: X201 not booting with edk2 payload https://ticket.coreboot.org/issues/552 * Author: Maya Matuszczyk * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2024-08-18 * Affected hardware: x201 ---------------------------------------- Hello, I tried to update my x201 with a new version of coreboot(I lost the working one). After building(using default config + set to x201 + bigger cbfs + linear high-res framebuffer) with latest release I couldn't get anything with edk2 to boot on it. I've tried changing `RESOURCE_ALLOCATION_TOP_DOWN` and using newer/older tags of MrChromebox's edk2 fork. -- 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 3

[coreboot - Bug #600] (New) [Intel Eaglestream platform ]PCH HSIO bifurcation.
by guo deng Sept. 7, 2025

Sept. 7, 2025

Issue #600 has been reported by guo deng. ---------------------------------------- Bug #600: [Intel Eaglestream platform ]PCH HSIO bifurcation. https://ticket.coreboot.org/issues/600 * Author: guo deng * Status: New * Priority: Normal * Target version: 25.03 * Start date: 2025-06-21 * Due date: 2025-06-30 * Affected versions: 25.03 * Needs backport to: 25.03 * Related links: Please refer to the following linker which is about the intel eaglestream platform CRB board in Coreboot. https://github.com/coreboot/coreboot/tree/main/src/mainboard/intel/archerci… * Affected hardware: [Intel Eaglestream platform ] * Affected OS: NONE ---------------------------------------- [Intel Eaglestream platform ] I have already checked the coreboot code , but I can't find any code about how to configure the PCH HSIO pcie bifurcation by Intel FSP ? Please refer to the following linker which is about the intel eaglestream platform CRB board in Coreboot. ( https://github.com/coreboot/coreboot/tree/main/src/mainboard/intel/archerci… ) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 1

[coreboot - Bug #604] (New) mb/hp: ProDesk 600 G1 SFF (Haswell / NPCD379) warm boot freezes
by Walter Sonius Aug. 1, 2025

Aug. 1, 2025

Issue #604 has been reported by Walter Sonius. ---------------------------------------- Bug #604: mb/hp: ProDesk 600 G1 SFF (Haswell / NPCD379) warm boot freezes https://ticket.coreboot.org/issues/604 * Author: Walter Sonius * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2025-07-30 * Affected versions: 25.03 ---------------------------------------- This board is still WIP code, see [review.coreboot.org](https://review.coreboot.org/c/coreboot/+/88616) Warm boots as in poweron after a previous successful shutdown will hang/freeze boot after "NMI sources disabled" but before [DEBUG] LynxPoint H PM init? However reboots and cold boots are not affected: ``` [INFO ] NMI sources disabled. ... #endless spew repeating following blocks [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: GPE0 [DEBUG] GPE0_STS: PME_B0 [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: GPE0 [DEBUG] GPE0_STS: PME_B0 [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: GPE0 [DEBUG] GPE0_STS: PME_B0 ... #system might never reach the following line as in freeze or is extreme slow, or hangs during booting OS [DEBUG] LynxPoint H PM init ``` A shutdown before this failing warm boot looks like this coreboot log: ``` [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: PERIODIC SLP_SMI #<----------------------------------------bad shutdown warm boot will freeze [DEBUG] SMI#: Entering S5 (Soft Power off) Or like this also bad warm boot after this shutdown [DEBUG] SMI_STS: SLP_SMI #<-------------------------------------------------also issue on warm boot [DEBUG] SMI#: Entering S5 (Soft Power off) ``` A shutdown before a "correct" warm boot looks like this in coreboot log: ``` [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: GPE0 PM1 [DEBUG] PWRBTN GPE0_STS: PME_B0 #<------------- initiated with help of pressing power button [NOTE ] coreboot-25.06-77-g812d0e2f626d-dirty Fri Jul 04 13:18:33 UTC 2025 x86_32 smm starting (log level: 7)... [DEBUG] SMI_STS: GPE0 SLP_SMI #<------------------------------------------- good shutdown no warm reboot issues [DEBUG] SMI#: Entering S5 (Soft Power off) ``` There might be a lot more to this but these are some differences I noticed related to SMI_STS: xxx SLP_SMI where xxx can be GPEO/empty/PERIODIC: ``` [DEBUG] SMI_STS: GPE0 SLP_SMI == warm boot okay (maybe because powerbutton shutdown?) [DEBUG] SMI_STS: SLP_SMI [DEBUG] SMI_STS: PERIODIC SLP_SMI ``` Any hints welcome, to unblock this port? ---Files-------------------------------- coldboot-fast-dblog.txt (53.1 KB) coldboot-fast-nri-dblog.txt (58.5 KB) prodesk-600-g1-oem-autoport-logs.zip (648 KB) warmboot-slow-dblog.txt (634 KB) warmboot-slow-nri-dblog.txt (164 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

1 2

New GNU Make regression? Why some Makefile.inc's romstage-options get interpreted as Makefile targets?
by Mike Banon July 30, 2025

July 30, 2025

While trying to build the ancient (<=4.11) versions of coreboot for research purposes, I get CC romstage/superio/winbond/common/early_init.o LINK cbfs/fallback/romstage.debug OBJCOPY cbfs/fallback/romstage.elf make: *** No rule to make target '".car.data"', needed by 'build/coreboot.pre'. Stop. because of the following Makefile.inc line: $(CONFIG_CBFS_PREFIX)/romstage-options := -S ".car.data" If I comment out this line, I get "No rule to make target '-P'" because of $(CONFIG_CBFS_PREFIX)/romstage-options += -P $(CONFIG_XIP_ROM_SIZE) If I comment out this too, everything goes well until the final coreboot.rom assembly stage, where a cbfstool prints "E: Encountered illegal degenerate region name in -r list" and deletes my coreboot.rom However, " $(CONFIG_CBFS_PREFIX)/romstage-options += --xip " is fine and doesn't cause any problems... Please tell, why these errors are happening now and not before? My host's GNU make --version is 4.4.1, but I tried everything down to 4.3 and still can't properly get rid of these errors (unfortunately can't use 4.2.1 because it gives a segmentation fault on new Linux) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 1