coreboot January 2025

coreboot@coreboot.org

13 participants
19 discussions

Help me understand more about coreboot
by sourabadi 05 Feb '25

05 Feb '25

Hello I am a student from tehran university in iran and I am interested to booting system's and I research in this field I compiled compiled and build your project in the qemu and run successfully but i have problem if i want to changing message that show in the qemu. for this I changing some printf() function in file /coreboot/payloads/external/Seabios/seabios/src/boot.c and then commit this changing and use make to recompiling project but nothing changing and then use "make clean " for deleting all the compiled file and recompile all of the project again by "make" and after this i see all of the my changing in the /coreboot/payloads/external/Seabios/seabios/src/boot.c is deleted and even my git commited is deleted . how build system work this happens? how to solve this problem and changing the massage in the qemu terminal? and please explain to me source for this subject (i search in coreboot documentation but i can't find proper source) With respect and apologies for any English grammatical errors in the text.

2 1

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

31 Jan '25

Dear coreboot Community, We are pleased to announce that our next leadership meeting is scheduled for February 5, 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

[coreboot - Bug #576] (New) GPIO locking is broken on Kaby Lake and possibly other platforms
by Mate Kukri 30 Jan '25

30 Jan '25

Issue #576 has been reported by Mate Kukri. ---------------------------------------- Bug #576: GPIO locking is broken on Kaby Lake and possibly other platforms https://ticket.coreboot.org/issues/576 * Author: Mate Kukri * Status: New * Priority: Normal * Target version: none * Start date: 2025-01-30 ---------------------------------------- Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to [TPM GPIO reset attacks](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html). Trying to fix this by marking the affected GPIOs as locked in gpio.h and even also selecting `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` does not work. This was discovered last year and briefly discussed on #coreboot, but it came up again on the Heads matrix group in relation to supporting the TPM on the in-progress ThinkPad T480 port. -- 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

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

29 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

2 1

2025_01_29 coreboot Group Review Sesssion
by mina＠coreboot.org 27 Jan '25

27 Jan '25

Hello coreboot! Our upcoming biweekly group review meeting is scheduled for Wednesday, January 29. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still 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

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

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