November 2023 - coreboot - mail.coreboot.org

RFC: Proposal for Devicetree.cb & the C preprocessor
by Martin Roth Nov. 9, 2023

Nov. 9, 2023

Hi Everyone, We are again considering running the devicetree.cb files through the C preprocessor before they're used by sconfig to generate the static configuration structures. This suggestion came up due to the desire to be able to have some control of devicetree with Kconfig. See footnote [1]. We discussed this previously in 2022-06-29 leadership meeting and decided not to use the C preprocessor at that point. Unfortunately the discussion and reasons for this decision were not captured in the minutes. Proposed rules: The standard coreboot header files can be included and used, similar to how we do things with the .asl files now. We'll have a way to exclude sections of the header file that aren't appropriate to be included. Allowed: - #include, of course - #if, #ifdef, #else, #elif, #endif and the like may be used. - #define is allowed only for simple Object-like macros Forbidden: - Function-like macros or any macros that take arguments may not be used, even if included from header files. The single exception is the CONFIG() macro to unify with the rest of coreboot. - Standard pre-defined macros like __FILE__ and __TIME__ should not be used - #undefine, #ident, #sccs, #line, and #pragma should not be used in devicetree files. - Obsolete features such as #assert and #unassert should not be used - Using build time macros defined in the Makefile (compiling with a -D option) These rules are proposed to limit the impact of the C preprocessor, and to try to prevent everything from just becoming a series of function-like macros. This could dramatically modify how the devicetrees are created, which is not what we're looking for. Question: If we do use the C preprocessor, do we want to get rid of '#' as the character to begin comments and switch to '/* */' & '//' C-style comments? The reasoning behind this is that the # comment style could get confused with the preprocessor commands. If # is a comment in devicetree, and someone types #efine instead of #define, there won't be an error, and could make debugging the issue more difficult than it needs to be. Martin Note: Even though proposal could greatly extend the flexibility of the devicetree, I'm not really a proponent of this idea. I'd rather add to the devicetree.cb grammar and generate the static code that uses the config options as discussed in [1]. If using the C preprocessor is the general preference though, I'll get behind that. [1] https://review.coreboot.org/c/coreboot/+/78604

2 1

Adding Rust and Go to the coreboot toolchain
by Martin Roth Nov. 8, 2023

Nov. 8, 2023

I'm proposing that we look at adding Go and Rust to the coreboot toolchain. Go: We’re already using a number of things written in Go as a part of the build, and they currently use the system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the build. Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s currently a problem or not. SBOM, STM Rust: Rust is starting to be used more and more widely as a system programming language. The Linux kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust. While I’m not personally a fan of Rust, I can see the need to support it coming. Ron has already posted a patch to add Rust support, but I think it needs to be reworked so that everything is contained in the XGCC directory, has a stable version for coreboot, and doesn't conflict with any system tools. https://review.coreboot.org/c/coreboot/+/74124 Neither of these is particularly urgent in my opinion, but I want to get the discussion started. I've added this as a topic to the next coreboot leadership meeting. Martin

5 6

RFC: A new bootflow on ARM64 server using more of TF-A
by Arthur Heymans Nov. 8, 2023

Nov. 8, 2023

