coreboot March 2025

coreboot@coreboot.org

10 participants
28 discussions

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 24 Mar '25

24 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 - Bug #579] (New) MAC address programmed by coreboot to onboard RTL8111F does not persist
by Keith Hui 22 Mar '25

22 Mar '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 2

[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

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