Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, November 29, 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 ### [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 -> 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. - 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. ### [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. 1) We’re replacing an existing system that works. Is this the best place to spend our resources? 2) Because it would be replacing a working system, there should be relatively substantial benefits to be gained by updating before it’s considered. 3) As 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) ### [Patrick, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and dump it on the project, and get indignant when the project doesn’t adopt it wholesale, and 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. 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? ### [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. [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]
