2026-02-18 - coreboot Leadership Meeting Minutes

# 2026-02-18 - coreboot Leadership Meeting


## 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
  * Next Open System Firmware - OCP Project Meeting 
    * Date: [February 26, 2026](https://coreboot.org/calendar.html)



## Attendees

Werner Zeh, Mina Asante, Jay Tallbott, Matt DeVillier, Rangasai Chaganty, Ravi Rangarajan, Ingo Reitz, Chris, Alicja Michalska, Julius Werner.


## Minutes


### [Werner] Representatives from Intel responsible for the FSP singing approach (Ravi) will be in this meeting. The community is able to ask remaining questions in the scope of FSP signing.
  * [Ravi]: If FSP-O would be executed first and then the rest of the firmware would start at the address of today's reset vector (0xfffffff0), would that be considered as “owning” the reset vector?
    * [Werner]: It is not the address value that defines the reset vector but the first instruction that is executed by the host CPU.
      * [Jay]: Would need to see the full boot flow in this case to understand it better.
      * [Julius]: Yes, it is not the address that defines the reset vector but the first executed mutable instruction. It is about platform control and not an address value.
    * [Werner]: The early stage (the one before the reset vector, e.g. FSP-O) might be vulnerable, and the community is not able to do anything to fix it and will need to rely on the chip vendor to fix it. This does not always happen in time.
      * [Sai]: Is there a document summarizing what is and what will not be acceptable in the context of execution flow by the community?
    * [Werner]: Not yet but we can start one at doc.coreboot.org. 

### [Matt] Attendance for review sessions has been pretty low; should we adjust the date/time?
  * [Alicja]: Not many people do submit patches currently (only Matt and some Google people). We need more people being active here.
    * Werner: Will try to get some people from Siemens involved (can’t promise though). 

### [Matt] Several areas have no maintainers currently, so patches pushed often have no reviewers automatically assigned. Perhaps we have a default/fallback group of maintainers (~5 people?) that are assigned when none exist? 
  * [Alicja]: We do even lack maintainers on many mainboards. People pushing a new mainboard are not added as maintainers. Then, patches to those boards will not be automatically sent to the persons who uploaded the mainboard initially.
    * [Werner]: Do we have a specific spot in the tree where it currently is most painful?
    * [Matt]: Need to look it up.
    * [Werner]: Can we create a list of missing maintainers/code places in the current code base? Maybe we can push it out to the mailing list to make it transparent?
    * [Alicja]: Will prepare the list and send it out once she has time.
    * [Werner]: We will set up a Google doc in the coreboot space for this purpose and make it publicly readable by everybody but writable just by a few people (including [email protected]).

### [Matt] Several mainboards have or are in the process of implementing power sequencing for Gen4/5 NVMe drives as the existing GPIO frameworks are not sufficient to meet the power sequencing timing requirements.
  * How can we add this at the project level to avoid duplication?
  * How can we do this pre-device init when device enablement/presence is unknown?
    * Discussion to continue at the next leadership meeting.



# Next Leadership Meeting Date
  * March 4, 2026.
  * [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 Notes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]