coreboot March 2025

coreboot@coreboot.org

10 participants
31 discussions

[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

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 March 2025