Dear community,
Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023.[1] You are welcome to add things you wish to see addressed during the meeting to the current agenda items. [2]
## Current Agenda Items
### [Martin] Cover open action items
### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like.
### [Martin] Cancel the December 27th meeting?
### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * with the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work.
### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user.
### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, cbor or protobuf)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWhR3nONXbENqYJ2vA...) * [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTNCWsrO3xuN... h.astha87lu249) * [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_SgaTaWJc...)
### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is.
### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion.
[1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...