coreboot

coreboot@coreboot.org

6 participants
39686 discussions

coreboot Leadership Meeting Minutes
by mina＠coreboot.org 16 Nov '23

16 Nov '23

# 2023-11-15 - coreboot Leadership Meeting ## Attendees Martin Roth, Wilhelmina Asante, Matt DeVillier, Maximilian Brune, Tim Crawford, Felix Held, Julius Werner, Jonathan Hall, Nico Huber, Jeremy Compostella , Karthik Ramasubramanian, Felix Singer, Benjamin Doron, David Hendricks, Sergio Moreira, Solomon Alan-Dei, Simon Glass, Lean Sheng Tan. ## Open Action Items * 2023-11-15 * [Open] Martin: Publish coreboot FAQ * [Open] 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. * 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. * [On hold pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * 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] 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. * FelixH: Maybe move the freeze to tuesday? No strong feelings. * Nico: I don’t know that this will really help - Things addressed in the meeting still can’t be discussed on the mailing list. Proposal might help but can also slow things down. * FelixS: Leadership meeting could just become the discussion channel. The meeting shouldn’t be the first place to announce an issue. People should start discussions with a new thread for every issue. * Martin: Do we really need separate email threads about every issue? Can people not read and respond to the agenda? * FelixS: The actual content is hidden in the agenda. Having a separate thread gets people more involved. * FelixH: Agenda being sent out is a huge improvement over what we had before. Not a fan of mailing lists. * Sheng: Agree with not forcing people to write threads - some people prefer talking over writing to the mailing list. * FelixS: Not trying to force anything, but the mailing list reaches more people. * FelixH: The leadership meeting allows people to contribute more easily. * DavidH: We should take input in multiple forms for controversial decisions. Not everything needs to be discussed. We already generally ask to spawn a thread on the mailing list for controversial issues. **Decision: Let’s try the original plan as Martin proposed for now - If there are any decisions that should have been made on the mailing list, please let us know. If there are any issues that need to be worked out, we can look at how the plan needs to be modified.** ### [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. **Decision: No objections, tentatively approved. If there are any objections, please email David, Matt or Werner before Friday.** ### [Martin] coreboot 4.22 to be released this friday. * Felix will send out another email. ### [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. Current number is meaningless. - Matches us up with linux distros. **Decision: We will change the format - Martin to announce in release notes.** ### [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 initialize 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. * Allows enablement of secureboot. * Considered just using smm store as it is - but this just submits the write. Downside can call the SMI. * Considered bringing the entire variable stack into coreboot. EEK! * Following what intel is doing for UPL, enabling payload to install SMM - takes care of its own variable stack. * Don’t init SMM on cold boot. * Passes data in cb tables - (fairly) silicon agnostic (intel specific). - not strictly required) * Can Payload init SMM on its own? * On S3 resume, payload isn’t on resume path. Coreboot would take data saved and trigger an SMI from coreboot so we can continue. * Dammit, looks something like UEFI - just because that’s what’s currently supported - any other solution would need to do something similar. * FelixH: On the AMD SOCs - SOC specific in SMI handler. How would these hook into the payload handler? The payload would need to know about the specifics. Solves one problem, but creates other issues. Makes payload non-hardware agnostic. * Benjamin: User can decide to include and support secureboot or not. Open source currently. * Martin: What prevents hardware vendors from forcing the inclusion of closed source binaries to support their hardware? * Benjamin: Nothing - but the person doing the compile gets to decide. * Sheng: Huge security impact. Currently we can’t do any secureboot. coreboot currently has no way to handle this currently. * Nico: Any other solution would do something similar - is this actually true? We have vboot that does things differently. Have you considered not doing things with SMM. * Benjamin: Vboot covers the boot path, doesn’t cover the final bootloader. * Nico: true, but it could verify the variables when they’re consumed. * Benjamin: The problem is that smm store can’t prevent people from writing. * Nico: If you don’t use SMMstore, there are other possibilities. * Benjamin: can’t call back into vboot * Nico: why would you need to? * Benjamin: Take the concept of vboot and put it into libpayload & the payload. * MattD: What about the effort to share smm between vboot & payload? Can that address some of these issues? * Benjamin: The concerns are more about licensing. About 2 big steps away from being able to test sharing. ### [Martin] Plans for the 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. * MattD: Would be good to have 3-5 big scope items for each release. ### [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 * Can probably drop this for now? * 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. * MattD:Can gather more engagement with support for more popular languages. * MaxB:Is this just about tooling or actually adding code? * MartinR:Toolchain for now, but this would start the direction of accepting rust. *MaxB: How would it look to start adding rust code? * FelixH - doing the SMI handler in rust would be interesting. * Nico: On the matter of integrating different languages - looked at it with ADA, same applies to rust. Would need good interface code. We’d need to create bindings for rust - then we could start creating things like drivers. * Benjamin: Would this be a maintenance issue? Would we need strict rules around languages for specific areas to allow for maintainers for each of the areas? * FelixH: Can we just start with tooling and payloads and see how it goes? ### [Sheng] Winter Hackathon hosted by 9E * November 17th - 19th * So far, ~35 people are planning on attending. * (https://opensourcefirmware.foundation/events/osff-fall-hackathon-2023/) ### [Martin] Fosdem: Open Source Firmware, BMC and Bootloader Room * Call for participation * (https://lists.fosdem.org/pipermail/fosdem/2023q4/003524.html) * Submission Deadline: 11-Dec-2023 @ 23:59:59 UTC * Acceptance Notification: 13-Dec-2023 * Final Schedule Posted: 15-Dec-2023 ### [Martin] Syspro servers here, but not set up yet * These will be used for non-critical builds. * Need help setting up BSD server. ## Closed action items * [Done] 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. * [Done] PatrickG: Slow down the updates of the master branch. * [Done] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * FelixH don’t use a preprocessor. * What problem are we trying to solve? If just adding Kconfig then preprocessor opens up too much. * Julius - Macros are easier to write - sconfig is hard to learn. # 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

Boot time optimization on a CMOS battery less hardware platform
by Moorthi M.s 16 Nov '23

16 Nov '23

Hi, I am developing coreboot along with Uefipayload for a custom board derived from CFL H RVP11 CRB. Modifications are done as per the custom board and the board was booted and working fine. Without CMOS battery, the board takes around 28 seconds for booting and it goes through 2 resets. But with CMOS battery, it takes only 15 seconds for booting and it skips the FSPS reset. Is there any method available in coreboot to reduce the boot time to 15 seconds same as with CMOS battery configuration on a CMOS battery less (without CMOS battery) hardware platform? Thanks & Regards, Moorthi S

1 0

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

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