2025-10-29 - coreboot Leadership Meetings Minutes

# 2025-10-29 - coreboot Leadership Meetings 


## Open Action Items
  * 2024-11-27
    * [Open] Send out poll with regards to  LLM usage (requested by SFC)
  * 2024-10-30
    * [Open] Add clarification to docs: “Do not use gerrit change-id or CB: format in reference to already-merged patches.”
  * 2024-10-16
    * [Open] 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
    * [Open] 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
    * [Open] 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)
      *  [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long-term project.


## Announcements & Events
  
   
 
## Late GMT coreboot Leadership Meeting Minutes


## Attendees
Martin Roth, Matt DeVillier, Jay Tallbott, David Hendricks, Karthik R, Mina Asante, Julius Werner, Alicja Michalksa.
 

## Minutes


### [Martin] Discuss the early meeting agenda.

### [Julius] C23 patches
  * Should we switch to C23? Benefits/drawbacks?
    * [Martin] I don’t see an issue with the concept, but we had already decided to wait for a few years until the toolchains in the distros that people are using have caught up.
  * If so, does it need to be a Kconfig?
    * [Martin] I don’t think a kconfig makes sense. Either we use it or we don’t.
  * Which C23 features should we actually start using?
      * [Currently proposed patches](https://review.coreboot.org/c/coreboot/+/89701/2) add a lot of cruft and churn… 
  * Also, should we maybe have some guidelines about how to weigh the trade-off between practical benefit and churn/disruption to other developers (Gerrit notifications, breaking git blame, etc.) for large, tree-wide, auto-generated patches?
    * Let’s stick to any non-invasive patches for now. Having the #if spread throughout the codebase is… ugly.
  * Should these sorts of patches be discussed more broadly before being implemented?

### [Martin] Testing coreboot.
  * We discussed testing with the 9E team - we’re going to start working with them to set up some test boards that would report back to coreboot.
  * coreboot would build the binaries via the CI - these would be password protected so that we don’t distribute working binaries.
  * Siemens tests are already set up and can be triggered by adding the user to the patch as a reviewer.
  * Need to continue working with google to have builds from the main branch report back to coreboot somehow.
  * Discussed testing setups: 
    * Alicja is working on a custom board using an STM32 for 50 euros. Maybe 100 for a professional setup with isolation.
        * David: Look at “littlebmc,” which was a presentation at OSFC. The SOC itself might be obtainable from Alibaba. The Zephyr work could be generically useful as a way to control the STM32 (or whatever) from an OS that can be easily adapted for servers.
    * Martin created a spreadsheet a while back with a number of remote setups: (https://docs.google.com/spreadsheets/d/1aDfPYRuFz0GfNl3-UAt9GYIpSW3Ui72XHwN0or3nxxA/edit?gid=0#gid=0)


## Early GMT coreboot Leadership Meeting Minutes


## Attendees
Mina Asante, Ziang Wang, Shuo Liu.


## Minutes


### [Ziang] ARM LBBR counterpart on RISC-V? (may be LBRS -- Linuxboot Boot & Runtime Service)
  * RISC-V community raised an open https://lf-rise.atlassian.net/wiki/spaces/HOME/pages/661585922/COREBOOT_00_04+-+coreboot+and+Linuxboot+For+RISC-V+Systems#Opens
    * Do we have buddies that worked on the LBBR before interested in LBRS for RISC-V this time?
    * If we are into this, there will be a new task group set up for drafting the LBRS spec.
        * Ron is probably going to be knowledgeable about this. David will talk to him. 

### [Ziang] Open: Standalone Ramstage?
  * We now have emerging silicon designs that do not let the application processor bootstrap itself, which means DRAM and PCIe RC etc. will be taken care of by other co-processors, and the AP starts directly into RAM without CAR.
    * In this case there would be less interest in implementing a full combo with bootblock and romstage. Yet Ramstage Hardwaremain is still necessary for a complete platform firmware.
    * Will it make sense to use ramstage as a standalone software (with payload for the rest), like we add a special build option in coreboot?
    * Maybe we could try it out with OpenSIL on AMD platforms first?
    * [Martin] The way that coreboot is architected, we really expect to run through all the various stages. We don’t have an issue with a standalone ramstage, but it may take some architectural changes. I think that a single combined stage with all phases might make the most sense. I don’t oppose this attempt in any way.
        * [David] There are some ARM-based platforms that have (almost) empty romstage, for example. So even if we can't easily skip a stage entirely without ugly architectural changes, we can strip it down to practically nothing.
        
### [Shuo Liu] Is it possible to mirror the VPD repository on GitHub? (https://chromium.googlesource.com/chromiumos/platform/vpd)
  * This shouldn’t be an issue. Let’s discuss it and make sure we understand exactly what’s needed.



# Next Leadership Meetings Date
  * November 12, 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.

We now host two leadership meetings, one in early GMT and one in late GMT, to better accommodate
participants from the Asian time zones. 
Kindly note that both sessions use the same meeting notes and Google Meet link.


# coreboot Leadership Meeting Notes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]