# 2025-11-12 - coreboot Leadership Meetings
## Open Action Items
* 2025-11-12
* [Open] Werner: Set up a call with Intel in early December
* [Open] Martin: Will take care of patches older than a year.
* 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
Mina Asante, Jay Talbott, Werner Zeh, David Hendricks, Matt DeVillier, Julius
Werner, Maximilian Brune, Alicja Michalska, Jon Murphy, Pono, Karthik R, Martin
Roth.
## Minutes
### [Elyes] Can we remove OpenSBI from 3rdparty?
* Currently, the 3rdparty/opensbi requires Position Independent Executables
(PIEs), which coreboot does not support
(https://qa.coreboot.org/job/coreboot-gerrit/285600/testReport/junit/(root)/clang/EMULATION_QEMU_RISCV_RV64/).
* So far, coreboot has been using an old version of OpenSBI. However, this
outdated version is now preventing us from updating Clang and GCC.
* [Martin] What would this mean to the project?
- We’ve tried updating to the latest openSBI in the past, but that was
difficult, though I don’t remember why.
I know that there are a couple of patches that worked towards this in the past,
but I don’t know if they ever got merged.
* [Max] Here is a patch to update openSBI and make it dependent on clang:
(https://review.coreboot.org/c/coreboot/+/80138/9)
* [Max] SBI is standard on RISC-V; we need it for all RISC-V targets
(maybe just two mainboards and one emulated mainboard). Therefore, it is better
not to remove it. OpenSBI does not hold us back from updating Clang.
* [Werner/Matt] We will keep OpenSBI as a submodule
### [Max] Can we auto-abandon gerrit patches after a certain period of time?
* Sadly, people don’t abandon their patches even if they didn’t touch them
for years. That has some downsides. For example, at some point someone (I don’t
remember who) removed himself from hundreds of old patches, which caused them
to go back to the top of the list in gerrit. It's also useful to have a more
sane list of open patches for searching purposes. I also sometimes just forget
about patches, so it would be nice to get a notification from gerrit.
* [Martin] We used to do this, but when we moved to the main branch from
master, it reset the dates for all changes. It’s probably been long enough that
we can abandon anything older than a year again. I’ll take care of that.
- Another issue is that we’d like to get patches merged instead of just
abandoning them. This involves people taking over old patches. We’ve addressed
a lot of the outstanding core coverity issues, so maybe we can use every other
review session (Wednesdays that we don’t have leadership meetings) to look at
abandoned patches that could be revived and taken over.
* [Matt] Should we implement a linter test to throw a warning when no “TEST=”
line is available in a patch commit message? We could encourage this even in
the Gerrit guidelines to help others to reproduce tests when a patch is taken
over by somebody else.
* Matt will have a look and take care.
* [Alicja] This is a simple chip ID patch:
(https://review.coreboot.org/c/coreboot/+/89157). However, buildtest complains
about chromebook bootblock builds (size of bootblock too big).
* [Max] This happens every now and then; no clue what goes wrong.
* [Julius] There are many reasons why this can happen, as the bootblock
size is limited due to early memory size constraints. This is nothing
chromebook specific.
* [Max] Can the SRAM size be extended to make the bootblock fit?
* [Julius] Not always; news to be treated case-by-case
* [Alicja] What to do when this happens on an unrelated patch?
* [Julius] Reach out to the maintainer (from the maintainers list) of the
failed board and ask for help. If there is nobody there, reach out to me for
Chromebooks
* GOOGLE MEDIATEK-BASED MAINBOARDS
* M: Chen-Tsung Hsieh <[email protected]>
* M: Hung-Te Lin <[email protected]>
* M: Yu-Ping Wu <[email protected]>
* M: Yidi Lin <[email protected]>
* S: Supported
* F: src/mainboard/google/asurada/
* F: src/mainboard/google/cherry/
* F: src/mainboard/google/corsola/
* F: src/mainboard/google/geralt/
* F: src/mainboard/google/kukui/
* F: src/mainboard/google/oak/
* F: src/mainboard/google/rauru/
* F: src/mainboard/google/skywalker/
* [David] Could we switch to SFDP for those boards? This would cut down the
chip ID array and therefore save space in the bootblock
* [Julius] SFDP has disadvantages, too, as you need to query the SPI chip
for the information in every stage.
### [Werner] How to deal with the signed FSP approach from Intel
* As presented at the last OSFC
(https://www.osfc.io/2025/talks/intel-r-signed-fsp-and-verified-boot/), Intel
has plans to only execute signed FSP binaries. The current approach from Intel
will heavily affect coreboot’s architecture. Can we start a discussion on how
to deal with this?
* [Jay] Ravi agrees that there need to be an exception for some users that
are not able to use the new boot flow. It seems to be heavily pushed from the
PC ecosystem
* [Werner] We should start to work on this. Interested parties are Google,
9elements, SysPro, Martin, and Matt. I will set up an initial call with Intel
in early December to start the discussion between Intel and the community.
* [Martin] We can set up a CBFS mechanism to verify a binary before it gets
loaded against a signature provided.
* [Jay] We need the ability to build our own FSP for reasons.
* [Martin] You have a license; go and sign it with your key
### [Martin] Cisco Meraki ignoring the GPL
* The issue with Cisco devices that used coreboot that didn’t get the source
code released is still present. The SFC isn’t interested in a lawsuit, but Hal
Martin would still be interested in pursuing something if he can. How do we
want to address this?
Obviously it’d be better if Cisco just released their source code as they
did once previously, but they haven’t responded to queries to release the
source in several years
* Do we want to help Hal with his legal campaign?
* Help raise funds?
* Donate money to his cause?
* Do we want to just make this as public as possible and try to shame Cisco
into releasing the source?
* Publicize this widely on the blog, twitter, press releases, etc.
* Add a webpage of companies that we know won’t comply with the GPL
* Other ideas?
* Or do we just want to ignore the issue?
* [Matt] Public shaming (e.g. a blog post on phoronix) won’t hurt;
maybe add a “hall of shame” on the coreboot webpage.
* [Jon Murphy] Set up a letter on openletter.earth might help
* [Werner] I do like this idea.
* [Martin] Sure, let’s reach out to Hal and propose this.
* [Werner] Will ask if FSFE has interest in this, too
* [Pono] SFC does not want to have a lawsuit, but we can look into
other opportunities we might have.
* [David] Be careful - it might look bad if people wonder why
(https://coreboot.org) isn't taking action financially, leaving it to some dude
to do the dirty work.
## Early GMT coreboot Leadership Meeting Minutes
## Attendees
Mina Asante, Werner Zeh, Jon Murphy.
### No issues on the early GMT meeting agenda.
# Next Leadership Meetings Date
* November 26, 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]
