- coreboot - mail.coreboot.org

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

25 Apr '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 30, 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 #579] (New) MAC address programmed by coreboot to onboard RTL8111F does not persist
by Keith Hui 23 Apr '25

23 Apr '25

Issue #579 has been reported by Keith Hui. ---------------------------------------- Bug #579: MAC address programmed by coreboot to onboard RTL8111F does not persist https://ticket.coreboot.org/issues/579 * Author: Keith Hui * Status: New * Priority: Normal * Category: chipset configuration * Target version: none * Start date: 2025-03-01 * Related links: https://review.coreboot.org/c/coreboot/+/86172 * Affected hardware: Asus P8Z77-V LE PLUS w/ RTL8111F * Affected OS: Linux kernel 6.12.7 ---------------------------------------- I am producing a coreboot port on Asus P8Z77-V LE PLUS on which this issue is observed. It has a RTL8111F ethernet controller without EEPROM for vital product data. I enabled the rtl8168 driver in coreboot so I can configure the LEDs and MAC address. Lights work great, but the MAC address always revert to `00:00:00:00:00:05` by the Linux r8169 kernel module. I would then have to reassign its proper MAC address using `ip link change eno0 address <mac>`. The device appears to be taking the address I programmed, but r8169 reverts it both on init and teardown, insisting that `00:00:00:00:00:05` is its permanent MAC address. Survival of coreboot programmed MAC address before r8169 driver is confirmed by a debug read back I inserted in the coreboot rtl81xx driver, as well as by temporarily blacklisting r8169. Vendor firmware is unaffected. -- 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 3

Memory map and type 13 (Fwd: Re: e820: Undefined type not treated as AddressRangeReserved)
by Paul Menzel 23 Apr '25

23 Apr '25

Dear coreboot folks, Some payloads, like GRUB [1] and formerly FILO [2], convert coreboot’s memory map(?) to E820 table, and copy the type 13. Currently, the Linux kernel does not follow the ACPI specification to treat the undefined types as AddressRangeReserved, so `cbmem` does not work, which can be worked around with `iomem=relaxed`. I brought this up to the Linux x86 maintainers, and Ingo Molnar kindly responded [attached, 3], and asked: > Just curious: why do they mark it type 13? What semantics do they > expect? It's not just some random value I suspect. Could somebody of the experts here shed some light on this? Thank you and kind regards, Paul PS: Ingo also prepared some patches to make Linux follow the ACPI specification [4]. [1]: https://ticket.coreboot.org/issues/590 [2]: https://review.coreboot.org/c/filo/+/51120 [3]: https://lore.kernel.org/all/aADkQoJE62OdWMhu@gmail.com/ [4]: https://lore.kernel.org/all/20250421185210.3372306-1-mingo@kernel.org/

1 0