Trusted Firmware A ( https://github.com/ARM-software/arm-trusted-firmware/tree/master) is ARMs reference firmware implementation. It currently consists of multiple programs of which at least the following: - BL1: roughly equivalent to coreboot's bootblock - BL2: roughly equivalent to coreboot's rom and ramstage - BL31: Implements a secure runtime, required by for instance Linux, also used by coreboot - BL32: roughly equivalent to a payload On ARM64 coreboot currently takes BL31 from TF-A. On some platforms BL31 is even the only component that is implemented in TF-A as a different program like coreboot or u-boot takes care of platform initialization. However on some platforms a 'full' working TF-A implementation exists. On ARM server platforms the 'preferred' way of informing the OS is via UEFI, ACPI and SMBIOS. There is some rationale on why: https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt TL;DR: "if you want to run an old kernel with new hardware ACPI could be a better solution than devicetree". Both the UEFI and ACPI spec are wild beasts to tame (with many pages) so ARM came up with essentially a TL;DR of that spec which is called Server Base Boot Requirements ( https://documentation-service.arm.com/static/63cfe3aee4378a55c5e03d96?token= ). Now on a lot of existing ARM server platforms TF-A exists as 'full' solution. Currently the SBBR is satisfied by adding a EDK2 or other proprietary UEFI solution that gets loaded by TF-A. Not everyone likes these UEFI implementations as they are big and well... not so nice. So the idea came up to lighten that part of the burden (implementing tables and loading the OS): use coreboot to generate ACPI and SMBIOS (well supported on x86 and small changes needed for ARM), implement a small UEFI (e.g. with libpayload, just enough to load Linux from flash) to get a lightweight LinuxBoot firmware. This is a pretty different bootflow than what most are used to in coreboot. Normally coreboot is the first code that gets executed (on the main CPU) and it's in charge of hardware init (or offloads that to blob). Here TF-A would be the first code that gets executed. This for instance means that a different exception level would be used: ( https://review.coreboot.org/c/coreboot/+/74798) Also in this use case only ramstage (with a potentially a decompressor stage to make things smaller) would be used as we start in RAM with most of the hardware init done. So here are my thoughts on the idea: - 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. - 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? The platforms we implemented A POC doing this, have an open source TF-A btw. As this is a pretty new way of using coreboot (ramstage only), I wanted to have your ideas on this. Arthur Heymans

3 3

Comet Lake: TOLUM change causes suspend/resume after reboot to fail
by Jonathon Hall Nov. 8, 2023

Nov. 8, 2023

Hi all, On Librem Mini v2, rebooting, then suspending and resuming fails to resume. I've tracked this down to a change in the TOLUM returned by FSP, which causes failures to find important cbmem regions during S3 resume. (I've run into problems relating to the TOLUM change before: https://puri.sm/posts/how-we-fixed-reboot-loops-on-the-librem-mini/.) This doesn't seem to happen on all CML boards but has always happened on Mini v2 for whatever reason. I have some ideas to address it, but I'm not sure which is best. For example: * Cold boot: cbmem_top() = 0x99fff000 * Reboot: cbmem_top() = 0x9a000000 (4K later, FSP seems to reserve 4K less memory for itself on reboot) * Resume after reboot: cbmem_top() = 0x99fff000 (will not be able to find cbmem from reboot, not sure if the upper 4 KB have been overwritten by FSP) coreboot needs to find cbmem (the imd structures) at TOLUM on resume, so failures cascade from there. (Happy to describe in detail but I don't think anything after this point is the root issue.) It seems pretty unlikely that FSP is going to change, so coreboot probably has to tolerate this TOLUM change :-/ Thought of a few approaches but I'm not sure which is best, they mostly trade off putting more holes in the memory map versus wasting a bit of memory on buffer space: * Put the imd structures below the FSP reserved memory with some buffer space? * Put the imd structures somewhere else entirely, like toward the beginning of the available low memory instead of the end? * Ask FSP to reserve more than 8 KB for some buffer in case TOLUM changes on resume, so the imd structures are still there? I could guard any of this with a Kconfig selected only by affected boards if needed. I appreciate any input! Thanks, Jonathon

2 4

[coreboot - Bug #412] x230 reboots on suspend
by Pawel Radomychelski Nov. 6, 2023

Nov. 6, 2023

Issue #412 has been updated by Pawel Radomychelski. File dmesg_ok.txt added File dmesg_broken.txt added File .config added Hello guys! I can confirm the same Problem on my ThinkPad X230t. The first Coreboot 4.21 release: WakeUp from Standby is working fine, Actual coreboot release: Computer restart after waking up from Standby. ---------------------------------------- Bug #412: x230 reboots on suspend https://ticket.coreboot.org/issues/412#change-1690 * Author: Carson A. * Status: New * Priority: Normal * Target version: none * Start date: 2022-09-02 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/393 * Affected hardware: x230 * Affected OS: windows/arch linux ---------------------------------------- Very similar to issue 393 where the x230 reboots when suspended to RAM. Seems to be an issue with coreboot v4.16 & 4.17 or something is missing in the config (attached). Any insight on this would be appreciated! ---Files-------------------------------- coreboot_config.txt (18.8 KB) normal_boot.txt (48.1 KB) suspend_boot.txt (48 KB) 12mb_boot.txt (47.6 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) cbmem.20221019195923.normal_boot.log (36.2 KB) dmesg_ok.txt (95.3 KB) dmesg_broken.txt (93.8 KB) .config (20.5 KB) -- 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

1 0

RFC on coreboot forms representation
by Patrick Rudolph Nov. 3, 2023

Nov. 3, 2023

Hello coreboot folks, At the time of writing coreboot is lacking good firmware menus or user-space applications to change options consumed by coreboot. While there's support for changing CMOS options in SeaBIOS or from within Linux on some x86 mainboards it's quite limited in user friendliness. While CMOS was a great thing some decades ago, it cannot compete with today's flash based non-volatile option store, like UEFI variables, SMMSTORE or VPD. Our best engineers at 9elements came up with a possible solution: coreboot forms representation, see [1], [2], [3] CFR allows to have nice firmware menus in coreboot payloads as done in example for tianocore/EDK2 [5]. While it was designed with EDK2 in mind it's possible to use it on any payload with any variable store back-end (UEFI, SMMSTORE, VPD, CMOS, ...), as it's really about providing meta data about the options, not how to actually store it's value in a non-volatile fashion. The coreboot forms representation is provided to a payload in a new coreboot table and is generated at runtime by using C-style lookup tables, but in order to reduce code duplicates can be defined in common code as done in [4]. Please review and give feedback. Regards, Patrick 1: https://review.coreboot.org/c/coreboot/+/77882/ 2: https://review.coreboot.org/c/coreboot/+/74121/ 3: https://review.coreboot.org/c/coreboot/+/78506/ 4: https://review.coreboot.org/c/coreboot/+/78296/ 5: https://github.com/9elements/edk2/commit/f34f17996444ef811cc0223b4f875c45da…

3 2

Feedback wanted for coreboot website update
by Matt DeVillier Nov. 3, 2023

Nov. 3, 2023

Greetings coreboot community! One of the items to come out of OSFC and the previous leadership meeting was the need to overhaul coreboot's website to look more "professional" -- like a project which was used by commercial entities large and small, not just something for hobbyists/tinkerers. The leadership council has decided to move forward with this, and would like to hear from the coreboot community as part of developing requirements. These reqs roughly fall into 3 broad categories: logistical, aesthetic, and content. Some of the ideas been put out so far: [logistical] * Everything must be owned and run by coreboot - not an outside developer. * Everything must be contained in a git repo (outside of downloadable files like releases). * As much as possible should be generated statically? [aesthetic] * Use a site-wide top bar for navigation? (similar to https://www.zephyrproject.org) [content] * Prominent display of companies using coreboot (similar to https://go.dev) We'd love to hear from anyone else with ideas on how we can improve from the existing site. regards, Matt

8 8

2023-11-01 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org Nov. 2, 2023

Nov. 2, 2023

# 2023-11-01 - coreboot Leadership Meeting Minutes ## Attendees Julius Werner, Jonathan Hall, Tim Crawford, Jay Talbott, Matt DeVillier, Jeremy Compostella, Wilhelmina Asante, Martin Roth, Simon Glass, David Hendricks, Christian (not 9e), Jon Murphy, Werner Zeh ## Open Action Items * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * [Open] Martin: Note the slowdown of syncing the master branch to the 4.22 release notes - Updates are now weekly & branch will be removed at 4.23 release. * [Open] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * [Open] Arthur: Ask Philip about how to use company logos. *[Open] Martin: Write a document about vendorcode submodules. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * [Started] MattD and WernerZ :Work on compiling a list of website requirements from the mailing list. * No feedback yet-MattD: To continue compiling feedback list of website requirements. * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Started] Martin: Work on clang-format. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78832 for what the current format’s changes will look like. * Martin to add bitfield example to 78832 * [Done] PatrickG: Slow down the updates of the master branch. ## Minutes: ### [Martin] Thoughts on enabling shallow clones of submodules by default? * [https://git-scm.com/docs/gitmodules/2.28.0] .shallow When set to true, a clone of this submodule will be performed as a shallow clone (with a history depth of 1) unless the user explicitly asks for a non-shallow clone. * [TimC] Shallow clones means no git history. Would be good for CI and people who don’t need it. Related: Does/Can gerrit support partial clones? Treeless clones (--filter=tree:0) would be nice to have. They’re like shallow clones, but still have the git history. * [Martin] You’re spot on about not having git history in the submodules - by default. I believe you could still download the full repo manually if desired (I’ll test before implementing if the decision is to go forward with it.) I don’t see why gerrit would have a problem with it, but git submodules don’t support treeless clones, just shallow. * [MattD] Are we already using a single branch? _AI: Martin to check._ This seems like a reasonable default - need to document how to change this. * What difficulties are there with this? Will we have issues updating during a build? * Will people need to update manually if going back to an earlier commit? _AI: Martin to write docs & test_ ### [Martin] Slow down syncing of coreboot’s master branch to Daily? Weekly? * We want not using the main branch to start being a little painful, without completely breaking things yet. We’ll want to discontinue updates to master and delete it in a month or two. * [TimC] Handle it like boards/features are deprecated and do it at a release? e.g., no updates after 4.22 and removed after 4.23. * [MattD] Slow the updates down to weekly, put it in release notes that the branch will be dropped at 4.23. * [JonM] Remove documentation from the master branch and point to the main branch. * [Martin] Because of the way the branches are being synced, we can’t have any differences between the master and main branches. ** Decision: Slow down to weekly updates.** _AI: Martin: Add change from master branch to main branch to the release notes_ _AI: PGeorgi: slow down the updates to master._ ### [MattD] Requirements for new website * Everything must be owned and run by coreboot - not an outside developer. * Everything must be contained in a git repo (outside of downloadable files like releases). * As much as possible should be generated statically. * Use a site-wide top bar for navigation? * Should look like a “professional” website. _AI: MattD: Mailing list & solicit feedback from other forums. (Just continuing from previous AI)_ ### [Martin] Should we have a separate meeting to discuss coreboot RFC patches? * [https://review.coreboot.org/q/status:open+repo:coreboot+message:rfc] * [Matt] A separate meeting seems reasonable. Would we get more people if we had another meeting, or fewer? * [David] Let’s try to do it in this meeting and go over one RFC each time. If we can’t get caught up, we can have additional meetings. ** Decision: Just try to do it in the leadership meetings.** ### [Martin] Clang-format update - show the pros & cons. * [clang-format: Update configuration for version 16+] https://review.coreboot.org/c/coreboot/+/78832 * Please take a look. Pain points: - Consecutive macros: Registers with bit definitions below them typically have bits indented to group things together. clang-format currently does not recognize this and will remove indenting of macros. - Bitfield handling: Martin says recent clang-format works much better - Martin: add example to CB:78832 - Structs where each member is on its own line (for example, a struct with UART baud rates) was a problem in earlier versions as well since clang-format would aggressively join lines. Maybe this is fixed. ### [Martin] 4.22 release scheduled for 2023_11_17 * 4.22 release checklist & meeting minutes (https://docs.google.com/document/d/1jElapZVmef2H6Gxs9QzdsHiiim-OpCHP6RjsGcL…) * Release meetings run for 4 weeks starting this friday. See the coreboot calendar for details(https://coreboot.org/calendar.html). * Discussions happen on IRC in #coreboot_releases. * MattD will try to test platforms he supports before the 4.22 release. ### [Martin] RFC: util/sconfig: Add 'enable_option' keyword * This will allow a Kconfig option to be used to enable/disable a device * Do we also want a “disable_option” keyword that enables the device if it’s not set? * Should we just make a 2nd Kconfig option that’s set when the first isn’t? * [https://review.coreboot.org/c/coreboot/+/78604] * Jonathan: supports the idea. * Julius: Let’s just run it through a preprocessor and make rules about what is and isn’t allowed. This is more consistent with how we handle other files. ** Decision: Look at using the C preprocessor instead.** * Simple #defines and #if type statements - no complex macros allowed. * Look back at the discussion from last year when we had the opposite decision. _AI: Martin: Send out a separate email to the mailing list for comments from all._ ### [PatrickR] RFC on coreboot forms representation * [https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PX6W… G5S/] * [https://review.coreboot.org/c/coreboot/+/77882/] * [https://review.coreboot.org/c/coreboot/+/74121/] * [https://review.coreboot.org/c/coreboot/+/78506/] * [https://review.coreboot.org/c/coreboot/+/78296/] * [https://github.com/9elements/edk2/commit/f34f17996444ef811cc0223b4f875c45da…] * Simon: In the spirit of cross-project collaboration, would it be worth looking at how U-Boot does this? It has a schema which can be loaded at runtime, rather than needing data in the C code (https://u-boot.readthedocs.io/en/latest/develop/expo.html#expo-format-examp…) * Goal is to be able to have a setup engine. * Runtime or payload. * Would we need to implement chain loading of payloads? * Martin: 3 main objections * Change the name - Forms Representation is awful. Config Options Data, Option Data structures, Menu Option Data, anything. “Forms Representation” is totally a UEFI phrase. * Make this at build time and not runtime. * Make it easier to populate the menus from each different level - Arch, SoC, Vendor, Mainboard * Werner: Agree it doesn’t need to be run-time. * Matt: Any runtime can just update the fields in cbmem. coreboot would need to understand the data structures. * Martin: Should we set up a meeting to discuss this with 9E and interested parties in the community? # Next meeting * November 15, 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