coreboot Meetings Announcement And Agenda Call

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-hl9jUfEWhR3nONXbENqYJ2vAJvI/edit)
    * [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTNCWsrO3xuNyJM/edit#heading
h.astha87lu249)
    * [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_SgaTaWJcvO0/edit)

### [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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?pli=1
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]