[coreboot - Support #581] (New) success new variant "compaq_pro_6300_sff" for hp/snb_ivb_desktops compatible with "compaq_8300_elite_sff" template
by Walter Sonius 23 Apr '25

23 Apr '25

Issue #581 has been reported by Walter Sonius. ---------------------------------------- Support #581: success new variant "compaq_pro_6300_sff" for hp/snb_ivb_desktops compatible with "compaq_8300_elite_sff" template https://ticket.coreboot.org/issues/581 * Author: Walter Sonius * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2025-03-15 ---------------------------------------- Successful flash and coreboot SeaBIOS functioning of a HP "compaq_pro_6300_sff" with a unchanged "compaq_8300_elite_sff" template using coreboot (24.12-758-g1e7ba810c6bb) and SeaBIOS (version rel-1.16.3-0-ga6ed6b70). These two HP Compaq devices are extremely similar, they use the same OEM proprietary BIOS upgrade files. Hardware wise the only 3 noticeable differences are that the "compaq_8300_elite_sff" comes with a Q77 chipset, SuperIO NPCD378 and J32 labeled 16x length "white" PCI-E slot versus a Q75 chipset, SuperIO NPCD379HAKFX with the J32 labeled slot populated with a limited physical 1x length "black" PCI-E slot on the "compaq_pro_6300_sff". Flashing from OEM proprietary BIOS 3.08revA enabling the FDO jumper on the motherboard as described for the compaq_8300_elite_sff works by booting with "iomem=relaxed" kernel parameter and specifying the specific 16MB chip 25Q128A: flashrom -p internal -w cbtest.rom -c "MT25QL128" Tested and Working: Poweron/Poweroff/Reboot CPU i3-3220 / e3-1225v2 RAM 1x 2x 4x populated slots total of 4GB/8GB/16GB/24GB (both 1.35v and 1.5v modules mixed with ECC) Serial port (including coreboot) PS2 keyboard (including SeaBIOS) PS2 mouse SATA 3 ports (blue/white/white) USB 2.0 4x front & 2x back ports USB 3.0 4x back ports Ethernet 1Gbit/100Mbit Display port works in SeaBIOS and OS VGA port only works in OS! PCI using realtek RTL8169 1Gb PCIE 3.0 16x using 2.0 8x 10Gb intel X540-AT2 / using 1.0 16x Nvidia Geforce 6200 LE (also works in SeaBIOS) PCIE 2.0 1x using 2.0 1x 2.5Gb realtek RTL8125 PCIE 2.0 1x using 1.0 1x 1Gb intel 82574L (SeaBIOS loads option rom) Audio built-in speaker (plays music in OS compared to legacy bleep pc-speaker) Audio front panel 3.5 mm headphone jack (auto disables built-in Speakers and selects Headphones) Audio front panel 3.5 mm headphone&mic jack (only microphone works with 4 pin 3.5mm combi mic/headphone) Audio back panel 3.5mm green jack (manually select Line Out and it works) Sensors CPU and 2 motherboard sensors SuperIO Booting USB / SATA(HDD/DVD) OS: Fedora-mate Linux kernel 6.11.4 / 6.13.6, KDE neon Linux kernel 6.8.0-52 Flashrom: needs additional parameters compared to OEM BIOS both for read/write depending on flashrom version? flashrom -p internal:boardmismatch=force,ich_spi_mode=hwseq -w test.rom -c "Opague flash chip" Tested not Working: RAM ECC functioning (see coreboot log) SATA port black Wakeonlan, it just auto wakes from itself so cannot verify... iGPU multigpu with PCIE nvidia geforce 6200 le, only PCIE nvidia geforce works and iGPU gets disabled. What to do next to get this "compaq_pro_6300_sff" variant officially supported? *Supply more logs/info? *Fill a bug for the ECC not working or first get this variant supported as is? *Fill a bug that VGA doesn't work in SeaBIOS? *Fill a bug/ticket on the flashrom support list for the difference in parameters needed pre/post flash? https://support.hp.com/us-en/drivers/hp-compaq-pro-6300-small-form-factor-p… https://support.hp.com/in-en/drivers/hp-compaq-elite-8300-small-form-factor… Walter Sonius ---Files-------------------------------- cb-log-hp-compaq_pro_6300_sff.txt (51.8 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 34

[coreboot - Feature #583] (New) Allow reconfiguring PCIe slots on Asus P8Z77-V
by Keith Hui 21 Apr '25

21 Apr '25

Issue #583 has been reported by Keith Hui. ---------------------------------------- Feature #583: Allow reconfiguring PCIe slots on Asus P8Z77-V https://ticket.coreboot.org/issues/583 * Author: Keith Hui * Status: New * Priority: Normal * Assignee: Keith Hui * Category: board support * Target version: none * Start date: 2024-11-30 * Related links: https://review.coreboot.org/c/coreboot/+/85413 * Affected hardware: mb/asus/p8z77-v ---------------------------------------- Vendor firmware allows configuring the PCIe slots in three different ways, by reallocating 4 of the PCIe lanes between PCIEX16_3, PCIEX1_1, PCIEX1_2, and the onboard ASM1061 serial ATA controller providing 2 additional SATA ports. The options are (devices not shown are disabled): * X4: PCIEX16_3 as x4 * X1: PCIEX16_3 as x1, PCIEX1_1, PCIEX1_2 * Auto: PCIEX16_3 as x1, PCIEX1_1, ASM1061 The technical details have been worked out and implemented as patch CB:85413. However, two issues remain: 1. Despite our best efforts, PCIEX1_2 still doesn't work. 2. Configuring PCIEX16_3 for 4x requires changing a PCH soft strap from firmware, and coreboot lacks infrastructure for doing so. It has been established that the descriptor itself, which contains the soft straps, needs to be reflashed to make this change. This issue tracks our progress implementing this feature. -- 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 15

Toolchain tarballs missing
by Tim Crawford 21 Apr '25

21 Apr '25

It is currently not possible to build the coreboot toolchain due to NASM. The project website (https://nasm.us), which is used to download the source tarball, has been offline for days. While being hosted on GitHub for years now, the project does not use it for creating and distributing releases. coreboot does have mirrors of tarballs (https://www.coreboot.org/releases/crossgcc-sources/), but the version of NASM used is not present. - How are the tarballs uploaded to the coreboot mirror in the first place? - Can someone upload the missing tarball(s) to the mirror? -- Tim Crawford System76 Kernel Engineer tcrawford(a)system76.com

2 1

2025_04_23 coreboot Review Session
by mina＠coreboot.org 21 Apr '25

21 Apr '25

Hello coreboot, Pleased to announce that our upcoming group review session is scheduled for Wednesday, April 23. 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…) 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 is greatly appreciated. Thank you. Best regards, Mina.

1 0

potential targets,
by zap 19 Apr '25

19 Apr '25

would it be possible to pay for a service to port x1 carbon gen 6 to coreboot? or thinkpad x280 or both? I am aware deguard can be used for this purpose, because of an intel me vulnerability. Is there a price someone would be willing to do this for? Would want boot guard disabled, plus intel me disabled + coreboot. Name the price if you anyone has interest

1 0

2025-04-16 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 17 Apr '25

17 Apr '25

# 2025-04-16 - coreboot Leadership Meeting ## Attendees Felix Singer, Werner Zeh, Julius Werner, Maximilian Brune, Jay Talbott, Alicja Michalska, Matt DeVellier, Mina Asante, Martin Roth, Felix Held, Jon Murphy, Marshall Dawson, Jeremy Compostella, Paul Menzel. ## 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. ## Minutes ### [Martin] Here is a blog post of things we are putting in place to have better engagement with companies: (https://docs.google.com/document/d/1lFUm4A-8F6J0acVbFkE_N_OY6PQcEup0lLPXAe3…) * This collaboration gives room for companies or entities to enjoy the following benefits: * Private development repos * Public branches in the coreboot repo * ongoing or one-off meetings with companies * official company reps for the leadership meetings * blog posts from companies * FelixS: Why would someone need a private repo? * [Alicja] The current coreboot leadership meeting schedule is not favorable for participants in the Asian time zones, and there are companies here that are interested in coreboot. Is it possible to schedule the meeting in a way that makes it possible for everyone to attend? * [Martin] If there's interest in scheduling another meeting, I’m personally fine with it. However, I can’t guarantee that the leadership team will be able to attend. * [Werner] People are always welcome to update the agenda with their issues even if they cant make it to the meeting or reach out directly to any member of the leadership team at any time, and we will be happy to help. * [Felix H] We should put this on the mailing list to see if there’s a demand for a second leadership meeting. ### [Martin] This is a task from a while back to create a questionnaire poll about the concerns surrounding the use of AI tools in open source development [Possible AI poll questions](https://docs.google.com/document/d/1s__V82xvvojpSuI9fEVD3YwND5_H… * Could I get some review? # Next Leadership Meeting * April 30, 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. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

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 15 Apr '25

15 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

git tag 24.12 (would clobber existing tag)
by Paul Menzel 05 Apr '25

05 Apr '25

Dear coreboot folks, Just a quick question, if there the 24.12 tag was renewed back in December(?). $ LANG= git fetch --tags From ssh://review.coreboot.org:29418/coreboot ! [rejected] 24.12 -> 24.12 (would clobber existing tag) I don’t think, I manually added a tag, but I can’t say for certain, what I did several months ago. Kind regards, Paul [1]: https://doc.coreboot.org/releases/coreboot-24.12-relnotes.html

3 4

HP t740
by rherr 04 Apr '25

04 Apr '25

Attn: coreboot Is coreboot compatible with the HP t740 Thin Client? Thanks, Rodger Herrington Blanco, TX, USA

1 0

2025-04-02 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 03 Apr '25

03 Apr '25

# 2025-04-02 - coreboot Leadership Meeting ## Attendees Felix Singer, Jay Talbott, Felix Held, Jon Murphy, Karthik R, Maximilian Brune, Werner Zeh, Matt DeVillier, Martin Roth, Julius Werner, Andre, Mina Asante. ## 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. ## Minutes ### [Martin] What’s going on with the GPL & Cisco * DavidH has been working on this. Still waiting for Cisco - They did a drop a couple years ago, but there are still additional products they haven’t released source code for. * Martin will reach out to David and update the meeting minutes with the current status. * [DavidH] Last I heard, SFC was going to set up a meeting in San Jose between their contact and those of us who are in the area (myself, Stefan, Ron, etc.) and possibly fly one of their attorneys over to attend (depending if lawyers are invited or not). This seems to have stalled again, likely due to the Vizio case consuming a lot of their bandwidth. ### [Martin] Discussion about having meetings between companies and coreboot. * We would like to have some regular meetings with companies or other groups where upcoming plans can be discussed. * [Matt] Put this out on the mailing list * [Max] How often would this be? How will people be made aware? * Monthly at most * At least two of the coreboot leadership would be present or it would have to be rescheduled * The meeting would be put on the coreboot mailing list and calendar. * The meeting could be scheduled by asking on the mailing list or reaching out to the coreboot leadership. # Next Leadership Meeting * April 16, 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. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 31 Mar '25

31 Mar '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, April 2, 2025. [1] Kindly take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. ## Current Agenda Items ### [Martin] What’s going on with the GPL & Cisco? ### [Martin] Discussion about having meetings between companies and coreboot. * We would like to have some regular meetings with companies or other groups where upcoming plans can be discussed. ## Notifications * coreboot 25.03 release is complete. We will do a blog post for it tomorrow. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Support #588] (New) Deguard AssertionError using ./generatedelta.py on Dell Optiplex 5040 SFF (0T7D40) full rom dump
by Walter Sonius 31 Mar '25

31 Mar '25

Issue #588 has been reported by Walter Sonius. ---------------------------------------- Support #588: Deguard AssertionError using ./generatedelta.py on Dell Optiplex 5040 SFF (0T7D40) full rom dump https://ticket.coreboot.org/issues/588 * Author: Walter Sonius * Status: New * Priority: Normal * Category: userspace utilities * Target version: none * Start date: 2025-03-31 ---------------------------------------- Running the deguard `./generatedelta.py` on the flashrom dumped rom from a Dell Optiplex 5040 SFF (0T7D40 A00, Q170 chipset, ME 11.8.92.4222) 1.22 BIOS results in the following AssertionError: ``` ./generatedelta.py --input dell_optiplex_5040_sff_bios122.rom --output data/delta/dell5040sff Traceback (most recent call last): File "/home/neon/deguard/./generatedelta.py", line 55, in <module> mfs = MFS(me.entry_data("MFS")) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 43, in __init__ page = MFSPage(self.data[page * self.PAGE_SIZE:(page + 1) * self.PAGE_SIZE], page) # Load page ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 164, in __init__ self.chunks[chunk] = MFSChunk(data, chunk_id) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 273, in __init__ assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError ``` This "AssertionError" can be skipped by using "Filip Lewiński" [filipleple patch](https://codeberg.org/libreboot/deguard/issues/1) on `lib/mfs.py`: ``` - assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) + print(f"Chunk ID: {self.chunk_id}, Data: {self.data.hex()[:100]}, Expected CRC: {self.crc}, Calculated CRC: {MFS.Crc16(self.data + struct.pack('<H', self.chunk_id))}") + # assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) + if (self.crc != MFS.Crc16(self.data + struct.pack("<H", self.chunk_id))): + print ("Invalid CRC!!!\n") ``` It now lists the following 52 CRC invalid errors, but will create a delta folder structure like the example optiplex 3050 although it misses the `ptt` folder and some other files differ: ``` ./generatedelta.py --input dell_optiplex_5040_sff_bios122.rom --output data/delta/dell5040sff | grep "CRC: 0," Chunk ID: 9662, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 40051 Chunk ID: 9668, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 31713 Chunk ID: 9669, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 18640 Chunk ID: 8173, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 20614 Chunk ID: 8174, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 1493 Chunk ID: 8175, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 14052 Chunk ID: 8176, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 9641 Chunk ID: 8177, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 5784 Chunk ID: 8178, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 17355 Chunk ID: 8179, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 28922 Chunk ID: 8180, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 59757 Chunk ID: 8181, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 55900 Chunk ID: 8182, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 36623 Chunk ID: 8183, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 48190 Chunk ID: 8184, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 44032 Chunk ID: 8185, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 40753 Chunk ID: 8186, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 51810 Chunk ID: 8187, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 63827 Chunk ID: 8188, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 24772 Chunk ID: 8189, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 21493 Chunk ID: 8190, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 1702 Chunk ID: 8191, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 13719 Chunk ID: 8192, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 61908 Chunk ID: 8193, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 49893 Chunk ID: 8194, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 38838 Chunk ID: 8195, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 42119 Chunk ID: 8196, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 15632 Chunk ID: 8197, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3617 Chunk ID: 8198, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 23410 Chunk ID: 8199, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 26691 Chunk ID: 8200, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 30845 Chunk ID: 8201, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 19276 Chunk ID: 8202, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 7711 Chunk ID: 8203, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 11566 Chunk ID: 8204, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 46265 Chunk ID: 8205, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 34696 Chunk ID: 8206, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 53979 Chunk ID: 8207, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 57834 Chunk ID: 8208, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 62119 Chunk ID: 8209, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 49558 Chunk ID: 8210, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 38085 Chunk ID: 8211, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 42996 Chunk ID: 8212, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 15971 Chunk ID: 8213, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3410 Chunk ID: 8214, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 22529 Chunk ID: 8215, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 27440 Chunk ID: 8216, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 31502 Chunk ID: 10199, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3459 Chunk ID: 6000, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 48953 Chunk ID: 6001, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 35848 Chunk ID: 6002, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 55643 Chunk ID: 6003, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 60010 ``` A tree view of the new delta folder: ``` data/delta/dell5040sff/ └── home ├── amt │ ├── rtfd │ │ ├── acl │ │ │ ├── tnf0 │ │ │ ├── tnf1 │ │ │ └── tnf2 │ │ ├── amt.wol │ │ ├── hshStr.crt19 │ │ ├── hshStr.crt23 │ │ ├── hshStr.crt24 │ │ ├── hshStr.crt25 │ │ └── hshStr.crt26 │ └── skip_rtfd │ └── uim.policy ├── bup │ ├── bup_sku │ │ ├── emu_fuse_map │ │ ├── fuse_ip_base │ │ └── plat_n_sku │ ├── invokemebx │ └── mbp ├── fwupdate │ ├── fwuavgerase │ ├── fwuavgwrite │ └── fwuoemid ├── gpio │ └── csme_pins ├── icc │ ├── dynregs │ ├── header │ ├── namestr │ ├── prof0 │ ├── prof1 │ ├── prof2 │ ├── prof3 │ ├── prof4 │ ├── prof5 │ └── prof6 ├── mca │ ├── eom │ └── ish_policy ├── mctp │ └── device_ports ├── pavp │ ├── hdcp_ports │ └── lspcon_port ├── policy │ ├── Bist │ │ └── auto_config │ ├── cfgmgr │ │ └── cfg_rules │ ├── hci │ │ ├── sysintid1 │ │ ├── sysintid2 │ │ └── sysintid3 │ └── pwdmgr │ └── segreto └── secureboot ├── bootpolres ├── bootpoltype ├── enfpolicy ├── kmid └── pubkeyhash ``` Diffing this compared to the example delta 3050 folder: ``` diff -bur optiplex_3050 optiplex_5040_sff_strip Binary files optiplex_3050/home/bup/bup_sku/emu_fuse_map and optiplex_5040_sff_strip/home/bup/bup_sku/emu_fuse_map differ Binary files optiplex_3050/home/bup/bup_sku/plat_n_sku and optiplex_5040_sff_strip/home/bup/bup_sku/plat_n_sku differ Only in optiplex_5040_sff_strip/home/bup: invokemebx Binary files optiplex_3050/home/bup/mbp and optiplex_5040_sff_strip/home/bup/mbp differ Binary files optiplex_3050/home/icc/dynregs and optiplex_5040_sff_strip/home/icc/dynregs differ Binary files optiplex_3050/home/icc/prof0 and optiplex_5040_sff_strip/home/icc/prof0 differ Only in optiplex_3050/home/icc: prof10 Only in optiplex_3050/home/icc: prof7 Only in optiplex_3050/home/icc: prof8 Only in optiplex_3050/home/icc: prof9 Only in optiplex_5040_sff_strip/home/policy: Bist Binary files optiplex_3050/home/policy/cfgmgr/cfg_rules and optiplex_5040_sff_strip/home/policy/cfgmgr/cfg_rules differ diff -bur optiplex_3050/home/policy/hci/sysintid1 optiplex_5040_sff_strip/home/policy/hci/sysintid1 --- optiplex_3050/home/policy/hci/sysintid1 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid1 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -�n$� \ No newline at end of file +_�� \ No newline at end of file diff -bur optiplex_3050/home/policy/hci/sysintid2 optiplex_5040_sff_strip/home/policy/hci/sysintid2 --- optiplex_3050/home/policy/hci/sysintid2 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid2 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -��t` \ No newline at end of file +�� \ No newline at end of file diff -bur optiplex_3050/home/policy/hci/sysintid3 optiplex_5040_sff_strip/home/policy/hci/sysintid3 --- optiplex_3050/home/policy/hci/sysintid3 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid3 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -Ȯ� \ No newline at end of file +�a< \ No newline at end of file diff -bur optiplex_3050/home/policy/pwdmgr/segreto optiplex_5040_sff_strip/home/policy/pwdmgr/segreto --- optiplex_3050/home/policy/pwdmgr/segreto 2025-03-31 15:36:47.221784637 +0200 +++ optiplex_5040_sff_strip/home/policy/pwdmgr/segreto 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -��к \ No newline at end of file +�"�H \ No newline at end of file ``` After deleting (strip) the `secureboot` and `amt,fwupd,pavp` folders it will generate a 2M consumer ME image when using `finalimage.py`. `./finalimage.py --delta data/delta/dell5040sff --version 11.6.0.1126 -pch H --sku 2M --fake-fpfs data/fpfs/zero --input external/asrock_h110_me_11.6.0.1126.bin --output 5040sff_patched_me.bin` When enabling the HAP bit on the original IFD and replacing the ME with the downgraded and deguarded ME should complete the manual. Is it correct to replace the current corporate ME firmware around ~7MB from the original image with this 2MB donor consumer variant, will it be similar like the Optiplex 3050 from the example or should I find a older vulnerable corporate ME firmware? Which file(s) of this dump may I distribute / upload to this ticket license wise to improve debugging? Using the service mode jumper on this Dell Optiplex 5040 SFF I was able to fully read and write the whole firmware even the ME regions (checksum checked it). Anyone else experience or success using a 'ch341a_spi' or 'raspberry spi' doing in-situ flash recover on this particular Dell or similar in case I need it? https://www.dell.com/support/product-details/en-uk/product/optiplex-5040-sf… -- 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

Q on flashing IFD from within coreboot (IVB boards)
by Keith Hui 30 Mar '25

30 Mar '25

I have narrowed the IFD update logic to one UEFI module within vendor BIOS: PcieLaneDxe, and after running Ghidra on it, I have learned enough to start implementing it on coreboot. All is in pursuit of this: https://review.coreboot.org/c/coreboot/+/85413 It will also help with the recently upstream p8z77-v_le_plus, and Sabertooth Z77. Turns out vendor is also just reflashing the IFD after configuring some GPIOs on the board. They don't seem concerned about SPI controller freezing. My code is going to look like this: 8<------ static enum cb_err reprogram_ifd(u8 new_pciepcs1) { const unsigned int PCHSTRP9 = 0x124; u16 lvscc = RCBA16(0x38c4); const unsigned int lbes_map[] = { 256, 4 * KiB, 8 * KiB, 64 * KiB }; u8 * ifdbuf; u8 erase_opcode = (lvscc >> 8) & 0xff; unsigned int erase_size = lbes_map[lvscc & 0b11]; unsigned int i; ifdbuf = malloc(erase_size); /* Read */ memcpy(ifdbuf, (void *) 0xff800000, erase_size); /* Patch */ ifdbuf[PCHSTRP9] &= 0b11111100; ifdbuf[PCHSTRP9] |= (pciepcs1 & 0b11); /* Erase */ /* Write */ for (i = 0; i < erase_size; i+=64) { if (is_write_needed (ifdbuf+i, 64) { /* Write all 64 bytes if anything within isn't 0xff */ } } free(ifdbuf); return CB_SUCCESS; } 8<------ Q1: So far all boards in the Asus p8x7x-series family that need this use 8MiB SPI flash, so they're mapped to 0xff800000 when run as 32-bit. What is the right address to use when coreboot is compiled as 64-bit? Would I have to do "max int - 8 MiB"? Q2: I may have asked this before. Can I use SPI_FLASH Kconfig and the SPI flash driver? Can I use this without a FMD file? Or am I better off rolling my own again? Thanks Keith

1 0

[coreboot - Support #585] (New) acpi MSDM / SLIC table usage?
by Walter Sonius 29 Mar '25

29 Mar '25

Issue #585 has been reported by Walter Sonius. ---------------------------------------- Support #585: acpi MSDM / SLIC table usage? https://ticket.coreboot.org/issues/585 * Author: Walter Sonius * Status: New * Priority: Normal * Category: Documentation * Target version: none * Start date: 2025-03-20 * Affected OS: Windows 8 Pro / Windows 10 Pro ---------------------------------------- What option(s) does one need to compile this feature into a coreboot & edk2 build and where does one put the `slic_file` and in what format? Couldn't find anything in the documentation nor the commits that introduce MSDM/SLIC support: https://review.coreboot.org/c/coreboot/+/44995 https://review.coreboot.org/c/coreboot/+/7202 -- 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 8

[coreboot - Bug #569] (New) coreinfo: i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar'
by Matthias Brugger 28 Mar '25

28 Mar '25

Issue #569 has been reported by Matthias Brugger. ---------------------------------------- Bug #569: coreinfo: i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar' https://ticket.coreboot.org/issues/569 * Author: Matthias Brugger * Status: New * Priority: Normal * Target version: none * Start date: 2024-11-14 * Affected versions: master * Related links: https://doc.coreboot.org/tutorial/part1.html ---------------------------------------- Hi, when trying to compile the qemu example with latest branch, I get the following error: ``` ~/src/coreboot/$ make -C payloads/coreinfo/ Makefile:358: warning: overriding recipe for target '/home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' Makefile:358: warning: ignoring old recipe for target '/home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' AR /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpci.a /home/mbrugger/src/coreboot/payloads/libpayload/../../util/crossgcc/xgcc/bin/i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar' make[1]: *** [Makefile.mk:116: /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpci.a] Error 1 make: *** [../libpayload/Makefile.payload:153: /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpayload.a] Error 2 ``` I double checked and ./util/crossgcc/xgcc/bin/i386-elf-ar exists. I suppose it's a problem in the cross compilation of i386-elf-gcc-ar -- 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 3

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 28 Mar '25

28 Mar '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 2, 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 #507] (Closed) Windows GPU driver fails to load on AMD based google/guybrush, google/skyrim boards
by Matt DeVillier 27 Mar '25

27 Mar '25

Issue #507 has been updated by Matt DeVillier. Status changed from New to Closed This isn't an issue when not using vboot/PSP verstage, so closing for now. ---------------------------------------- Bug #507: Windows GPU driver fails to load on AMD based google/guybrush, google/skyrim boards https://ticket.coreboot.org/issues/507#change-2049 * Author: Matt DeVillier * Status: Closed * Priority: Normal * Target version: none * Start date: 2023-08-30 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, 4.21, main * Affected hardware: google/guybrush, google/skyrim ---------------------------------------- The Windows GPU drivers on AMD Cezanne and Mendocino platform ChromeOS devices (google guybrush and skyrim boards respectively) fail to load due to the PSP boot mode being `Development` vs `Production.` On these platforms, the PSP only boots in `Production` mode when ChromeOS verified boot mode is active. Possible solutions include having the PSP boot in `Production` mode when vboot is not used at all, when CONFIG_CHROMEOS is not set, or (always) when PSP signed verstage is used. Any of these require changes to the PSP firmware from AMD. -- 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

Re: [coreboot - Bug #582] (Closed) failure to boot after using haswell nri
by p db 26 Mar '25

26 Mar '25

> Problems are not ours, Problems are about corporations that in the year > 1991, decided do not give support to the operating system: "Gnu/linux"; > > When things were more easy to solve for Software and for Hardware, to the > same time, corporations REFUSED to develop "Free Hardware" and REFUSED to > put BLACK on WHITE and To SAY what type of COMPONENTS were used to develop > the motherboards. > > Informatics means: "Automatic Information"; it does not mean to give > support ONLY to the NON free software operating systems of corporations! > > Hardware MUST BE 100% Free! Why users must become crazy to have support > for Hardware and for Software? > > Awaiting a reply, > > Best Regards, > > Paolo Del Bene [PdB71] >

1 0

[coreboot - Bug #582] (New) failure to boot after using haswell nri
by Ron Dillenger 24 Mar '25

24 Mar '25

Issue #582 has been reported by Ron Dillenger. ---------------------------------------- Bug #582: failure to boot after using haswell nri https://ticket.coreboot.org/issues/582 * Author: Ron Dillenger * Status: New * Priority: Normal * Assignee: Angel Pons * Category: coreboot common code * Target version: master * Start date: 2025-03-15 * Affected hardware: Z97E-ITX a/c ---------------------------------------- Good day, I am experiencing a rather strange issue with my system after trying out the recently merged Haswell NRI. It was working great, booted fine and ran memtest86+ for the whole day, 10 passes with 0 errors. I then turned off the system for the night by just holding the power button down. The next morning, the system would not boot at all. No display output. Ever since then I haven't been able to get it to boot at all. One thing I have noticed is that the system will restart after about 15 seconds if there is an SPI flash chip present. If there is no present SPI chip this doesn't happen. So I assume the PCH is reading it or at least trying to. Worth noting is it only restarts one time, then it will just remain powered on forever until I turn it off. The restarting also doesn't seem to be consistent, it seems to only happen if I flip the switch on the power supply on and off. If I don't do this it will just remain powered on forever. My hardware: Z97E-ITX a/c 16GB TridentX 2400mhz DDR3 i7 4790S Things I have done: - Reflashed the original stock firmware - Tried a different known working kit of RAM - Removed everything from the system that is nonessential to boot (disk, keyboard, USB drives, etc.) - Removed the CMOS battery - Tried a different known working PSU - Tried different SPI flash chips with coreboot on them - Tried the original SPI flash chip with coreboot on it - Tried coreboot with flashconsole enabled, nothing is written to it At this point I suspect the problem is either with the motherboard, CPU or SPI flash chip. They are the only things I haven't swapped out. One reason I suspect the SPI flash chip is because I wrote to it a lot of times in my initial attempts to get coreboot working on this board. So, maybe that caused excessive wear, I'm not sure. The other reason is because one of the last flashes I did was with the internal motherboard programmer, which worked fine. At the time of the flash I was running the board with all the flash descriptor binaries and an external microcode binary included for my CPU since building it from tree was failing. The image that I flashed with the internal programmer was the same image with me_cleaner run on it. The system booted fine, I confirmed me_cleaner worked but then I tried to do another flash to include memtest86+ as a second payload and flashrom gave some errors about not being able to erase, telling me the flash chip ended up being unchanged. I then flashed the image using an external programmer (raspberry PI with a breadboard) and that worked fine. This makes me somewhat doubt it's the SPI flash chip, flashrom successfully verifies the flash with no errors, and I can read it back fine too and it's the same as what I flashed. I tried other flash chips but my understanding is they aren't all command-compatible so that could be why they didn't work. Unfortunately I haven't been able to try the stock bios on another flash chip because I don't have any motherboards that have chips of the same size. I know this could maybe be a hardware failure unrelated to coreboot or haswell NRI but I figured I would submit this with the hope that the developer or someone else here might have some better ideas about what is going on. -- 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 #586] (Response Needed) autoport should sanitize at least its ACPI DSDT SLIC/MSDM key dumps?
by Walter Sonius 24 Mar '25

24 Mar '25

Issue #586 has been reported by Walter Sonius. ---------------------------------------- Bug #586: autoport should sanitize at least its ACPI DSDT SLIC/MSDM key dumps? https://ticket.coreboot.org/issues/586 * Author: Walter Sonius * Status: Response Needed * Priority: Urgent * Start date: 2025-03-23 ---------------------------------------- Some might even want other info like MAC addresses or serial numbers to be cleared from the autoport dumps, but could at least these SLIC/MSDM activation keys be wiped by default when doing a log dump? -- 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

2025_03_26 coreboot Group Review Session
by mina＠coreboot.org 24 Mar '25

24 Mar '25

Hello coreboot! This is a reminder that our upcoming group review session is scheduled for Wednesday, March 26. 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…) Kindly add any specific patches you'd like the group to review to the top of the sheet. As one 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

Fwd: Linux: [GIT PULL] Please pull fwctl subsystem changes
by Paul Menzel 24 Mar '25

24 Mar '25

Dear coreboot folks, Is Nvidia’s Jason Gunthorpe pull request *Please pull fwctl subsystem changes* [1] interesting for the coreboot ecosystem (including payoads), and if so, does it meet the requirements? > To refresh what it is about please refer to the cover letter and LWN coverage: > > https://lore.kernel.org/all/0-v5-642aa0c94070+4447f-fwctl_jgg@nvidia.com/ > https://lwn.net/Articles/990802/ Kind regards, Paul [1]: https://lore.kernel.org/lkml/Z+F2tcBM1LJpTDF9@nvidia.com/

1 0

coreboot 25.03 Release Tag Scheduled For 27_03 _2025
by mina＠coreboot.org 23 Mar '25

23 Mar '25

Hello everyone, This is a reminder that the coreboot release version 25.03 is scheduled to be tagged on Thursday, March 27th. Please let us know if there are any patches that should be included in the release. You can do that by adding the hashtag "coreboot_release_25.03" to the related patch on Gerrit. The hashtag field is shown after clicking on the "show all" button from the top left information block of a patch. We are using the hashtag "post_coreboot_release_25.03" to track patches that are important or useful and possibly even ready to be submitted but might break something and cause issues, so we prefer to submit them after the release. This gives enough time for testing until the next release. As usual, we have a 1 week delay after the new version is tagged before the announcement to allow for testing of the release. This gives us a chance to fix any issues that are found before making the release public. The 25.03 public announcement is scheduled for April 3rd. If you have any questions or concerns, please let the coreboot release team know or reply to this email. Thank you. Best regards, Mina.

1 0

[coreboot - Support #584] (New) [x200] DDR3 SPD value are read but memtest doesn't display them
by David Duchesne 21 Mar '25

21 Mar '25

Issue #584 has been reported by David Duchesne. ---------------------------------------- Support #584: [x200] DDR3 SPD value are read but memtest doesn't display them https://ticket.coreboot.org/issues/584 * Author: David Duchesne * Status: New * Priority: Normal * Target version: none * Start date: 2025-03-19 ---------------------------------------- Hello, Before opening an issue on memtest issue tracker, I would like to know if the DDR3 SPD reading is correct because with memtest 7.20 (64bit build), the main screen is fully empty, instead of showing: ``` Memory SPD Information ---- - Slot 0 : RAM SIZE / SPEED / PART NUMBER - Slot 1 : RAM SIZE / SPEED / PART NUMBER ``` Also, no mention of the RAM CAS just above. It is empty. Otherwise the test is running correctly. I'm having the same issue with a t400, r400 & t500 and memtest 7.20 (and earlier) All my lenovo are running coreboot 24.12 and have **CONFIG_DUMP_SMBIOS_TYPE17=y** Otherwise dmidecode have no issue reporting those values, see below. Any advice appreciated. Thanks. ``` $ dmidecode -t 17 # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4 GB Form Factor: SODIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Unknown Synchronous Speed: 1067 MT/s Manufacturer: Samsung Serial Number: 4608a20b Asset Tag: Channel-0-DIMM-0-AssetTag Part Number: M471B5273CH0-CF8 Rank: 2 Configured Memory Speed: 1067 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x000B, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4 GB Form Factor: SODIMM Set: None Locator: Channel-1-DIMM-0 Bank Locator: BANK 1 Type: DDR3 Type Detail: Unknown Synchronous Speed: 1067 MT/s Manufacturer: Samsung Serial Number: 4608a20b Asset Tag: Channel-1-DIMM-0-AssetTag Part Number: M471B5273CH0-CF8 Rank: 2 Configured Memory Speed: 1067 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown ``` -- 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

2025-03-19 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 18 Mar '25

18 Mar '25

Dear coreboot Community, Please note that our leadership meeting scheduled for tomorrow, March 19 has been canceled, as the issue on the agenda has already been resolved. Thank you. Best regards, Mina.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 17 Mar '25

17 Mar '25

Dear coreboot Community, Our upcoming leadership meeting is scheduled for Wednesday, March 19, 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 25.03 release schedule
by coreboot org 13 Mar '25

13 Mar '25

Hi everyone, This is the notification that we're two weeks away from the coreboot 25.03 release tag, scheduled for Thursday, March 27th. Please mark patches you want to be merged before the release with the hashtag “coreboot_release_25.03”. There's no promise that these will get merged, but we will try to get everything on the list in. Mark any patches that need to be merged *after* the release with the hashtag "post_coreboot_release_25.03" As usual, we have a 1 week delay after the new version is tagged before the announcement to allow for testing of the release. This gives us a chance to fix any issues that are found before making the release public. The 25.03 public announcement is scheduled for April 3rd. If you have any questions or concerns, please let the coreboot release team know or reply to this email. Thanks, Martin

1 0

[coreboot - Feature #461] Replacing Haswell mrc.bin blob with free software
by gaspar ilom 12 Mar '25

12 Mar '25

Issue #461 has been updated by gaspar ilom. The patch train got merged: https://review.coreboot.org/c/coreboot/+/81897/4 Anyway, in heads we have made an effort to use NRI on the W541 and T440p boards. However boot times are between 10 and 20s. So it seems like the mrc cache is not properly build and reused. Also, on the W541 S3 resume does not work (just reboots the machine). I can offer testing and helping debugging this feature: https://github.com/linuxboot/heads/pull/1923 ---------------------------------------- Feature #461: Replacing Haswell mrc.bin blob with free software https://ticket.coreboot.org/issues/461#change-1999 * Author: akjuxr3 akjuxr3 * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: chipset configuration * Target version: none * Start date: 2020-04-01 * Related links: https://review.coreboot.org/q/topic:haswell-nri * Affected hardware: All Haswell mainboards ---------------------------------------- Currently in case of the ability to run as less amount of closed source software as possible and still have Microcode updates the reduced Intel ME with disabled bit in IFD and the lga1155 or the mobile versions of those cpus are the only option for x86_64 out there. The next cpu generation (Haswell) inside for example T440p and W541 require the binary blob mrc.bin Are there any plans of replacing the Haswell mrc.bin with free software? Or have the x86_64 platform be given up when the goal is to run just free software and the people should move to aarch64 or risc-v? -- 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_03_12 coreboot Group Review Sesssion
by mina＠coreboot.org 10 Mar '25

10 Mar '25

Hello coreboot! Please note that we have an upcoming group review session scheduled for Wednesday, March 12. https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

[coreboot - Bug #580] (New) smbios table only recorded data for one slot
by Keith Hui 09 Mar '25

09 Mar '25

Issue #580 has been reported by Keith Hui. ---------------------------------------- Bug #580: smbios table only recorded data for one slot https://ticket.coreboot.org/issues/580 * Author: Keith Hui * Status: New * Priority: Normal * Category: coreboot common code * Start date: 2025-03-09 * Affected hardware: asus/p8z77-v_le_plus ---------------------------------------- I entered smbios slot description for 5 slots in devicetree (via an overridetree.cb), but after booting only the last slot is recorded in the data table. overridetree.cb ``` device domain 0 on subsystemid 0x1043 0x84ca inherit device ref peg11 on # PCIEX_16_2 smbios_slot_desc "SlotTypePciExpressGen3X8" "SlotLengthLong" "PCIEX16_2" "SlotDataBusWidth8X" end chip southbridge/intel/bd82x6x register "usb_port_config" = "{ /* not relevant */ }" register "gen1_dec" = "0x000c0291" # NCT6779 HWM register "gen4_dec" = "0x0000ff29" # Could be for KB3722 EC device ref pcie_rp1 on # PCIEX_16_3 (electrical x2 or x4) smbios_slot_desc "SlotTypePciExpressGen2X4" "SlotLengthLong" "PCIEX16_3" "SlotDataBusWidth4X" end device ref pcie_rp3 on smbios_slot_desc "SlotTypePciExpressGen2X1" "SlotLengthShort" "PCIEX1_1" "SlotDataBusWidth1X" end device ref pcie_rp4 on smbios_slot_desc "SlotTypePciExpressGen2X1" "SlotLengthShort" "PCIEX1_2" "SlotDataBusWidth1X" end device ref pcie_rp5 on # RTL8111F LAN chip drivers/net register "customized_leds" = "0x482" device pci 00.0 on subsystemid 0x1043 0x8505 end end end device ref pcie_rp6 on # ASM1083 PCI bridge subsystemid 0x1043 0x8489 smbios_slot_desc "SlotTypePci" "SlotLengthLong" "PCI1" "SlotDataBusWidth32Bit" end device ref pcie_rp7 on # Marvell 88SE9120 ESATA6G subsystemid 0x1043 0x83ba end device ref pcie_rp8 on # ASM1042 USB3 subsystemid 0x1043 0x8488 end device ref hda on subsystemid 0x1043 0x841a end device ref lpc on chip superio/nuvoton/nct6779d device pnp 2e.1 off end # Parallel device pnp 2e.2 on # UART A io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 off end # UART B, IR device pnp 2e.5 on # PS2 KBC io 0x60 = 0x0060 # KBC1 base io 0x62 = 0x0064 # KBC2 base irq 0x70 = 1 # Keyboard IRQ irq 0x72 = 12 # Mouse IRQ # KBC 12Mhz/A20 speed/sw KBRST drq 0xf0 = 0x82 end device pnp 2e.6 off end # CIR device pnp 2e.7 off end # GPIOs 6-8 device pnp 2e.8 off end # WDT1 GPIO 0-1 device pnp 2e.108 on end # GPIO0 device pnp 2e.109 on end # GPIO1 device pnp 2e.509 on end # GPIO5 all in device pnp 2e.a on # ACPI drq 0xe7 = 0x11 drq 0xf2 = 0x5d # Enable PME end device pnp 2e.b on # H/W Monitor, FP LED io 0x60 = 0x290 io 0x62 = 0 irq 0x70 = 0 drq 0xe4 = 0xf9 # Use GP50/52/55 end device pnp 2e.d off end # WDT1 device pnp 2e.e off end # CIR wake-up device pnp 2e.f off end device pnp 2e.14 on end # Port 80 UART device pnp 2e.16 off end # Deep sleep end end end end ``` Output of dmidecode -t9 ``` # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.0.0 present. Handle 0x0015, DMI type 9, 19 bytes System Slot Information Designation: PCI1 Type: PCI Data Bus Width: 32 bit Current Usage: In Use Length: Long ID: 0 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Bus Address: 0000:00:1c.4 Data Bus Width (Base): 1 Peer Devices: 0 ``` I expect to see all 5 slots returned. -- 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

[announce] flashprog v1.4 is out!
by Nico Huber 09 Mar '25

09 Mar '25

Hi, I'm glad to announce the release of flashprog v1.4. This time we've mostly updated the flash chip database, added 90 new entries and polished many existing ones. You can read more about it in the full release notes[1]. As usual, you can download the source via Git[2] (tag `v1.4`) or as tarball[3]. Cheers, Nico [1] https://flashprog.org/wiki/Flashprog/v1.4 [2] https://github.com/SourceArcade/flashprog [3] https://flashprog.org/releases/flashprog-v1.4.tar.bz2

1 0

2025-03-05 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 06 Mar '25

06 Mar '25

# 2025-03-05 - coreboot Leadership Meeting ## Attendees Mina Asante, Jon Murphy, Felix Singer, Benjamin Doron, Felix Held, Andre, Andy Ebrahiem, Jeremy Compostella, Martin Roth, Matt DeVillier, David Hendricks, Jay Talbott, Julius Werner, Karthik R. ## 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. ## Minutes ### [Benjamin] Add support for sharing SMM with the payload * To support UEFI secure boot effectively, we need to perform the verify and write steps of its variables together, in SMM. Consequently, we propose a solution where coreboot ‘owns’ SMM (initialises and installs all its regular SMI handlers), and the payload is permitted to install its own SMI handlers within a dedicated SMRAM region that coreboot will call into (and return from) for payload-specific use-cases. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific, and contains nothing specific to secure boot. This is a superior solution to one we proposed in 2023, called “[Add support for calling SMM payloads.](https://docs.google.com/document/d/1S1hLGc7nhBIaD3wN3eylyjhMMqEo… * Earlier proposal handed SMM control to the payload, which caused issues since some things like suspend/resume and EC functionality needed to be provided in SMM controlled by coreboot. * This new approach allows EDK2 to read, verify, and potentially write secure boot related variables in an "atomic" manner (using coreboot's SPI driver on the backend?). This solves a problem from the earlier solution where secure boot variables could be changed by an attacker in between EDK2 and coreboot interactions. * [A.I] Benjamin to publish a[ blog post at the 9E blog](https://9elements.com/blog/) about this so that we can review the design in more detail. (DFAD/ETA: unknown, probably after university exams) ### [Martin] Updating website * Privacy Policy * Leadership page * Trademark & logo ### [Martin] Email server * As we agreed previously, the email service remained on Stefan’s server. This includes the mailing list * Stefan, Patrick and myself are admins there. ### [Jon] cbmem updates * Google is pursuing testing of coreboot with Android. As such, we do need to make some changes to coreboot mechanisms to facilitate a slightly different OS. Can we get review on some cbmem changes to add support in sysfs: (https://review.coreboot.org/q/topic:%22cb em-in-sysfs%22) ### [Martin] We can post blogs on the coreboot blog if people are interested in writing things. * Don’t want to make it an advertising area, but we’d like news about devices using coreboot. * Martin can write something about opensil with coreboot after the Phoenix & Turin Proof-of-Concept (Non-production) openSIL releases. # Next Leadership Meeting * March 19, 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. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 03 Mar '25

03 Mar '25

Dear coreboot Community, Please note that we have an upcoming leadership meeting scheduled for Wednesday, March 5, 2025. [1] Kindly review the agenda and share your thoughts or suggest additional items you would like to discuss during the meeting. [2] Thank you. ## Current Agenda Items ### [Benjamin] Add support for sharing SMM with the payload * To support UEFI secure boot effectively, we need to perform the verify and write steps of its variables together, in SMM. Consequently, we propose a solution where coreboot ‘owns’ SMM (initialises and installs all its regular SMI handlers), and the payload is permitted to install its own SMI handlers within a dedicated SMRAM region that coreboot will call into (and return from) for payload-specific use-cases. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific, and contains nothing specific to secure boot. This is a superior solution to one we proposed in 2023, called “Add support for calling SMM payloads.” [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

(preping to coreboot) laptop X230 stuck on 2.75 - I cannot downgrade to 2.60!
by bruno＠slingshotsecurity.pro 02 Mar '25

02 Mar '25

I think I got myself in trouble stuck on 2.75 - I cannot downgrade to 2.60 (X230) via IVprep or the lenovo tool (I get "This app can't run on your PC"). Is there a way forward, please? Here is what I did and was planning to do (1vyrain, skulls and clean/disable/break the Intel ME): ## 1. EC Patching (accept all batteries and keyboards) https://github.com/hamishcoleman/thinkpad-ec/ It recomends using on the last modifiable version: x230 -BIOS 2.75 (G2ETB5WW) EC 1.14 (G2HT35WW) Therefore I upgraded from my 2.55 to 2.75, by downloading g2uj31us.exe, saving on a usb stick and running on the target machine's windows (the bootable iso would not dd well to the usb stick). https://support.lenovo.com/ec/en/downloads/ds029187 ## 2. Downgrade from 2.75 to 2.60 (X230) (I cannot perform from here onwards): https://github.com/n4ru/IVprep/tree/master Downloaded both IVprep and g2uj17us.exe and saved on the usb stick to run on target machine's windows but then I get I get "This app can't run on your PC". I have tested with both: BIOS Setup -> Security -> UEFI BIOS Update Option. Set Flash BIOS Updating by End-Users to Enabled, and Secure RollBack Prevention to Disabled BIOS Setup -> Security -> UEFI BIOS Update Option. Set Flash BIOS Updating by End-Users to Enabled, and Secure RollBack Prevention to Enabled ## 3. Get rid of the ME https://github.com/corna/me_cleaner I gues for this one, I should boot the target machine with a Live Linux, clone the repo and execute ## 4. Install Skulls via 1vyrain https://github.com/n4ru/1vyrain This would be burn the usb stick to the 1vyrain, use the ethernet cable and the skulls release URL https://github.com/merge/skulls/releases ## This question has been also posted on: - https://github.com/n4ru/1vyrain/issues/144- https://forum.qubes-os.org/t/how-to-use-ivprep-and-1vyrain-and-disable-inte… https://github.com/merge/skulls/issues/302 - https://github.com/hamishcoleman/thinkpad-ec/issues/266

1 0

Re: PC with coreboot - boot menu locked
by Paul Menzel 28 Feb '25

28 Feb '25

Dear Andrea, Welcome to coreboot. Please do not send messages over 500 kB (definitely not more than 1 MB) to mailing lists. Am 16.02.25 um 18:30 schrieb Andrea Battelli: > I have an embedded system that I want to reuse but the bios is locked up > and when I press the f12 key, it shows only a boot option (payload). How > can I disassemble the bios or rebuild another one? > > Attached is the dump of the rom and the screenshot of the boot menu It’d be great if you just copied the text output from the payload. SeaBIOS (version SageBIOS-20161017_085144-ttyree-dev-gtk-gtech-com) Select boot device: 1. Payload [igt_secure] Sage Engineering [1] *was* a company offering coreboot development a long time ago. No idea, if they upstreamed this board, or how to get the source code. What board is it exactly? Anyway, your attached dump has a coreboot image (CBFS – coreboot file system), you can dump with `cbfstool`: ``` $ ~/src/coreboot/util/cbfstool/cbfstool bios_igt_orig.bin print FMAP REGION: COREBOOT bios_igt_orig.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xc00000 alignment: 64 bytes, architecture: x86 Name Offset Type Size Comp roothashes 0xc00000 (unknown) 192 none fallback/romstage 0xc00100 stage 60241 none fallback/ramstage 0xc0ecc0 stage 94548 none fallback/payload 0xc25e80 simple elf 49158 none bootsplash.jpg 0xc31ec0 bootsplash 48411 none etc/boot-menu-wait 0xc3dc40 raw 8 none (empty) 0xc3dc80 null 4888 none keyupdate 0xc3efc0 mma 8192 none (empty) 0xc41000 null 3992 none keystore 0xc41fc0 mrc 131072 none img/igt_secure 0xc62000 simple elf 83362 none vgaroms/videobios.rom 0xc76600 optionrom 65536 none (empty) 0xc86640 null 51544 none bootorder 0xc92fc0 raw 4096 none (empty) 0xc94000 null 2604952 none cpu_microcode_blob.bin 0xf0ffc0 microcode 38912 none (empty) 0xf19800 null 157592 none mrc.cache 0xf3ffc0 mrc_cache 65536 none (empty) 0xf50000 null 65432 none fsp.bin 0xf5ffc0 spd 524288 none (empty) 0xfe0000 null 12248 none bootorder_sata 0xfe3000 raw 4096 none bootorder_usb 0xfe4040 raw 4096 none bootorder_sec 0xfe5080 raw 4096 none (empty) 0xfe60c0 null 24 none rootpub 0xfe6100 fsp 2064 none (empty) 0xfe6940 null 103000 none ``` It does not seem to contain the build configuration, but you might be able to boot from a USB device. From there you should be able to read the logs with `cbmem` and find out the coreboot version and board name. Maybe that brings you further. I have never heard of `igt_secure`. As you can access the dump, you can at least build the payload yourself, and replace `fallback/payload` or add it under `img/`. Maybe that works. No idea if the keys/hashes verify anything from this. Anyway, the above should get you going. Kind regards, Paul [1]: https://se-eng.com/ [2]:

3 2

[p8x7x port] Realtek loses its mind & Marvell not going with times.
by Keith Hui 28 Feb '25

28 Feb '25

(Catchy subject eh? There's some truth to both.) My coreboot port to Asus P8Z77-V LE PLUS is almost ready, but I still have two outstanding problems. The board is losing its MAC address, partly because it doesn't have an EEPROM for vital product data. I enabled the rtl8168 driver in coreboot so I can configure the LEDs and MAC address. Lights work great, but the MAC address always revert to 00:00:00:00:00:05 by the time Linux kernel sees it. I would then have to reassign its proper MAC address using "ip link change eno0 address <mac>". I added a debug read back in the rtl81xx driver and the device appears to be taking the MAC I programmed. Board also has a Marvell 88SE9120 for two extra SATA ports. It came up in legacy mode and pata_marvell driver isn't able to operate it. I find no documentation on how to switch to AHCI mode like ASM1061. Needless to say those two ports are currently useless. Ideas? I'm hoping to get this and a few supporting patches in for next release. https://review.coreboot.org/c/coreboot/+/86172 Thanks Keith

1 0

Re: PC with coreboot - boot menu locked
by p db 27 Feb '25

27 Feb '25

This is NOT free hardware, that is, tying people to solutions: "Digital Restricted Management", when people will understand that they will have to start relying on free hardware solutions, as usual, it will always be too late. Best Regards, Paolo Del Bene Il Gio 27 Feb 2025, 19:57 Andrea Battelli <battelli2(a)gmail.com> ha scritto: > Hi, > > I have an embedded system that I want to reuse but the bios is locked up > and when I press the f12 key, it shows only a boot option (payload). How > can I disassemble the bios or rebuild another one? > > Attached is the dump of the rom and the screenshot of the boot menu > > Thanks > Andrea > > PS: I don't how if it helps but the cpu is a Intel Core i3 4010U > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

2025_02_26 coreboot Group Review Sesssion
by mina＠coreboot.org 24 Feb '25

24 Feb '25

Hello coreboot! Our upcoming biweekly group review meeting is scheduled for Wednesday, February 26. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. 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