# 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.... - 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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...