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