coreboot April 2025

coreboot@coreboot.org

12 participants
23 discussions

coreboot Leadership Meeting: Call for Interest from the Asian Region
by coreboot org 17 Apr '25

17 Apr '25

Hello all, We’d like to gauge interest in establishing a second coreboot leadership meeting scheduled at a time more accessible for contributors across Asia. As our community has grown globally, we recognize that our current meeting time may present challenges for many of our contributors in Asian time zones. While we've tried to be inclusive by encouraging people to submit agenda items via the mailing list or directly to the agenda regardless of attendance ability, we understand this is not the same as active participation in discussions. This topic was raised during the most recent leadership meeting, so we'd like to determine if there's sufficient interest to warrant a second regularly scheduled meeting. While all three members of the coreboot leadership team probably will not be able to attend this additional meeting, we see value in creating a dedicated forum to: - Hear perspectives from our Asian contributors - Discuss region-specific challenges and opportunities - Ensure diverse viewpoints are incorporated into project decisions - Build stronger connections with contributors across all regions If you're based in Asia or would benefit from an alternative meeting time, please respond to this post indicating: - Your interest in attending - Preferred time window - Early, overlapping more with the Americas - Late, overlapping more with Europe and Africa Feel free to respond on the mailing list or directly to the coreboot.org(a)gmail.com email if you don't feel comfortable posting to the mailing list. We'll assess the responses to determine if there's enough interest to move forward with this initiative. Thanks! Martin

1 0

Qotom Q20331G9-S10 (Intel Denverton C3758R) — Two Issues Remaining (VGA + Console Drop)
by Enzo Potenza 16 Apr '25

16 Apr '25

