Sorry about that, something happened during cut and paste that eliminated the leading spaces. Martin
2023-09-20 - coreboot Leadership meeting minutes
## Attendees:
MartinR, MarshallD, MattD, RonM, TimC, FelixH, KarthikR, JuliusW, DanielM, JonathanH, SimonG, JonM, StefanR, NicoH, MinaW
## Minutes:
### sjg - RFC: Post-build control of serial console
* https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/F5NPE... * outside of the thread: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/D2PIP... * Enable/Disable the serial console on images with the console previously disabled/enabled. * In CrOS, both serial and non-serial are built. * Put control in the boot block. * Martin] This presents multiple issues: * Changing the bootblock will mess up cbfs verification * On AMD platforms, the bootblock is part of the AMDFW binary, not in the typical place. * CBFSTOOL would access the “coreboot control block” to enable/disable serial. CBFS attribute - use a magic number in the boot block. * [Martin] Let’s separate this into 2 issues - do we want this feature & how to enable it. * [Matt] What’s the size difference & impact to boot time. * No impact if serial is disabled at build time (since this feature of course will not be enabled) * Size of the serial drivers * Boot time is not impacted unless serial is enabled. * Stefan] We have defaults for cmos settings that can be changed (though obviously not all systems have cmos). There’s no uniformity across all platforms. Let’s make enabling/disabling options flexible so that we can use different back-ends depending on the platform. Can’t write to CMOS when the machine is up and running. * Julius] CBFS attributes are already (mostly) written up. * CBFS may not be a good option because of the code needed to read it. * [martin]This is just an argument about how to set up a new configuration mechanism. * Let’s use something that works with the current CMOS option mechanism. * Stefan] Let’s see if we can get rid of the ChromeOS GBB flags while we do this. * Julius] this is being discussed, but not really relevant here. We can already put the existing GBB flags in CBFS. * Martin] Let’s not add yet another method of configuration. * Smmstore - SJG: uses an FMAP region so available later in bootblock? * CMOS - SJG: not controlled by firmware image * can we use the options API? * one drawback?? is that it uses strings to access the values * Stefan] Can only be modified when the board is running. * Devicetree - SJG: build-time * CBI - SJG: doesn't this fetch from the EC? * Martin] Yes * Storing things in the SPI ROM. - that is this proposal. * Martin] I believe that there’s already a method for doing this that’s implemented. * CBFS flag files - SJG: available later in bootblock? * VPD - SJG: not available in bootblock? * Kconfig? - SJG: build-time * Nobody disagrees with the idea of being able to enable/disable the serial console at runtime, the thing that needs to be figured out is the method.
### [Nico] What to do about undisclosed downstream coreboot used in production? (cf. discussion of [CB:77466](https://review.coreboot.org/c/coreboot/+/77466))
* Martin] There was a misunderstanding about whether this code was used in production images or not. From the discussion last meeting, as David described it, the EINJ is strictly for debug. * What’s our official position? * [Martin] We decided this in the last meeting. EINJ is *debug* code and would never be used in a production image. It’s useful code, so the agreement was that it should be left in coreboot, but could be moved to vendorcode. * How could we push back? E.g. ask to add absence of such conflicts to the criteria for “OCP accepted” badge? * [Martin] I think pushing back should be handled on a case-by case basis. * Concerns: * It seems unfair to deny the addition of new blob support on one hand and allow direct linking to proprietary code on the other. * [Martin] Are you arguing that we should allow other blobs because of a blob that’s never going to be used in production images? * Weakening the idea of the GPL might make it harder to get code out of companies that see a business advantage in their work. * [Martin] How does this weaken the GPL? * We need better communication about what any code that is used along with sources outside of the tree are for. There needs to be a maintainer for these items. * Let’s discuss this further later.
### [MartinR] Formatting arguments: What’s the coreboot standard for wrapped lines?
* Should they match the start of the previous block or just use two tabs beyond the previous indentation? Or something else? * Julius] Decide on place-by-place basis - let the developer decide. * Can we start using clang-format for everything so that we can stop arguing about formatting? * Julius] Let the author decide - new contributors should just follow the existing format. * Ron] This worked well on other platforms - Rust & Go communities - just format it and move on. * Nico] We decided on clang-format already. * Martin] We just need to finish the implementation. Clang format versions caused issues. * Jon] Not using clang-format causes confusion and keeps people from wanting to update patches. * Felixs] hook up clang-format to the CI and allow the reviewers to decide * Ron] this would keep the current situation. Make the automaton the arbiter. * Simon] Agrees with ron - let’s not argue about formatting. * Clang-format would be done a directory at a time. * Felix] Patches that are in flight will be problematic. * There’s a script to reformat patches: clang/tools/clang-format/clang-format-diff.py * Martin] I will pick up the existing patch for the clang-format config, and we can discuss the configuration settings. I’ll send out a sample to the mailing list and write up some instructions on how to use it. * We can use the clang-format from the coreboot toolchain.
### [MartinR] I’m planning on hiring someone to help with this meeting.
Duties include: * Announcing the upcoming meeting on IRC, Slack & Discord. * Helping keep minutes during the meeting * Sending the minutes to the mailing list at the conclusion of the meeting.
I’ve already picked a person, and hope they’ll start attending in the next few meetings. I’m paying for this out of my own pocket to avoid any issues with having the SFC pay someone, which involves contracts & whatnot.
# Next meeting October 4th, 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...