coreboot

coreboot@coreboot.org

11 participants
39715 discussions

Looking for more pairs of eyes, reviewers, for a Rust port of bios_extract
by Idwer Vollering 13 Jan '25

13 Jan '25

Hi, I'm porting bios_extract to Rust. This is an equally serious endeavour as it is a learning project. The port is halfway finished when it would handle PhoenixBIOS binaries, this is the part where I am stuck and would like to receive review. Award, AMI, binaries should work or mostly work, I could not find enough binaries to test with. What needs to be done, can be fixed later. Running `cargo clippy` is on the (mental) todo list. https://review.coreboot.org/c/bios_extract/+/84226

1 0

2025-01-08 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 09 Jan '25

09 Jan '25

# 2025-01-08 - coreboot Leadership Meeting ## Attendees Mina Asante, Saulo Silva, Felix Singer, Christian Walter, Andre, Maximilian Brune, Jay Talbott, Julius Werner, Matt DeVillier, Werner Zeh, Andy Ebrahiem, David Hendricks, Martin Roth, Alicja Michalska, Jeremy Compostella. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * 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 * 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 * 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) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ## [Sheng/Chris] Promote Liu Shuo to be core developer * He has shown great progress in leading and helping coreboot Xeon patches together with the community * Stats for the past 2 years: Commits: 96 (10th most commits overall) Reviews: 139 Comments: 118 * Worked together with community to upstream GNR patches and cleaned up many Eagle Stream coreboot mess * Able to address most of reviewers feedback and make the code better, understand coreboot practices, and also produces patches with good code quality. * Author of (https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-…) * Will have bigger responsibility to maintain and drive the Xeon coreboot works. * There have been no objections. * Decision: Liu Shuo has been promoted as a core developer. ### [Martin] How do we want to handle platforms that don’t have a public FSP/openSIL or other binaries. * We definitely don’t want to make it mandatory to have the binaries available to have the code in the coreboot repo. * We could make a blog post listing platforms that don’t have a public FSP and request that something be released. ### [Alicja] Plans to have a new mainboard porting guide later this month ### [Alijca] Refactor fallback mechanism to use more modern parts of vboot. * [David] We've had a fallback mechanism since early on, however it may be stale by now e.g. due to usage of CMOS variables and whatnot. A more modern approach that removes any dependency on things like counters maintained in certain types of memory would be nice, similar to vboot itself which was designed to not rely on any specific implementation from silicon vendors. # Next Leadership Meeting * January 22,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

Sane length for the first commit message line in documentation
by Zeh, Werner 09 Jan '25

09 Jan '25

Hi all. Recently it was brought to my attention that there is a dead link [1] in our documentation (commit message guidelines [2]). After having a look and asking around it turned out that it currently points to the old wiki which is finally offline, hence the dead link. I have created a patch to re-write the old content from the wiki in [3]. So far this is more or less a rewrite of what has been there in the old wiki with some additions from me. One review comment is that the mentioned limits for the line length of the first commit message might not be sufficient anymore. There it stated that the first line should be less than 65 characters or absolute maximum 75. Shall we adjust this length now that we are having this commit message guideline available again in our docs? Limiting to a too low number might lead to struggles when writing a meaningful description with the prefixed file path. Having too big numbers here might make it hard to read on consoles and even in Gerrit. Any thoughts on the new limits? Or are the ones mentioned there still fine? Your input is valuable. Thanks Werner [1] https://www.coreboot.org/Git#Commit_messages [2] https://doc.coreboot.org/contributing/gerrit_guidelines.html#recommendations -for-gerrit-activity [3] https://review.coreboot.org/c/coreboot/+/85915

2 2

Q: Can I modify PCH soft straps from bootblock?
by Keith Hui 09 Jan '25

09 Jan '25

