coreboot

coreboot@coreboot.org

17 participants
39654 discussions

coreboot 4.22 release tag is ~2 weeks ahead!
by Felix Singer 16 Nov '23

16 Nov '23

Hi coreboot fellows, the coreboot 4.22 release tag is scheduled for November 17th. It's about two weeks ahead and we just started with the release process. As always, please test any mainboards, give feedback, and if possible submit a patch for review if you found an issue. We appreciate any help. Also, let us know if there are any patches which need to make it into the release. You can do that by responding to this email and by adding the following hashtag to the related patch on Gerrit. The hashtag field is shown after clicking on the "show all" button from the top left information block of a patch. coreboot_release_4.22 [1] From this release on, we are using another hashtag in order to track patches which are important or useful in some way, maybe even ready to be submitted, but might break something and thus the risk is too high right before the release. So we prefer to submit them after the release which gives enough time for testing until the next release. Examples are version updates to the toolchain or updates to the FSP submodule pointer. The hashtag is as follows: coreboot_post_release_4.22 [2] If you have any questions, please don't hesitate and reach out to us. Thank you all. Felix --- [1] https://review.coreboot.org/q/hashtag:coreboot_release_4.22 [2] https://review.coreboot.org/q/hashtag:coreboot_post_release_4.22

1 1

Getting FSPM XIP base does not match Error, after flashing the fspm stitched Coreboot
by Sameeruddin Shaik 15 Nov '23

15 Nov '23

hi , I am trying to stitch the fspm.bin binary in the coreboot file by using the below steps. *sudo cbfstool "${IMAGE}" remove -r FW_MAIN_A -n fspm.binsudo cbfstool "${IMAGE}" remove -r FW_MAIN_B -n fspm.binsudo cbfstool "${IMAGE}" remove -n fspm.binsudo cbfstool "${IMAGE}" expand -r FW_MAIN_Asudo cbfstool "${IMAGE}" expand -r FW_MAIN_Bsudo cbfstool "${IMAGE}" add -t fsp -r FW_MAIN_A --xip -n fspm.bin -f "${FSPM}"sudo cbfstool "${IMAGE}" add -t fsp -r FW_MAIN_B --xip -n fspm.bin -f "${FSPM}"* *sudo cbfstool "${IMAGE}" add -t fsp --xip -n fspm.bin -f "${FSPM}"* After stitching fspm.bin binary file in the coreboot file. i flashed the coreboot , its failing to boot and stuck at the below error. *CBFS: Found 'fspm.bin' @0xc3fc0 size 0xd0000 in mcache @0xfef87804FSPM XIP base does not match: 0x00510000 vs 0xf95d3fe4* I can be able to stitch the fspm.bin at the correct offset in the CBFS, but i can't update the fspm XIP Any help is much appreciated. Thanks in advance --sameer.

3 6

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 15 Nov '23

15 Nov '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1524317: Uninitialized variables (UNINIT) /src/northbridge/intel/sandybridge/raminit_mrc.c: 332 in spd_fill_pei_data() ________________________________________________________________________________________________________ *** CID 1524317: Uninitialized variables (UNINIT) /src/northbridge/intel/sandybridge/raminit_mrc.c: 332 in spd_fill_pei_data() 326 } else { 327 /* MRC expects left-aligned SMBus addresses. */ 328 pei_data->spd_addresses[i] = spdi.addresses[i] << 1; 329 } 330 } 331 /* Copy SPD data from CBFS for on-board memory */ >>> CID 1524317: Uninitialized variables (UNINIT) >>> Using uninitialized value "have_memory_down". 332 if (have_memory_down) { 333 printk(BIOS_DEBUG, "SPD index %d\n", spdi.spd_index); 334 335 size_t spd_file_len; 336 uint8_t *spd_file = cbfs_map("spd.bin", &spd_file_len); 337 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

coreboot Meetings Annoucement And Agenda Call
by mina＠coreboot.org 13 Nov '23

13 Nov '23

Dear coreboot community, Kindly note that the coreboot leadership meeting is scheduled for Wednesday, November 15, 2023 [1]. You are welcome to add things you wish to see addressed during the meeting to the agenda [2]. ## Current Agenda Items ### [Martin] Proposal: Agenda items needing a decision must be on the agenda by the time it’s sent to the mailing list on Monday. * To give everyone a chance to participate in the decisions being made, we should make sure that all agenda contains all items being discussed well ahead of time. I’d propose that we send out an initial agenda calling for any additional items on the Friday before the meeting, then an updated, final agenda on the Monday before the meeting. (Thank you Mina!) We encourage people to update the agenda document before the meeting with any thoughts they have before the meeting, whether or not they can actually attend the meeting. Posting responses to the mailing list for the agenda items should also be acceptable - those responses can be collected into the meeting minutes, at least with a summary and a link. ### [Martin] I’d like to nominate Jérémy Compostella for core developer status. * Jeremy’s first patch at coreboot was in September of 2016, and he’s definitely done a lot more recently. CB:16524 He’s volunteered as *the* maintainer for the x86 platform code - no simple task. He’s shown himself to be extremely capable both in his reviews and in his own patches. Statistics as of 2023_11_08 - 81 Patches, 93 Reviews, 41 Comments ### [Martin] coreboot 4.22 released this friday. ### [Martin] Change the coreboot versioning from 4.xx to year.month format? * We’d note this in the 4.22 release notes, and the next release would be 24.02. ### [Benjamin] Add support for calling SMM payloads * To support UEFI secure boot effectively, we need to perform the verification and SPI write steps of its variables together, in SMM. Consequently, we need the payload to initialise SMM, and on S3 resume, to relocate these SMBASEs (because the payload is not on the boot path). We would like approval for this use-case. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific (other potential payloads must have similar design), and contains nothing specific to secure boot. We are also pursuing future work to share SMM between coreboot and the payload. ### [Arthur] [A new bootflow on ARM64 server using more of TF-A](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/threa… BAIMXUWM/) - 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? ### [Martin] Localization of non-console strings for coreboot * With the addition of 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? ### [Martin] Plans for the 4.23 (or 24.02) release * We’d like to start creating and announcing plans for upcoming releases that the entire project can work toward. These can be maintenance, new features, documentation goals, or hopefully some of each. -[Maintenance] Chipset device trees for all SOCs. ### [Martin] Look at adding Go and Rust to the toolchain * Go: We’re already using tools 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. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

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

10 Nov '23

Dear Community, We are happy to announce the upcoming coreboot leadership meeting is scheduled for November 15, 2023. [1] Kindly update the current agenda items with things you wish to see addressed during the meeting.[2] [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… j6ljr2742djc

1 0

RFC: Proposal for Devicetree.cb & the C preprocessor
by Martin Roth 09 Nov '23

09 Nov '23

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 08 Nov '23

08 Nov '23

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 08 Nov '23

08 Nov '23

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 08 Nov '23

08 Nov '23

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 06 Nov '23

06 Nov '23

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot