# 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)/c...). * 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 <chentsung@google.com> * M: Hung-Te Lin <hungte@chromium.org> * M: Yu-Ping Wu <yupingso@google.com> * M: Yidi Lin <yidilin@google.com> * 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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj....