coreboot November 2023

coreboot@coreboot.org

32 participants
57 discussions

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel 07 Aug '24

07 Aug '24

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 12

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski 24 Apr '24

24 Apr '24

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 6

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 20 Feb '24

20 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

[PATCH] firmware: coreboot: framebuffer: Avoid invalid zero physical address
by Alper Nebi Yasak 28 Dec '23

28 Dec '23

On ARM64 systems coreboot defers framebuffer allocation to its payload, to be done by a libpayload function call. In this case, coreboot tables still include a framebuffer entry with display format details, but the physical address field is set to zero (as in [1], for example). Unfortunately, this field is not automatically updated when the framebuffer is initialized through libpayload, citing that doing so would invalidate checksums over the entire coreboot table [2]. This can be observed on ARM64 Chromebooks with stock firmware. On a Google Kevin (RK3399), trying to use coreboot framebuffer driver as built-in to the kernel results in a benign error. But on Google Hana (MT8173) and Google Cozmo (MT8183) it causes a hang. When the framebuffer physical address field in the coreboot table is zero, we have no idea where coreboot initialized a framebuffer, or even if it did. Instead of trying to set up a framebuffer located at zero, return ENODEV to indicate that there isn't one. [1] https://review.coreboot.org/c/coreboot/+/17109 [2] https://review.coreboot.org/c/coreboot/+/8797 Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- (I was previously told on #coreboot IRC that I could add coreboot mailing list to CC for kernel patches related to coreboot.) drivers/firmware/google/framebuffer-coreboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/google/framebuffer-coreboot.c b/drivers/firmware/google/framebuffer-coreboot.c index c323a818805c..5c84bbebfef8 100644 --- a/drivers/firmware/google/framebuffer-coreboot.c +++ b/drivers/firmware/google/framebuffer-coreboot.c @@ -36,6 +36,9 @@ static int framebuffer_probe(struct coreboot_device *dev) .format = NULL, }; + if (!fb->physical_address) + return -ENODEV; + for (i = 0; i < ARRAY_SIZE(formats); ++i) { if (fb->bits_per_pixel == formats[i].bits_per_pixel && fb->red_mask_pos == formats[i].red.offset && base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f -- 2.42.0

3 2

2023-11-29 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 30 Nov '23

30 Nov '23

# 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.htm…. - 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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Monochrome coreboot logo as BMP?
by Simon Glass 29 Nov '23

29 Nov '23

Hi, I am looking for a 160x160 BMP coreboot logo to use when booting U-Boot on top of coreboot, so that it is obvious to people that coreboot is being used. Typically it is used with a blank background. I have looked at the available logo but it is quite large. I am looking for something small, perhaps <10KB, so it needs to be BMP compressed (U-Boot does not support PNG at present). I have spent a bit of time trying to do this with inkscape and 'convert' but I cannot get one with anti-aliased edges. Can anyone help, please? Thanks! Simon

3 6

commit 0eab62b makes menuconfig more strict regarding the old configs
by Mike Banon 29 Nov '23

29 Nov '23

In my case, a csb_patcher.sh script [1] - among other things - delivers the example config files for the opensource AGESA boards. Although these configs haven't been updated for a while (i.e. a last update of AMD Lenovo G505S config [2] is 1 year ago), I got away with this: they are still working, just get refreshed when a user does "menuconfig" & "make" and result in a working coreboot build. However, with a commit 0eab62b [3] they are rejected [see 4]. Of course I'm going to manually "refresh" the configs to temporarily fix this problem, but I see this could increase the maintenance burden and reduce the usefulness of coreboot config files shared online... Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that outweigh these potential issues? [1] https://review.coreboot.org/c/coreboot/+/64873 [2] https://review.coreboot.org/c/coreboot/+/64829 [3] https://review.coreboot.org/c/coreboot/+/79259 [4] ./coreboot/$ make menuconfig src/soc/intel/meteorlake/Kconfig:457:warning: config symbol defined without type ./coreboot/.config:26:warning: unknown symbol: COMPRESS_RAMSTAGE ./coreboot/.config:230:warning: unknown symbol: ARCH_ALL_STAGES_X86 ./coreboot/.config:249:warning: unknown symbol: VBT_DATA_SIZE_KB ./coreboot/.config:256:warning: unknown symbol: UART_PCI_ADDR ./coreboot/.config:264:warning: unknown symbol: S3_DATA_POS ./coreboot/.config:265:warning: unknown symbol: S3_DATA_SIZE ./coreboot/.config:274:warning: unknown symbol: LOGICAL_CPUS ./coreboot/.config:459:warning: unknown symbol: INTEL_GMA_OPREGION_2_0 ./coreboot/.config:572:warning: unknown symbol: PAYLOAD_YABITS ./coreboot/.config:574:warning: unknown symbol: PAYLOAD_TIANOCORE ERROR: 10 warnings encountered, and warnings are errors. make: *** [build/util/kconfig/Makefile.real:47: menuconfig] Error 1 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

