# 26 October 2021 - coreboot EFI working group
It looks like the push to require linux to use EFI is coming from the Universal Scalable Firmware project. [https://github.com/UniversalScalableFirmware/linuxpayload%5D(https://github....)
It might be good if coreboot contributors helped drive those decisions.
## Objective: Linux is expecting more and more to use EFI supplied interfaces (UEFI Boot Services in particular, even if many are stubbed out) so like it or not, we’re going to need to support these interfaces. How do we approach this without turning coreboot into UEFI.
## AIs: * Matt to push his EDK2 patches * Matt look at re-implementing coreboot payload package * Martin to write some initial eocumentationDocumentation
## Agenda & Minutes * We have the coreboot EFI fork up: [https://review.coreboot.org/edk2.git%5D(https://review.coreboot.org/edk2.git) * Jenkins builder is up: [https://qa.coreboot.org/job/edk2-gerrit/%5D(https://qa.coreboot.org/job/edk2...) * Final patch for build was merged: [https://review.coreboot.org/c/edk2/+/58497%5D(https://review.coreboot.org/c/...)
* What next with EDK2? * Matt to push his patches from his current fork and clean them up. * Expect discussions on the patches about the best ways to do things. * Pulled patches from system76 & 9elements branches. * 9Elements - no definite timeline for pushing their patches. Currently having a logging issue. Mostly fixes. * Major feature implementation next year. Not sure yet how that will be handled. * Do we need to create branches? * 3mdeb, system76 & 9elements have other branches.
* Documentation? * Any volunteers? Martin will write up some documentation to review. * What are we doing here? * How does this differ from the upstream EDK2?
* Would like to avoid EFIisms in coreboot itself, so we are offloading it to the payload.
* Is the EDK2 our preference for now? * Nobody stated a preference, but we'd like to make sure that any changes do not limit coreboot to only using the EDK2.
* FSP has an issue with console output and timestamps - how to address this? * If we add an interface for the FSP, there are issues with linking. * AMD already handles this and passes coreboot compatible console and timestamps.
* Payload chain loaders - turn cbmem into HOBs * Why not just put these into EDK2 * Let’s not limit ourselves to EDK2
* Sandy/ivy bridge platforms are having problems with the latest edk2 * Do we need to bring back the coreboot payload package as a separate implementation until this is fixed? * Separate payload or just update makefile? Matt will look into it initially.
* Philipp is interested in working on a Rust-based payload for EFI compatibility. * Working on proof of concept payload
* Look at adding Rust to coreboot toolchain at some point * System76 is also using Rust to build binaries that are getting added to the firmware separately.
* Additional references for minimal EFI interfaces: * [https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf%5D(https://odm...) (chapter 9) * [https://arm-software.github.io/ebbr/index.html#document-chapter2-uefi%5D(htt...) * [https://developer.arm.com/documentation/den0044/latest%5D(https://developer....) (Appendix C) * [https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requi...) \
coreboot org wrote:
It looks like the push to require linux to use EFI is coming from the Universal Scalable Firmware project. [https://github.com/UniversalScalableFirmware/linuxpayload]
Thanks for the link! I didn't know about USF and found a good project overview linked from https://github.com/UniversalScalableFirmware :
https://github.com/UniversalScalableFirmware/Introduction/blob/main/USF_Over...
The last page has a good diagram of the USF vision showing coreboot positioned next to tianocore, slimboot and U-Boot while also showing that these are all rather small pieces and, crucially, that Intel will of course not accept anything but theirs as the overarching concept - one where ACPI, binary configuration through YAML (funny oxymoron!) and FSP are key features, with benefits such as minimized need for source code manipulation.
To me, this is sadly as unsurprising as it is disgusting.
It might be good if coreboot contributors helped drive those decisions.
That seems a fool's errand to me, but power to you if you try.
Kind regards
//Peter