# 2023-11-29 - coreboot Leadership Meeting Minutes
## Attendees:
Christian Walter, Daniel Maslowski, David Hendricks, Felix Held, Felix Singer,
Jay Talbott, Jeremy
Compostella, Jonathan Hall, Julius Werner, Lean Sheng Tan, Marshall Dawson,
Martin Roth, Matt
DeVillier, Matt Papageorge, Maximilian Brune, Nico, Patrick Georgi, Simon
Glass, Tim Crawford,
Werner Zeh, Mina Asante.
### Open Action Items
* 2023-11-29
* [Open]FelixS: Draft a proof-of-concept proposal to switch to meson.
* 2023-11-15
* [Started] Martin: Publish coreboot FAQ
* 2023-11-01
* [Open] Martin: Shallow submodules - document & test, then update submodules
if testing goes well.
- Additionally look at whether the .branch option helps.
* 2023-10-18
* [Started] MattD and WernerZ: Work on compiling a list of website
requirements from the mailing
list.
* No feedback yet - Matt will continue to gather feedback.
* Probably have all of the community input - Need to capture the
requirements as a starting point.
* Move to next year.
* [On hold pending requirements] MartinR & FelixS: Build a POC front page.
* [Open] Arthur: Ask Philip about how to use company logos.
* 2023-10-4
* [Started] Martin: Write a tutorial for gerrit - Feel free to help.
* [Open] OSFF: Look into making a video about using gerrit.
* Discussed with Christian who felt this was a good plan.
* Look at next year.
* [Open] Martin: Write a document about vendorcode submodules.
* 2023-09-20
* [Started] Martin: Work on clang-format config update.
* We can use the clang format version from the coreboot toolchain!
* Some issues with clang format - martin will present.
* See CB:78833 for what the current format’s changes will look like.
* [David] #defines for bits in headers lose their indenting. Maybe we
should have clang-format
ignore headers for now. Smaller issues can be handled on a "use your best
“judgement" basis.
* [Done] Martin to add bitfield example to 78833
* Let’s look at running this just for .c files to start with.
## Minutes
### [Martin] Cover open action items
- Clang format - Can we merge the format update at
https://review.coreboot.org/c/coreboot/+/78832,
then start converting .c files?
- Header files can be put off until later.
-Requested that patches be reviewed & merged.
- Website requirement status?
- Delay until next year.
### [Arthur] A new bootflow on ARM64 server using more of TF-A
- Motivation: More ARM-Server support in coreboot
- ARM wants to put coreboot in the ARM Base Boot Requirements:
https://developer.arm.com/documentation/den0044/latest
- Vendors are more inclined to consider coreboot if it is in a spec written
and supported by ARM
- It is currently planned to put the TFA on ARM -> coreboot -> Linuxboot
bootflow in there as an
alternative to the EDK2 variants. TFA can be open source as well as closed
source so it is not
entirely the same as letting FSP start at Reset
- The Idea is that coreboot is considered by big Vendors when they
formulate their specs (so that
coreboot doesn’t have to hack around to make stuff work for it)
- Reuse working solutions (TF-A) can be a good idea: easier porting.
- The scope of the coreboot side of things is small and very reusable:
generating SMBIOS and ACPI
is quite portable between platforms.
- patches necessary to accomplish this mainly are the following:
- https://review.coreboot.org/c/coreboot/+/74798/9
- https://review.coreboot.org/c/coreboot/+/78284/8
- patch missing that grabs FDT in bootblock (like done in RISC-V bootblock)
- Using only ramstage can be minimally invasive. A similar thing was done to
optionally build
romstage sources inside the bootblock:
https://review.coreboot.org/c/coreboot/+/55068
- coreboot's security model often relies on it being the first code that
executes. This might need
some changes.
- Handoff data from TF-A is often in FDT format for which ramstage has
support.
- TF-A is BSD3 licensed. You may not always have access to the source code
for your platform.
* Currently use bootblock & romstage, but they basically do nothing more than
setting up cbmem.
Only generating SMBIOS & ACPI tables.
- This really depends on the platform though. Other platforms than the
initial vendor would be able
to implement more setup in coreboot if desired.
* Another concern is that this could set a precedent for other platforms
taking over the reset
vector and wrapping coreboot.
- We definitely don’t want to do this on X86
- ARM is different?
- Intel wanted to do this before -
https://universalscalablefirmware.github.io/documentation/1_terminology.html#usf-layers.
- Can we accept this case and consider accepting other use cases when they
come up? All we can
really do is prevent the name ‘coreboot’ being used - anyone can take and use
the code as long as
they follow licensing restrictions.
* This is just a discussion about doing the minimum needed to support
inclusion into ARM’s Base
Boot Requirements. We’d still be able to refuse any particular additions to the
codebase (though
vendors can fork this).
* [Felix H.] If we put the TF-A bootflow with coreboot code into the spec, we
should also put in a
coreboot-native bootflow next to it into the same spec.
* [simon] The way that TFA operates is unfortunate - arm wants to produce
blobs out of TFA instead
of supporting other open source projects. Beware.
* [Martin] Is there a deadline? Spec review is in January.
- Maybe the ease of use and quality of coreboot convinces a more full
adoption on server (use only
BL31 like other platforms)? Maybe I'm naive on this?
* [Martin]
1) This is taking a piece of coreboot and using it in a different way than
normal. I recommended on
the mailing list that we call this flow something other than just "coreboot' so
as not to confuse
things or dilute the meaning of what coreboot is. Maybe "ATF with coreboot
technology" or
something.
2) This allows us to expose coreboot to people who would otherwise be using
a completely different
solution. That's a *really* good thing in my opinion.
3) We should try to be a good player in the open source firmware space and
work with other projects
to create solutions. If this means using pieces of coreboot, I'm all for it,
similar to wanting to
be able to take pieces of other projects and use them to extend coreboot's
functionality. Sure, we
could block it here and force it to be forked, but that doesn't really help
anyone.
4) Maybe to differentiate this, we can go further than just making it a
Kconfig option and actually
add a new makefile target. That would make it even more plain that this isn't
the full coreboot
build.
- No decision was made at this meeting, but the leadership is leaning towards
accepting the
proposal.
**Leadership viewpoint:
* [David] Maybe the situation here is not as good as we’d hoped. We’d like
to have coreboot allowed
for inclusion than have ARM push everything to coreboot.
* [Matt] - Agree with David, but it’s better to allow coreboot to be used.
Hope is that by
providing an alternative to EDK2, we’ll help push open source firmware.
* [Werner] - See both ways. This discussion is about the spec - Document
the bootflow for the spec
and the regular bootflow, and this would probably be enough for now.
### [Martin/MaxB] Look at improving the readability of our build system
* Our current build system uses make, but stretches it way beyond most
makefile-based build
systems. This was done to add abstractions which, for example, make it much
easier to add files to
the various stages.
Because of this complexity at the heart of the build, it can be very
difficult to understand what’s
going on in any given section. One way that is being looked at to improve this
is indentation of
the if clauses, but this is problematic without rewriting some sections. See
CB:79230
PatrickG encourages folks to consider Burning the Diskpack because he feels
that people are too
reverent about old work. The build system is 14 years old (and replaced a build
system that was 10
years old at the time): if there’s an opportunity to achieve a significant
improvement in that area
by replacing what we have with something else, go for it! (That doesn’t mean
that it must be done.
But consider it besides the various fixes that could be applied)
* [Martin] I agree with Patrick, but have some qualifications
i. We’re replacing an existing system that works. Is this the best place
to spend our resources?
ii. Because it would be replacing a working system, there should be
relatively substantial benefits
to be gained by updating before it’s considered.
iii. While Patrick doesn’t want to discourage change just because the
build process is old, we also
shouldn’t look to throw it away just because it’s old.
- (Patrick agrees with all of that)
* There was a proposal to switch to meson. FelixS will do a proof of
concept.
* Switch to .mak or .mk - not .am or .in (used by autoconf/automake)
### [FelixH] Announcements for non-regular meetings
* A non-regular coreboot meeting should be announced at least on the previous
work day before the
time the meeting starts, so that everyone has a chance for preparing for the
meeting. [Martin] And
- check your damned links.
## Closed action items
* [Done] Martin: Make announcement about changing release numbers in the
release notes of the final
4.xx release. Following releases will use year.month.sub release format. 24.02
(24.02.00 implied)
would go to 24.02.01 if a release update is needed. The next release, 3 months
later, would be
24.05.
* [Done] Martin: Create coreboot governance page
* https://review.coreboot.org/c/homepage/+/79312
# Next meeting
* December 13, 2023
* [Meeting link](https://meet.google.com/pyt-newq-rbb)
* [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/edit?pli=1
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
