coreboot

coreboot@coreboot.org

11 participants
39714 discussions

Help me push coreboot's envelope on Asus P8Z77-V
by Keith Hui 24 Jan '25

24 Jan '25

Hello all, Doing some work with (Bill's) Asus P8Z77-V board and running into some issues and limits. See it unfold at https://review.coreboot.org/c/coreboot/+/85413 That said, I've run into a few issues and limits trying to bring feature parity to it. It will also help me with porting coreboot to two more boards in the family: P8Z77-V LE PLUS and Sabertooth Z77. A patch has been sent for Sabertooth and I have one on the way maybe early next month - it needs a cap replaced, maybe more. The other board is on hand and a patch is being prepared. I'll put in as much as I can get working before sending it in. #1. Bill has been testing this patch (thanks!) with PCH soft strap #9 configured to have all lanes as x1. Actual routing is controlled by 3 GPIO lines from the super I/O, and it has card presence lines wired to the PCH. I got both working, but Bill still couldn't get his card to work on one of the two x1 slots. I need more fresh eyes to help. #2. Changing flash descriptor from within coreboot. I've come to a point where I need to be able to change the PCH soft straps based on user selection. As you can see in 85413, and in consultation with Nicholas (that convo is also on this list), to make it fully work I need to be able to change the otherwise read-only soft strap #9 in the flash descriptor, and it appears Asus is doing it as well. I know about SPI console - I actually used it during early attempts of porting my P8Z77-M - but I have not dealt with writing to the SPI from within coreboot nor have I studied SPI console deep enough to be able to come up with code of my own. 7-series PCH supports hardware sequencing if the SPI flash chip meets certain requirements. Does it mean I can just write() to the memory area mapped for SPI flash, and it fires the SPI commands for me? Will it do sector erase on my behalf and preserve what's not being overwritten? Nicholas mentioned some Haswell boards also need this done. Would love to hear some progress there. #3. Dynamic device tree? There will be times when the devicetree needs to change based on user selection. Not necessarily nvram options, but also choices made in 'make menuconfig'. In my efforts they are respectively enabling/disabling PCIe root ports 2-4 (based on whether port 1 is set for x4) and enabling the SIO serial port on Sabertooth if the user enables the "hacked serial port" in Kconfig. Devicetrees are supposed to be static, I get this. Where are the runtime hooks where code can go in and say "nope, this device is off"? Many thanks Keith

1 0

2025-01-22 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 23 Jan '25

23 Jan '25

# 2025-01-22 - coreboot Leadership Meeting ## Attendees Felix Singer, Andre, Mina Asante, Werner Zeh, Felix Held, Jay Talbott, Maximilian Brune, Matt DeVillier, David Hendricks, Julius Werner, Alicja Michalska, Karthik R, Jon Murphy, 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 ### [Werner] What is the guidance for the length of the first commit line? * We used to have a Wiki entry for that which I have ported over to our new documentation (see [CB:85915](https://review.coreboot.org/c/coreboot/+/85915)). Shall we still stick with 65 (max 75) characters, or shall we adjust? A quick [survey](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thr… on the mailing list did not reveal any path forward. * [FelixH] 72 chars is used to prevent line breaks when the commit is formatted for e-mail. * [David/Matt] Subject lines often have long paths (as mentioned by others). We should have some guidelines and examples on how to keep this small (what part of the path to mention, acceptable abbreviations for "mainboard", "common", etc) so as to avoid over-crowding the subject line. ### [Werner] Our documentation website (doc.coreboot.org) seems still not to be updated periodically. Is there something we need to do? * [FelixS] Documentation is currently built weekly by a cron job. It's a hacky solution intended to help with migration from old server to new one. Future plan is to have documentation built by CI. * [Matt] Can we increase frequency of cron job? * [FelixS] Yes, that should be possible. * We'll increase it to once per day ### [Werner] Intel has some plans around signing their FSP binaries and would like to present details to the community some day. * Can we offer a dedicated call for that with a broader representation of the community? Or shall we just do it in one of the regular Wednesday-Calls? * [Max/Felix] We probably don't need another meeting. Someone from Intel can just bring it to this one. * [FelixH] What validates signatures? Do we not own the reset vector on Intel platforms anymore? * [David] It seems like a good thing if signature validation is optional. If it's mandatory and enforced by ME or something then that will be terrible since it will cripple portability to other platforms. Can't use a validated Intel binary from a BKC in a new product, for example, and people with FSP source code won't be able to build and run it on a validated Intel platform (CRB). * [Alicja] What is the justification? This will negatively impact debuggability. * Alicja: The first answer was "security". The second answer is to reduce the number of issues due to customized FSP binaries out there. ### [Werner] Our last release 24.12 seems stuck (behind schedule). Anything we can do about it? * [FelixS] It's ready, we just need to update the blog. Tag was created. * But there is some issue - `git describe` shows 24.08. Maybe it's not annotated? # Next Leadership Meeting * February 5, 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 22 Jan '25

22 Jan '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for tomorrow, January 22, 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 ### [Werner] What is the guidance for the length of the first commit line? * We used to have a Wiki entry for that, which I have ported over to our new documentation (see [CB:85915](https://review.coreboot.org/c/coreboot/+/85915)). Shall we still stick with 65 (max 75) characters or shall we adjust? ### [Werner] Our documentation website (doc.coreboot.org) seems still not to be updated periodically. Is there something we need to do? ### [Werner] Intel has some plans around signing their FSP binaries and would like to present details to the community some day. * Can we offer a dedicated call for that with a broader representation of the community? Or shall we just do it in one of the regular Wednesday-Calls? [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Farewell to coreboot community
by LEAN SHENG TAN 21 Jan '25

21 Jan '25

Hi all, Couldn’t leave without saying goodbye to the open source community which I spent the most time mingling besides my previous company work. As many of you already know, I left the firmware field and thus 9elements to pursue my own startup. What a bizarre community with many interesting and great people, who I have grown to know many of you personally throughout the journey. In the end, I wish for the best of coreboot from the bottom of my heart, and hopefully it will be the de-factor firmware standard for providing much better quality and services compared to the existing solutions… Firmware world is a mess, and the introduction of coreboot came in as a spring water flows in some of very best devices in the world, and it just boot without much complications! Firmware should be simple and free the users from proprietary control!!! Always believed in coreboot, and will always vouch for you all :) Thank you for creating a very welcoming open source community that I had a lot of fun (and also some hard) times with ;) Best Regards, Sheng P.S: Any coreboot forks (whatever you called it Masharo or Pipapo), please pay your due in upstreaming your changes back to the main coreboot branch - especially for those companies who are having good profits (you know who you are) but refuse to actively contributing back to the community: maybe I will still come after you if I have too much free time; unless be a good boy and stop leaching for greed and profits, after all you are taking big advantage of the hard work from all the community members. Have some dignity.

4 5

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

19 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 18 Jan '25

18 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

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