5 7

coreboot's role in the boot process -- is it time for a coreboot spec?
by Nico Huber 29 Nov '23

29 Nov '23

Hi folks, something I've been thinking back and forth about since the hackathon a week ago: Should we give people who promote coreboot something to refer to, something that more clearly states, what coreboot is? I know, some of you who know me might feel the urge to check if it isn't April the 1st. Nico suggesting a spec? What's happening here? I've always neglected the idea. Probably because I was too focused on fellow developers. But coreboot is not only discussed by develo- pers anymore. And we all know too well, developers don't make all the decisions. I believe having a document that basically says "that's coreboot, that's what people ask for" might help in, well, higher-level discussions. So what do I suggest? To have some high-level description of what coreboot does, where it starts, where it ends. And also, to be com- prehensive, the things that are set in stone: cb-tables, SELF for the payload. It's in C header files. But I guess the information could be imported for the last chapters. Overall, the spec should not be long. I imagine something like 2~4 pages plus the cb-tables. About the high-level part: Generally, I don't want to rush this. But I'll draft some things below that I already have on my mind. My current thoughts are mostly motivated by the "new bootflow for ARM64" thread[1] and Martin's excellent idea to rather call that "with coreboot technology" than "coreboot". Many people seem to agree. I guess, because it's not what we usually do. But what do we usually do? Shouldn't we write that down? coreboot boot process --------------------- coreboot's bootstrapping usually happens in two phases: 1. When a DRAM controller is part of the platform, it will be configured by coreboot to allow access to the main memory. 2. When the main memory is available, the platform is further initialized into an abstract state that allows generic opera- ting systems to run. (some simple picture here; it's too late in the evening for ascii-art on my end) coreboot starts with the first instruction on the main application processor (AP), or earlier when another processor runs platform initialization code from writable memory before the AP starts. Exceptions are made, when * the first instructions run from a boot ROM, or * the first instructions are pre-defined by the silicon vendor and the hardware doesn't allow execution of other code, i.e. due to cryptographic signature checks. In this case, coreboot starts with the first instruction from writable memory that can be controlled by the platform owner. Future hardware iterations should strive to allow coreboot to run earlier. After the hardware initialization, coreboot will write tables (cbtables, ACPI, SMBIOS and alike) with chip- and board-specific information. With this information, a generic operating system should be able to run without any further, board-specific know- ledge. Finally, coreboot loads and executes an embedded payload program from the same memory that holds coreboot. If possible, coreboot will cease all other execution at this point. It is the payload program's responsibility to continue the boot strapping on its own, without relying on any services provided by coreboot but the in-memory tables. Cheers, Nico [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3…

2 4

RFC: Behavior of make *config
by Patrick Georgi 28 Nov '23

28 Nov '23

Hi everybody, I updated Kconfig to track latest Linux last week and that brought some behavioral change with it. While these changes are appreciated in some respect, they also complicate work in others. I now proposed https://review.coreboot.org/79298, a change that exempts _all_ *config targets from strict symbol checking under the assumption that any attempt to edit a config should work even if the old configuration is unclean. It will save a clean copy if it saves on exit. A regular build will still fail with an error like this: /home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB ERROR: 1 warnings encountered, and warnings are errors. make[1]: *** [build/util/kconfig/Makefile.real:76: olddefconfig] Error 1 make: *** [Makefile:219: build/config.h] Error 2 Running `make olddefconfig` manually (that is, explicitly stating that you want to run the command) would clean it up. Now, given that this is a rather big semantic change, I wanted to make sure that the wider community can provide their input on how to approach this issue properly. Before last week, only `make oldconfig` was exempt from checking, and the checks made by the other *config targets were much more lenient. With this approach, all *config targets clean up the config (and will do so silently, which might be a concern!) but when the config isn't right, the build will fail, and loudly. Thoughts? Regards, Patrick

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 27 Nov '23

27 Nov '23

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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKr…

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2023