# 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]