All, A use case for the title is beginning to emerge for a number of Asus P8x7x boards. For example: https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 Many standard ATX boards in the family have more peripherals than the 8 PCIe lanes available out of the PCH, so some are structured to share 3 of the 4 PCIe lanes originally earmarked for an x4 slot. They do this with a number of 2-way PCIe switches (specifically ASM1440 - no datasheet, but I figured out the pinout, only thing I don't know is the polarity of the control signal) controlled by GPIOs either on the super I/O or the PCH. With vendor firmware this is an option that can be configured from UEFI setup itself. I can handle GPIOs fine, but stealing lanes from an x4 slot requires changing a soft strap to reconfigure lanes 1-4 from one x4 port to four x1 ports. The only strategy I can see work is flash a modified soft strap to the descriptor, during bootblock before PCI bus scan happens and before SPI is locked down, trigger a full platform reset (eg. outb(0xe, 0xcf9)) , then program the GPIOs to match the updated soft strap. Has this been done before in coreboot so there is code I can lift? Thanks Keith

1 0

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

06 Jan '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, January 8, 2025. [1] Kindly update the agenda with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### [Sheng/Chris] Promote Liu Shuo to be core developer * He has shown great progress in leading and helping coreboot Xeon patches together with the community * Stats for the past 2 years: Commits: 96 (10th most commits overall) Reviews: 139 Comments: 118 * Worked together with community to upstream GNR patches and cleaned up many Eagle Stream coreboot mess * Able to address most of reviewers feedback and make the code better, understand coreboot practices, and also produces patches with good code quality. * Author of (https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-…) * Will have bigger responsibility to maintain and drive the Xeon coreboot works. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

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

03 Jan '25

Dear coreboot Community, We are pleased to announce that we have an upcoming leadership meeting scheduled for January 8, 2025. [1] Please 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

Two devicetree questions and two use cases
by Keith Hui 27 Dec '24

27 Dec '24

My question is pretty much as title. I'll explain my use cases below. 1. https://review.coreboot.org/c/coreboot/+/82633 With this patch, I'm still getting leftover devices messages in the log for devices 0:1.1 and 0:1.2. This is with no card plugged into the PCIe x16 slot. As far as I can tell those devices are for when the Ivy Bridge CPU's PCIe lanes have to run in x8 or x4 mode. I don't know what device 0:4.0 is for. 0:6.0 is for the extra 4 PCIe lanes for Xeon CPUs. None of the Asus P8x7x series boards have them wired up. So is there a way for me to "remove" the latter two devices from chipset.cb with the mainboard devicetree.cb, or do I have to hide them like I did in the patch? How do I completely get rid of leftover devices? 2. https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 These boards, as well as p8z77-m_pro (likely any standard ATX board in this family), have one x16 slot and one x8 slot that are both serviced by the 16 PCIe lanes out of the CPU. The card presence pin on the x8 slot activates a CPU hard strap and enables bifurcation, as well as configures a bunch of PCIe mux/switches to send the bifurcated lanes to the x8 slot. Together they reconfigure the CPU's PCIe lanes into two x8 slots. But wait, there's more. p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the PCH, but the 4 lanes are shared with some other x1 slots and devices. They can configure the PCIe x4 slot to really be x4, or the 4 lanes can be configured as 4 x1 ports for various x1 slots or onboard devices. This requires changing a soft strap as well as manipulating some GPIOs in the SIO chip, and the devicetree changed to match. I have the SIO GPIO part figured out, the soft strap I can only come to one possible explanation: reflash SPI descriptor with the changed soft strap and force a platform reset. To verify I'll need to get a board and actually check the flash chip for changes. But how do I manage the devicetree dynamically? Say for sabertooth I'll want to turn on PCH PCIe root port 1 only if it is set for x4, otherwise I'll need all ports 1-4 on so its three PCIe x1 slots can work along with the x4 slot now being x1 only. Thanks Keith

2 1

Calling all Asus P8x7x board owners, and Q about NCT5535D
by Keith Hui 23 Dec '24

23 Dec '24

Hello, I recently got my hands on boardviews of many Asus P8x7x series mainboards, and some offshoots such as Z77-A and Sabertooth Z77, and have also found a way to extract VBT data and the USB port config out of the vendor firmware image (which isn't really a straight image, but what looks like an update capsule), allowing me to attempt something quite ambitious given I only have the P8Z77-M on hand: Bring coreboot to the entire family. Again because I only have the vendor firmware image and boardview to go by, I will only be able to put out an untested new board patch, hence I am calling for anyone with these boards, that aren't already in the tree, to help me test them, and to get things I can't get out of firmware image, such as HDA verbs and GPIO setup, by running autoport on your board. Additionally, if you have a P8Z77-V (Hello Bill!), please test this patch: https://review.coreboot.org/c/coreboot/+/85413 And if you have a P8Z77-M PRO, please test your serial port, and if changing it to use serial port A like P8Z77-M does, make the serial port work. Now, during my survey of the board family, I found that: 1. They link their power LEDs to only one of two GPIOs on the PCH: 8 or 27. That's easily determined from the boardview. 2. Except for P8C WS which I can't get a boardview for, this family only uses one of two Nuvoton super I/Os: NCT5535D or NCT6779D. 6779 is well known, but I cannot find the datasheet for 5535, and the pinout for the closest thing I can find, NCT5532D, have the pins shifted by approximately 3 pins, and there may be more differences. Does anyone know anything about NCT5535D or can hook me up with a datasheet? Thanks Keith

2 2

2024-12-25 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 23 Dec '24

23 Dec '24

Hello coreboot, Please note that the leadership meeting scheduled for Wednesday, December 25, 2024, has been canceled as it falls on Christmas Day. Thank you for your understanding, and I wish you a joyous and merry Christmas. Best regards, Mina.

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 18 Dec '24

18 Dec '24

Issue #121 has been updated by Anastasios Koutian. Anastasios Koutian wrote in #note-100: > Have been using this change: https://review.coreboot.org/c/coreboot/+/78609 since it was merged (May 23) and haven't seen any freezes. > It's possible that this solves the issue. Can others confirm? Still no freezes since. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1995 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- 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

Jump to page:

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