2025-04-30 - coreboot Leadership Meeting Minutes

# 2025-04-30 - coreboot Leadership Meeting



## Attendees

Martin Roth, Mina Asante, Werner Zeh, Jay Talbott, Andy Ebrahiem, Matt DeVillier, Jeremy
Compostella, Marshall Dawson, David Hendricks, Michael Zygowski, Alicja Michalska, Julius Werner,
Karthik R, Maximilian Brune, Felix Held, Jon Murphy.



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



## Minutes


### [MartinR/Nicholas Chin] Look at adding doxygen back to coreboot
  * (https://review.coreboot.org/c/coreboot/+/87227)
    [RFC][POC] Tree: Add doxygen config files and targets
coreboot used to have targets to build Doxygen documentation, but they were removed in
(https://review.coreboot.org/q/commit:619086d1056c) ("Treewide: Remove doxygen config files and targets") after it was decided that the doxygen documentation was dead. Recent discussion on a patch for doc.coreboot.org brought up the issue of how to keep API documentation up to date with the code, and there was some interest in being able to use the docstrings in the code to generate such information. Doxygen is one of the go-to tools for this sort of thing, but the previous attempt at using this required users to run a separate make target to view documentation, which may have contributed to its lack of use.
Instead of using doxygen to generate its own separate HTML output directly, there are tools such as Breathe [1] which can take the output of Doxygen and bridge it into Sphinx, which would allow API documentation to be seamlessly integrated into doc.coreboot.org and built automatically. To support this, re-add Doxygen configs and targets, but configure it for XML output, which is the format Breathe is able to parse.
  * The Gerrit discussion that prompted this idea:
(https://review.coreboot.org/c/coreboot/+/87186/4..5/Documentation/lib/timestamp.md#b192)
  * A proof of concept for how the whole Doxygen + Breathe thing works to pull in docstrings into our docs can be found in these patches: (https://review.coreboot.org/q/topic:%22autogen_api_docs%22)
There are also some alternatives, which are all based around the idea of “API docs in code, then generate documentation from that.” 
The Sphinx syntax for pulling in a particular API’s documentation is also fairly similar between them. 
With all of these types of documentation generators, you only need to add Doxygen/kerneldoc/etc style docstring comments for the APIs you intend to include in the documentation, and in the Documentation/*.md files you need to explicitly add a directive to pull in the docstrings for those items. This is in comparison to pure Doxygen documentation which runs and generates docs for the
entire tree (it is possible to exclude certain subdirectories but in general it is designed to run on the the entire project)
  * [NicholasC] kerneldoc from Linux (basically their own Doxygen-like tool)
    * I did some brief experimentation with this, and it also seems to work fairly well. It does seem
lighter than Doxygen + Breathe and is much faster than my current proof of concept. I think this
would also be easier to integrate into the doc.coreboot.org container as it doesn’t require a
separate step to run like Doxygen. That was causing me a lot of issues in the container due to the
tree being read-only and the output paths being different compared to running in the host OS. There
might be some Linux-isms that we’d need to deal with though, whereas Doxygen is a bit more generic.
    * Proof of concept here: (https://review.coreboot.org/q/topic:%22docs-kernel-doc%22) (this does
currently work in Docker, unlike my current Doxygen + Breathe proof of concept)
  * Sphinx C Autodoc (https://sphinx-c-autodoc.readthedocs.io/en/latest/))
    * Relies on clang, and I found it difficult to figure out all the proper compiler flags to pass it
to get it to work.
  * Hawkmoth (https://jnikula.github.io/hawkmoth/stable/))
    * Also relies on clang; had the same issues as the above
  * Decision: Let’s do a limited doxygen implementation for pieces that are pulled into the coreboot documentation directory. 
    Maybe use it for internal APIs that are used widely. Don’t make documentation a huge burden. When we do have doxygen, let’s add a 
    checker of some sort to try to keep it in sync. This is *NOT* a requirement. Make sure that it’s actually useful. Take a look at 
    cleaning up existing doxygen.

### [MartinR] Leadership meeting for Asia times
  *(https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/UMGFEEFOTMIDRNZLA375HJ3ROVTT3DX/)
  * One response in favor of this - either morning or evening is good.
    * One response probably isn't enough to set up a second meeting right now. Let’s revisit it in a
year or when we get more requests.
  * [David] If we do set up a meeting, we need to find someone in those time zones who runs it.
    * Can't rely on people in the US or Europe getting online at awkward hours (very late US time, very early Europe time).

### [Martinr/Michał Żygowski] redundancy of firmware with vboot
  *
(https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/IY6B2W4PLLTCLW2WHP3OO4J6F3T5QPS/)
  Add link to slides
  Slides:
  * Problem statement: lack of real redundancy in the firmware
    * Issues with backward compatibility
  * Current solution:
    * vboot enables coreboot to have a root of trust and verification for subsequent firmware stages.
  * Verified Boot in Chrome devices
    * write protection using WP# pin on SPI rom
  * Verified boot in Dasharo:
    * WP by chipset
  * Current solution: sources of incompatibilities
    * changes in flash layout, coreboot stage memory layout, changes in vboot
  * Current solution diagram
  * Proposed solution: Leverage Intel's top-swap feature to provide bootblock redundancy
  * Proposed Solution: Changes in new approach
  * Proposed Solution: Problems solved by the proposed approach
  * Proposed Solution: Problems *NOT* solved by the proposed approach
    * Changes in flash layout, recovery state
  * [Alicja] coreboot-specific solution for nvram
      * Updated flashmap is still a problem
    * This would be SOC-specific—not a coreboot-wide solution.
  * [Julius] Let’s look at solutions.
    * Releases should be done on a branch to keep vboot or coreboot changes from breaking.
  * Michal: This makes us as bad as the other IBVs
    * Julius: If we don’t freeze the branch, it’s almost impossible to maintain backward compatibility.
  * [Maximilian] We need to discuss this further outside of the meeting.
  * [Martin] This current solution is intel specific, so isn’t really useful coreboot-wide
  * [Julius] We definitely want to make vboot useful for as many groups as possible. Let’s discuss
it.
  * [David] Maybe instead of extending vboot, we can… create a different update mechanism, e.g. an
alternate path in ramstage where chipset registers, FD/APCB, etc. can be manipulated to disable RO
protections and an update can be done (somewhat like UEFI capsule updates). The current solution
breaks a number of protection mechanisms.
  * [Martin] Let’s set up a ‘workstream’ to discuss this.

### [Elyes] Jenkins is not functioning correctly when building the toolchain. See (https://review.coreboot.org/c/coreboot/+/87433) and (https://review.coreboot.org/c/coreboot/+/87342/2)
  * Martin will take a look at this.



# Next Leadership Meeting
  * May 14, 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.



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