October 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

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

EU-CRA and the ongoing standardization work
by Werner Zeh Oct. 23, 2025

Oct. 23, 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…

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

[coreboot - Bug #612] (New) coreboot blocks PCIe root port: reg_script_run_step / P.m CAP (Baytrail)
by Walter Sonius Oct. 21, 2025

Oct. 21, 2025

Issue #612 has been reported by Walter Sonius. ---------------------------------------- Bug #612: coreboot blocks PCIe root port: reg_script_run_step / P.m CAP (Baytrail) https://ticket.coreboot.org/issues/612 * Author: Walter Sonius * Status: New * Priority: Normal * Category: chipset configuration * Target version: none * Start date: 2025-10-13 * Affected versions: main * Affected hardware: ZOTAC ZBOX-CI320NANO series ---------------------------------------- The ZBOX-CI320NANO series from ZOTAC see code [CB:89528](https://review.coreboot.org/c/coreboot/+/89528) behaves different concerning enabling PCIe root ports via devicetree.cb compared to earlier Baytrail ports from Lenovo H500s [CB:89170](https://review.coreboot.org/c/coreboot/+/89170) and Jetway NF9N-2930 [CB:89279](https://review.coreboot.org/c/coreboot/+/89279). Although devicetree.cb lists all PCIe root ports for enabling 1c.0, 1c.1 1c.2, and 1c.3, coreboot first enables each device during early init: ``` ... [SPEW ] PCI: 00:00:1c.0: enabled 1 [SPEW ] PCI: 00:00:1c.1: enabled 1 [SPEW ] PCI: 00:00:1c.2: enabled 1 [SPEW ] PCI: 00:00:1c.3: enabled 1 ... [SPEW ] PCI: 00:00:1c.0: enabled 1 [SPEW ] PCI: 00:00:00.0: enabled 1 #force eth as builtin also tried without it? [SPEW ] PCI: 00:00:1c.1: enabled 1 [SPEW ] PCI: 00:00:1c.2: enabled 1 [SPEW ] PCI: 00:00:1c.3: enabled 1 ... ``` Later on disables each device except 1c.2 which contains miniPCIe wifi: ``` ... [SPEW ] PCI: 00:00:1c.0 [8086/0000] bus ops [DEBUG] No PCIe device present. [WARN ] reg_script_run_step: POLL timeout waiting for 0x328 to be 0x1000000, got 0x0 [DEBUG] PCI: 00:00:1c.0: Disabling device: 1c.0 [DEBUG] Power management CAP offset 0xa0. [DEBUG] PCI: 00:00:1c.0 [8086/0f48] disabled [SPEW ] PCI: 00:00:1c.1 [8086/0000] bus ops [DEBUG] No PCIe device present. [WARN ] reg_script_run_step: POLL timeout waiting for 0x328 to be 0x1000000, got 0x0 [DEBUG] PCI: 00:00:1c.1: Disabling device: 1c.1 [DEBUG] Power management CAP offset 0xa0. [DEBUG] PCI: 00:00:1c.1 [8086/0f4a] disabled [SPEW ] PCI: 00:00:1c.2 [8086/0000] bus ops [DEBUG] PCI: 00:00:1c.2 [8086/0f4c] enabled [SPEW ] PCI: 00:00:1c.3 [8086/0000] bus ops [DEBUG] No PCIe device present. [WARN ] reg_script_run_step: POLL timeout waiting for 0x328 to be 0x1000000, got 0x0 [DEBUG] PCI: 00:00:1c.3: Disabling device: 1c.3 [DEBUG] Power management CAP offset 0xa0. [DEBUG] PCI: 00:00:1c.3 [8086/0f4e] disabled ... [SPEW ] PCI: 00:00:1c.0: enabled 0 [SPEW ] PCI: 00:00:1c.1: enabled 0 [SPEW ] PCI: 00:00:1c.2: enabled 1 [SPEW ] PCI: 00:00:1c.3: enabled 0 ... ``` While the 1c.2 root port stays enabled it is not listed in the OS using lspci, however the miniPCIe WIFI device behind it does list and works. A Realtek RTL8111F Gb NIC on the PCIe 1c.0 root port remains undetected! This only misbehaves on the ZBOX, Lenovo and Jetway boards enable and do list their PCIe root ports including the devices on those root ports. The coreboot log mentions the following lines while unintentionally disabling a PCIe root port: ``` [WARN ] reg_script_run_step: POLL timeout waiting for 0x328 to be 0x1000000, got 0x0 [DEBUG] Power management CAP offset 0xa0. ``` Besides using devicetree.cb as a method to enable / disable devices, are there special GPIO values that may override this or Power management CAP offset values that I haven't yet set up correctly? Could this be an issue with the Realtek Gb adapter that needs a special gpio/reset pin and Kconfig option like the Asrock H110M-DVS (which also doesn't seem to have a working NIC)? Tried two coreboot code revisions including a older one that works fine on the earlier Baytrail Lenovo and Jetway ports and different EDK2 revs: ``` coreboot-25.06-77-g812d0e2f626d coreboot-25.09-70-g98a54453284e-dirty EDK2 (MrChromebox-2502/2505/2508) ``` Also tried disabling libgfxinit, removing VBT and following options: ``` CONFIG_RESOURCE_ALLOCATION_TOP_DOWN=n CONFIG_PCIEXP_COMMON_CLOCK=n CONFIG_PCIEXP_ASPM=n CONFIG_PCIEXP_L1_SUB_STATE=n CONFIG_PCIEXP_CLK_PM=n ``` It doesn't make a difference except that disabling TOP_DOWN breaks the miniPCIe which contradicts this recent patch[CB:89464](https://review.coreboot.org/c/coreboot/+/89464) and [BUG 611](https://ticket.coreboot.org/issues/611). Comparing the build .config of the Jetway with this ZOTAC only reveals this obvious difference which I still need to rule out, besides some uart/serial/sio options: ``` < CONFIG_USE_DDR3=y > CONFIG_DRAM_SUPPORT_DDR3=y #both boards use DDR3L SODIMM(s) (Jetway uses 2) ``` More and complete logs are available in the attachment zotac_zbox-ci320nano.zip. ---Files-------------------------------- zotac_zbox-ci320nano.zip (179 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

2 7

2025_10_22 coreboot Group Review Session
by mina＠coreboot.org Oct. 20, 2025

Oct. 20, 2025

Hello coreboot, Kindly note that we have an upcoming group review session scheduled for Wednesday, October 22, 2025. https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is a link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Please add any specific patches you'd like the group to review to the top of the sheet. Since an hour may not be sufficient to address all patches on the list, reviewing patches in advance is greatly appreciated. Thank you. Best regards, Mina.

1 0