coreboot January 2025

coreboot@coreboot.org

13 participants
21 discussions

Re: Two devicetree questions and two use cases
by Keith Hui 18 Jan '25

18 Jan '25

Hi Nicholas, Thanks for the reply, and the scoop, and pardon my second email to the list that essentially asked the same question again. The hidden register would be a boon to my goals. I have an Asus P8Z77-V LE Plus board on order that I will soon be able to test the idea on, since it is one of those boards with more devices than PCIe lanes. It is part of my plan to bring coreboot to all the P8x7x boards. Towards that goal there are a few patches I'm looking to get in such as CB:82556,82557,85834, and am still looking for volunteers to boot test my as yet incomplete ports. Cheers Keith > > Hi Keith, > > I can't speak to the devicetree stuff, but I did find something > interesting regarding the PCH PCIe ports: > > > 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. > > Changing the IFD at runtime seems like an impractical way to achieve > this, especially since the IFD is normally supposed to be read only. I > suspect there's another, undocumented method to change the > configuration. On ICH/PCH datasheets, there is an RCBA register (Root > Port Configuration Register) that indicates the current port > configuration. On the 7 series PCH's, that is at RCBA32(0x400), bits 3:2 > for ports 5-8 and bits 1:0 for ports 1:4. However, these bitfields are > documented as read only in the public datasheets. However, in the public > ICH9 datasheet (and seemingly only the ICH9 datasheet; other datasheets > like ICH7, ICH8, ICH10, etc don't have this detail) the equivalent > register at RCBA32(0x224) lists the bitfields as R/W, with a note saying > that writing to them is for debug/testing and should be treated as read > only and modifiable only through hard straps (it seems like ICH9 didn't > use IFD soft straps for this). Based on that note, I assume this > mechanism is intended for testing different PCH PCIe configurations > without reflashing the IFD. I haven't tested this yet on any platform > but it does seem plausible that this mechanism exists on chipsets other > than ICH9. > > Cheers, > Nicholas > > >

2 4

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

17 Jan '25

Dear coreboot Community, We are pleased to announce that we have an upcoming leadership meeting scheduled for January 22, 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

Reviewers for src/soc/intel/
by Compostella, Jeremy 16 Jan '25

16 Jan '25

Hi, I do not know who I should talk to so I am going to leverage the mailing list. I have been wondering: why have I not been looped in the review [85827 soc/intel/pantherlake: Refactor FSP-M params for debug message control]. I looked at the `MAINTAINERS' file and I found the following related definitions. ,---- | INTEL SUPPORT | R: Intel_Coreboot_Reviewers <intel_coreboot_reviewers(a)intel.com> | S: Maintained | F: src/vendorcode/intel/ | F: src/cpu/intel/ | F: src/northbridge/intel/ | F: src/southbridge/intel/ | F: src/soc/intel/ | F: src/drivers/intel/ | F: src/include/cpu/intel/ | [...] | INTEL PANTHERLAKE SOC | M: Subrata Banik <subratabanik(a)google.com> | M: Kapil Porwal <kapilporwal(a)google.com> | M: Pranava Y N <pranavayn(a)google.com> | S: Maintained | F: src/soc/intel/pantherlake/ `---- I am part of the Intel_Coreboot_Reviewers <intel_coreboot_reviewers(a)intel.com> mailing list but I do not see *Intel_Coreboot_Reviewers* added to the CC section in gerrit which probably explain why I did not get any email. Our goal is to have Intel folks of this mailing list as reviewers of all the src/soc/intel/... changes. How can we achieve that ? Regards, -- *Jeremy* /One Emacs to rule them all/ [85827 soc/intel/pantherlake: Refactor FSP-M params for debug message control] <https://review.coreboot.org/c/coreboot/+/85827>

2 7

Review session
by Maximilian Brune 15 Jan '25

15 Jan '25

Hello fellow coreboot engineers, I feel like I need to point out that the attendance of the review session is becoming rather poorly. I think the idea of the review session meeting is very nice, but it doesn't work if no one attends. The current attendance is usually 3 people of which 2 are fairly new in the project (1 year max) and have no +2 rights. That makes the meeting essentially pointless. I myself also don't always join the meeting, but I try to join if I can. I know everyone is doing this on a voluntary basis and even if I want to force you to join I sadly can't, because free will seems to become popular these days. Nevertheless I hope some of you can free up some time (doesn't have to be for the whole meeting) in the future. love you all Max

1 0

2025_01_15 coreboot Group Review Sesssion
by mina＠coreboot.org 14 Jan '25

14 Jan '25

Hello coreboot! We are pleased to announce that our upcoming review session is scheduled for tomorrow, January 15, 2025, at 10:00 AM Pacific Time: https://meet.google.com/kpu-yozw-gtt As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will 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

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

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