Dear all, I’ve been working on porting coreboot to the Qotom Q20331G9-S10, which uses the Intel Atom C3758R (Denverton). So far: System boots All onboard devices are detected properly Payload (EDK II) loads fine Issues: 1. VGA Not Working Pre-OS The board uses an AST2400 BMC for VGA output. I’ve added the VGA ROM (pulled from the official site) into the coreboot image, but no output is visible during pre-OS phase. (without the ROM, no VGA at all) 2. Console Stops After Payload The serial console works fine during the bootblock and into romstage/post. However, once coreboot hands off to the payload, the console garbles and stops showing valid output. Here’s the last clean output before it breaks: FSP End of Firmware ... Install PPI: BD44F629-EAE7-4198-87F1-39FAB0FD717E NotifyPhaseApi() - End [Status: 0x00000000] ▒`▒f▒▒▒f▒▒▒▒`▒f▒▒▒f▒▒▒▒`▒f▒▒▒f▒▒ If anyone has any ideas, I’d love to hear your inputs. Happy to share build configs or logs if that helps. Thanks! enzo

1 0

[RFC] Towards a more complete redundancy of firmware with vboot
by Michał Żygowski 16 Apr '25

16 Apr '25

Hello coreboot community, Google's vboot has been with us (coreboot) for many years already, probably mainly on Chromebook devices. In 3mdeb we have been using it with coreboot for a couple years as well. From a user and developer point of view, vboot is a great library that hardens the firmware with cryptographic verification of the executable code and provides a redundant A/B + recovery layout scheme. However, it comes with a couple of limitations we have observed throughout the years: 1. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the vboot submodule revisions get updated too. Occasionally it may lead to backwards incompatibility between recovery and A/B parts (assuming that only A/B is updated and recovery remain write protected) . 2. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the car.ld (or any program layout shared across multiple stages in both recovery and A/B like bootblock and romstage/postcar) gets updated too. Almost every time it leads to backwards incompatibility and a brick. There may be other cases as well, which need special handling and testing, because it may not be safe to flash an update on a device. One solution may be to freeze the codebase on given revisions and avoid updating them, but that's not what we typically want. I came up with the following idea: Leverage the top-swap mechanism to provide two bootblocks with verstages (assuming verstage starts in bootblock and no separate verstage): - Top Swap RO - used for booting recovery only (built with vboot submodule from coreboot revision X) - Top Swap RW - used for booting RW A/B only (built with vboot submodule from coreboot revision Y) Example (simplified) flashmap layout could look like this: RW_B (optional RW_A WP_RO { FMAP GBB COREBOOT TOP_SWAP_RO } TOP_SWAP_RW - TOP_SWAP_RW would be the default one placed right under top of 4G. - Whenever vb2api_fail is called, coreboot would have to switch the top swap to TOP_SWAP_RO. - TOP_SWAP_RW is updatable so should be unlocked, like RW_A/B. But verstage should be protected coreboot has some code/logic for building an image with top swaps, so I think it is doable. Unsolved problems or questions: 1. Having two distinct vboot builds does not prevent from backwards incompatibility in vboot NV storage layout. Does the layout of vbnv even change? For the past 10 years the offsets have not changed (only one new flag and one flag name modification). So we can assume it is not a problem. 2. There might be other incompatibilities I am unaware of. Different recovery reasons codes shouldn't be a problem generally. 3. Chromebooks usually write-protect WP_RO region. In the scheme above, the TOP_SWAP_RW would be unprotected. Do Chromebooks still use WP screws and SPI chip provided protections? - In 3mdeb we use the chipset PRx registers to protect the recovery part of the firmware. It gives a possibility of 4K granular protection of the SPI firmware. Multiple PRx registers could be used here: 1 - protect WP_RO, 2 - protect TOP_SWAP_RW. On updates lift the protection on second PR only - Ideally the top swaps could be protected/verified by solutions like Boot Guard (AFAIK boot Guard can support top swap, haven't researched yet how it works in practice). Then write protection of TOP_SWAP_RW would not be a concern. 4. Changes in the flashmap layout. This is rather out of scope, as any change in flashmap layout would imply updating whole BIOS region typically. So I would exclude this for now. The solution is Intel-only, not aware of top-swaps on AMD, except PSP/ASP 16MB flash page limitations and top-swap like behavior. Also AMD is a whole different story, because bootblock is integrated into PSP/ASP directory, which has its own A/B (and two level) mechanism + psp_verstage... So leaving that aside for now. Looking for your insights, comments, suggestions, any problems you see with the approach (haven't started any development yet) etc. Appreciated in advance. Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

2 2

[coreboot - Bug #592] (New) Lenovo M920q can't use DIMM2 RAM slot
by Coreboot Enjoyer 16 Apr '25

16 Apr '25

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

2 1

[coreboot - Bug #591] (New) Build error on lenovo/m920q due to removal of ##ROM_BASE##
by Oberon 4071 14 Apr '25

14 Apr '25

Issue #591 has been reported by Oberon 4071. ---------------------------------------- Bug #591: Build error on lenovo/m920q due to removal of ##ROM_BASE## https://ticket.coreboot.org/issues/591 * Author: Oberon 4071 * Status: New * Priority: Normal * Category: userspace utilities * Start date: 2025-04-11 * Affected hardware: lenovo/m920q ---------------------------------------- The current coreboot sources (25.03-161-gf6d40a9564) will not build when specifying lenovo/m920q as the mainboard, regardless of which payload is used. The following error occurs during build: ``` IFDTOOL IFDTOOL -p cnl -F build/fmap-template.fmd 3rdparty/blobs/mainboard/lenovo/m920q/descriptor.bin File 3rdparty/blobs/mainboard/lenovo/m920q/descriptor.bin is 4096 bytes Wrote layout to build/fmap-template.fmd HOSTCC cbfstool/fmaptool.o HOSTCC cbfstool/cbfs_sections.o HOSTCC cbfstool/fmap_from_fmd.o HOSTCC cbfstool/fmd.o HOSTCC cbfstool/fmd_parser.o HOSTCC cbfstool/fmd_scanner.o HOSTCC cbfstool/fmap.o HOSTCC cbfstool/kv_pair.o HOSTCC cbfstool/valstr.o HOSTCC cbfstool/fmaptool (link) FMAP build/util/cbfstool/fmaptool -h build/fmap_config.h build/fmap.fmd build/fmap.fmap syntax error FATAL: Failed while processing provided descriptor make: *** [Makefile.mk:1263: build/fmap.fmap] Error 4 ``` It appears that this error is the result of the commit a7eb390796ef4ba7baaffca741664b816de12256 (mb/*/*/*.fmd: Start flash at 0). This commit appears to remove all references to the token ##ROM_BASE##, but ifdtool has not been updated to reflect this change. The following patch appears to fix the issue on my end and allow coreboot to build for lenovo/m920q: ``` diff diff --git a/util/ifdtool/ifdtool.c b/util/ifdtool/ifdtool.c index 94105efe52..b21a89c0e1 100644 --- a/util/ifdtool/ifdtool.c +++ b/util/ifdtool/ifdtool.c @@ -1094,7 +1094,7 @@ static void create_fmap_template(char *image, int size, const char *layout_fname exit(EXIT_FAILURE); } - char *bbuf = "FLASH@##ROM_BASE## ##ROM_SIZE## {\n"; + char *bbuf = "FLASH ##ROM_SIZE## {\n"; if (write(layout_fd, bbuf, strlen(bbuf)) < 0) { perror("Could not write to file"); exit(EXIT_FAILURE); ``` In case it is needed, I have attached my .config settings. ---Files-------------------------------- config_lenovo_m920q_20250411.txt (26.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

3 3

[coreboot - Bug #590] (New) emulation/qemu-i440fx with GRUB payload: cbmem fails with `Table not found.`
by Paul Menzel 14 Apr '25

14 Apr '25

Issue #590 has been reported by Paul Menzel. ---------------------------------------- Bug #590: emulation/qemu-i440fx with GRUB payload: cbmem fails with `Table not found.` https://ticket.coreboot.org/issues/590 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-10 * Affected versions: 25.03 ---------------------------------------- See `emulation/qemu-i440fx/25.03-154-g9e757b3396/2025-04-10T04_35_41Z` in the board status repository for the configuration. Building coreboot (25.03-154-g9e757b3396) for emulation/qemu-i440fx with GRUB (master) as payload, `cbmem` does not find the CBMEM tables and aborts with `Table not found.`. qemu-system-x86_64 -bios /dev/shm/coreboot/build/coreboot.rom -L /dev/shm -enable-kvm -smp cpus=2 -m 1G -hda /dev/shm/debian-32.img -serial stdio -net nic -net user,hostfwd=tcp::22222-:22 Using SeaBIOS, it works. -- 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 3

Bachelor thesis *Whole Process Persistence with coreboot* by Max Streicher, KIT
by Paul Menzel 14 Apr '25

14 Apr '25

Dear coreboot folks, I just found a the bachelor thesis *Whole Process Persistence with coreboot* by Max Streicher [1], from February 2024 (last year). It’s great to see, that coreboot allowed them to do research. Kind regards, Paul [1]: https://os.itec.kit.edu/downloads/2024_BA_Streicher_Whole_Process_Persisten…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 14 Apr '25

14 Apr '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 16, 2025. [1] Please take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #589] (New) X230 eDP panel not detected by libgfxinit but works in Linux
by Jens Moelzer 09 Apr '25

09 Apr '25

Issue #589 has been reported by Jens Moelzer. ---------------------------------------- Bug #589: X230 eDP panel not detected by libgfxinit but works in Linux https://ticket.coreboot.org/issues/589 * Author: Jens Moelzer * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-09 * Affected versions: 25.03 * Affected hardware: X230 eDP ---------------------------------------- I have a X230 with a eDP panel (LP125WF4-SPB1). My FHD mod board is self designed but somewhat similar to the nitrocaster mod (just much simpler). It takes DP_D from the docking port (2 lanes plus AUX plus HDP) and BACKLIGHT_ON + PANEL_BKLT_CTRL from the LVDS connector and connects everything directly to the eDP panel. It is totally passive and has no MCU and no EEPROM. I also attached the schematic (dasher-fhd.pdf). The panel stays blank until Linux boots and from the debug output it seems libgfxinit does not detect it at all. Once drm/i915 in Linux takes over the panel starts up and works perfectly fine including backlight control. From the log it seems that coreboot/libgfxinit for some reason can't read the EDID but Linux has no problem reading the EDID. An external display attached to the mini-DP port is detected by libgfxinit and does work with coreboot. I'm using coreboot 25.03 with "ThinkPad X230 eDP Mod (2K/FHD)" as mainboard and libgfxinit with linear framebuffer and edk2 payload. Though I also tried other payloads, gfx initialization settings, various changes to `gma-mainboard.ads`, `devicetree.cb` and other hacks I though worth a try. I also played around a lot with modifications to the VBT (explicitly configuring my panel including DTD, enabling edidless, ...). But nothing made any difference. Attached you find a coreboot log with Ada debug enabled (cbmem.log) and a full Linux boot log with `drm.debug=0x1ff` (linux.log) from the same boot since I though it might help to see what i915 is doing to get the panel working. ---Files-------------------------------- cbmem.log (58.3 KB) linux.log (301 KB) dasher-fhd.pdf (74.4 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 0

2025_04_09 coreboot Group Review Session
by mina＠coreboot.org 07 Apr '25

07 Apr '25

Hello coreboot! Our upcoming group review session is scheduled for Wednesday, April 9. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 937#gid=1695410937) Kindly add any specific patches you'd like the group to review to the top of the sheet. As an hour is not sufficient to address all patches on the list, reviewing patches in advance would be greatly appreciated. Thank you. Best regards, Mina.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2025