October 2025 - coreboot - mail.coreboot.org

[coreboot - Bug #449] (New) ThinkPad T440p fail to start, continous beeping & LED blinking
by Crazy Fox Feb. 21, 2026

Feb. 21, 2026

Issue #449 has been reported by Crazy Fox. ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449 * Author: Crazy Fox * Status: New * Priority: Normal * Category: coreboot common code * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.18 * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 5

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

Jan. 25, 2026

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

2 2

EU-CRA and the ongoing standardization work
by Werner Zeh Dec. 14, 2025

Dec. 14, 2025

Hi coreboot community. As presented on the last OSFC, there is quite some work currently ongoing in the context of the upcoming EU Cyber Resilience Act (EU-CRA, [1]). Among the activities is the creation of harmonized standards which will be used to help in conformity assessment of the different applications, which are driven by ETSI. Some of the standards are now publicly available for review and I encourage you to take a closer look and provide feedback. You can find the draft standards as well as a feedback form here: [2]. Especially the standard for Boot Managers (see [3]) is highly interesting for the firmware space. In case of questions feel free to reach out to me. Werner [1]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CONSIL%3APE_100_2023_RE… [2]: https://docbox.etsi.org/CYBER/EUSR/Open/ [3]: https://docbox.etsi.org/CYBER/EUSR/Open/EN-304-623_V0.0.4_2025-09-30_Boot_M…

4 10

[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

2025-10-29 - coreboot Leadership Meetings Minutes
by mina＠coreboot.org Oct. 30, 2025

Oct. 30, 2025

# 2025-10-29 - coreboot Leadership Meetings ## Open Action Items * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs: “Do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?). * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long-term project. ## Announcements & Events ## Late GMT coreboot Leadership Meeting Minutes ## Attendees Martin Roth, Matt DeVillier, Jay Tallbott, David Hendricks, Karthik R, Mina Asante, Julius Werner, Alicja Michalksa. ## Minutes ### [Martin] Discuss the early meeting agenda. ### [Julius] C23 patches * Should we switch to C23? Benefits/drawbacks? * [Martin] I don’t see an issue with the concept, but we had already decided to wait for a few years until the toolchains in the distros that people are using have caught up. * If so, does it need to be a Kconfig? * [Martin] I don’t think a kconfig makes sense. Either we use it or we don’t. * Which C23 features should we actually start using? * [Currently proposed patches](https://review.coreboot.org/c/coreboot/+/89701/2) add a lot of cruft and churn… * Also, should we maybe have some guidelines about how to weigh the trade-off between practical benefit and churn/disruption to other developers (Gerrit notifications, breaking git blame, etc.) for large, tree-wide, auto-generated patches? * Let’s stick to any non-invasive patches for now. Having the #if spread throughout the codebase is… ugly. * Should these sorts of patches be discussed more broadly before being implemented? ### [Martin] Testing coreboot. * We discussed testing with the 9E team - we’re going to start working with them to set up some test boards that would report back to coreboot. * coreboot would build the binaries via the CI - these would be password protected so that we don’t distribute working binaries. * Siemens tests are already set up and can be triggered by adding the user to the patch as a reviewer. * Need to continue working with google to have builds from the main branch report back to coreboot somehow. * Discussed testing setups: * Alicja is working on a custom board using an STM32 for 50 euros. Maybe 100 for a professional setup with isolation. * David: Look at “littlebmc,” which was a presentation at OSFC. The SOC itself might be obtainable from Alibaba. The Zephyr work could be generically useful as a way to control the STM32 (or whatever) from an OS that can be easily adapted for servers. * Martin created a spreadsheet a while back with a number of remote setups: (https://docs.google.com/spreadsheets/d/1aDfPYRuFz0GfNl3-UAt9GYIpSW3Ui72XHwN…) ## Early GMT coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Ziang Wang, Shuo Liu. ## Minutes ### [Ziang] ARM LBBR counterpart on RISC-V? (may be LBRS -- Linuxboot Boot & Runtime Service) * RISC-V community raised an open https://lf-rise.atlassian.net/wiki/spaces/HOME/pages/661585922/COREBOOT_00_… * Do we have buddies that worked on the LBBR before interested in LBRS for RISC-V this time? * If we are into this, there will be a new task group set up for drafting the LBRS spec. * Ron is probably going to be knowledgeable about this. David will talk to him. ### [Ziang] Open: Standalone Ramstage? * We now have emerging silicon designs that do not let the application processor bootstrap itself, which means DRAM and PCIe RC etc. will be taken care of by other co-processors, and the AP starts directly into RAM without CAR. * In this case there would be less interest in implementing a full combo with bootblock and romstage. Yet Ramstage Hardwaremain is still necessary for a complete platform firmware. * Will it make sense to use ramstage as a standalone software (with payload for the rest), like we add a special build option in coreboot? * Maybe we could try it out with OpenSIL on AMD platforms first? * [Martin] The way that coreboot is architected, we really expect to run through all the various stages. We don’t have an issue with a standalone ramstage, but it may take some architectural changes. I think that a single combined stage with all phases might make the most sense. I don’t oppose this attempt in any way. * [David] There are some ARM-based platforms that have (almost) empty romstage, for example. So even if we can't easily skip a stage entirely without ugly architectural changes, we can strip it down to practically nothing. ### [Shuo Liu] Is it possible to mirror the VPD repository on GitHub? (https://chromium.googlesource.com/chromiumos/platform/vpd) * This shouldn’t be an issue. Let’s discuss it and make sure we understand exactly what’s needed. # Next Leadership Meetings Date * November 12, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. We now host two leadership meetings, one in early GMT and one in late GMT, to better accommodate participants from the Asian time zones. Kindly note that both sessions use the same meeting notes and Google Meet link. # coreboot Leadership Meeting Notes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Oct. 27, 2025

Oct. 27, 2025

Dear coreboot Community, Please be reminded that the upcoming leadership meetings for both the early GMT and late GMT time zones are scheduled for Wednesday, October 29, 2025. [1] Kindly take a moment to update the agenda items with issues you'd like to discuss during these meetings. [2] Thank you. ## Current Agenda Items ### [Julius] C23 patches * Should we switch to C23? Benefits/drawbacks? * If so, does it need to be a Kconfig? * Which C23 features should we actually start using? * [Currently proposed patches](https://review.coreboot.org/c/coreboot/+/89701/2) add a lot of cruft and churn… * Also, should we maybe have some guidelines about how to weigh the trade-off between practical benefit and churn/disruption to other developers (Gerrit notifications, breaking git blame, etc.) for large, tree-wide, auto-generated patches? [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Oct. 24, 2025

Oct. 24, 2025

Dear coreboot Community, Please note that the upcoming leadership meetings for both the early GMT and late GMT time zones are scheduled for Wednesday, October 29, 2025. [1] Kindly take a moment to update the agenda items with issues you'd like to discuss during these meetings. [2] Thank you. Best regards, Mina. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #614] (New) USE_OPTION_TABLE=y with HAVE_ACPI_RESUME=y build Error 1 on baytrail
by Walter Sonius Oct. 21, 2025

Oct. 21, 2025

Issue #614 has been reported by Walter Sonius. ---------------------------------------- Bug #614: USE_OPTION_TABLE=y with HAVE_ACPI_RESUME=y build Error 1 on baytrail https://ticket.coreboot.org/issues/614 * Author: Walter Sonius * Status: New * Priority: Normal * Target version: none * Start date: 2025-10-19 * Affected versions: main * Affected hardware: baytrail ---------------------------------------- On multiple tested Baytrail platforms, building coreboot errors when enabling CMOS support `USE_OPTION_TABLE` and `HAVE_ACPI_RESUME` active, while the later is the default for most platforms. Affected hardware: * bostentech/gbyt4 * jetwayipc/nf9n-2930 [CB:89279](https://review.coreboot.org/c/coreboot/+/89279) * lenovo/h500s_10157 [CB:89170](https://review.coreboot.org/c/coreboot/+/89170) Affected coreboot versions: ``` coreboot 25.06-77-g812d0e2f626d coreboot 25.09-70-g98a54453284e ``` Reproduce: ``` make distclean touch .config ./util/scripts/config --enable VENDOR_BOSTENTECH ./util/scripts/config --enable BOARD_BOSTENTECH_GBYT4 ./util/scripts/config --enable USE_OPTION_TABLE make olddefconfig make ``` Error message: ``` ... CC bootblock/southbridge/intel/common/spi.o CC bootblock/superio/ite/common/early_serial.o CC bootblock/superio/ite/common/gpio.o LINK cbfs/fallback/bootblock.debug /home/neon/Desktop/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: section .car.mrc_var LMA wraps around address space /home/neon/Desktop/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/drivers/pc80/rtc/option.o: in function `acpi_is_wakeup_s3': /home/neon/Desktop/coreboot/src/include/acpi/acpi.h:1984:(.text.sanitize_cmos+0xf): undefined reference to `acpi_get_sleep_type' make: *** [src/arch/x86/Makefile.mk:83: build/cbfs/fallback/bootblock.debug] Error 1 ``` A workaround to get CMOS support enabled and build is to have `HAVE_ACPI_RESUME` disabled (removed from Kconfig) for these boards. However if the board also has an active serial port with `CONFIG_CONSOLE_SERIAL` coreboot console output, you have to disable that as well otherwise you get the Error below (Jetway nf9n-2930). ``` CC bootblock/southbridge/intel/common/reset.o CC bootblock/southbridge/intel/common/spi.o CC bootblock/superio/fintek/common/early_serial.o LINK cbfs/fallback/bootblock.debug /home/neon/Desktop/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: section .car.mrc_var LMA wraps around address space make: *** [src/arch/x86/Makefile.mk:83: build/cbfs/fallback/bootblock.debug] Error 1 ``` Contrary the `google/rambi/ninja` image builds without this error: ``` make distclean touch .config ./util/scripts/config --enable VENDOR_GOOGLE ./util/scripts/config --enable BOARD_GOOGLE_NINJA ./util/scripts/config --enable USE_OPTION_TABLE make olddefconfig make ``` -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 2