# 12 October 2021 - coreboot EFI working group
## 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.
## Decisions:
* The coreboot repo will host an EDK2 fork for use as a coreboot payload. Commits to this repo will go through gerrit for review. * Any code needed to support booting should go into a payload instead of coreboot itself. * We will look at adding chain-loading payload support to coreboot. Among other things, this will allow a payload to support turning cbmem tables into UEFI HOBs as needed before calling into a UEFI support payload.
## Minutes:
* Can you access the VC ? [Chris] * 9 people in. Apparently Chrome + Web or using the apps work for some people, but not for others. * Native [Bluejeans] apps * We’ll try a different method for our next meeting - The method will be announced after we decide when to hold our next meeting. * FelixH: this isn’t a job for coreboot. * This should definitely be in a payload. * If FSP settings need to be configured, this would be a problem. * How would we support boot variables? Or would we? * Werner: Agree with keeping this in a payload. * [pgeorgi] What’s the scope of this project? * Just booting? * Jay: Syspro is typically asked to create solutions that are NOT UEFI. They want simplicity and boot code to do the minimal amount. * 9elements: customers are mostly desiring UEFI boot solutions * coreboot need additional tables in cbmem to support a better UEFI implementation. * What’s the timeline? * When will we NEED to support the EFI interfaces? * Do we know what these interfaces will be? * Initially just boot services. * Is there any advantage to pulling EFI into coreboot. * No? Having chainloading payloads could handle any translation necessary without tying that to a specific payload. (ie. coreboot loads the cbmem2hob payload, which does its thing, then cbmem2hob loads the actual payload) * Look into chain-loading payloads: pgeorgi will look into this. Proof of concept: move splashscreen support out of ramstage. * Add an edk2 fork to the coreboot git server * Where do we start from? * Current EDK2 stable from August 2021. * https://review.coreboot.org/edk2.git is now mirrored from https://github.com/tianocore/edk2 * Updated hourly * Our own stable tag is default: coreboot-stable202108, based off edk2-stable202108 * How do we pull changes from EDK2 * Create upstream branch to pull in changes? The vast majority of changes will come into this branch, and someone would need to sort them out at some point. * What’s the volume of patches that come into the EDK2? That has a big impact to how we address this: * About 5 patches a day. * checked again: there are ~6000 commits between 2020-09-20 and 2021-09-20 on edk2/master, so more like 20 commits a day * Can we just create a fork and add things on top, or is there a better way to start? * Matt currently just creates his fork for the chromebook firmwares that he maintains. * How do we push changes back to EDK2? * This is a big issue - this is why many of the forks were created. * What’s the volume of our changes that would go into this tree? * How do we want to handle commits? * Are there enough people to do real code reviews? * Let’s just start by pushing through gerrit. * What other more minimal projects are we interested in pulling in as payloads? * Yabits, Voodoo, U-Boot’s codebase? * Yabits did not work the last time it was (minimally tested) * Tianocore is currently not very well featured. * There are definitely situations currently where a uefi-payload is needed, so if there were something that provided a UEFI interface without all of the associated overhead, that would be very useful. * Everyone has different ideas about what’s needed as a minimal solution. * Voodoo is trying to get away from running all of this code in ring0. * No serious discussion about building anything new from scratch at this point, but that’s obviously not out of the question if someone wanted to start a new project. * Definitely no one-size fits all solution here * AI: Need to find out what linux is going to need. * Is this just what’s required for grub, or by linux itself - those are different things. * May be useful to have multiple implementations to find where the gaps are. * Any maintained implementations are welcome on review.coreboot.org! (no graveyard for yabits unless you start working on it) * Figure out boot services profile for linux as a payload * AI: look at what grub needs * Note that there is "grub as a payload" * UEFI spec is closed source * This would need to be addressed by the UEFI Forum board of directors. * Nate will pass along the request to make this open source. * What counts as working? * Will definitely set up build testing * Can 9elements help any with testing for their purposes at least. * 9elements will definitely test, but can’t say at this point how it will look. * Created edk2 repo: * Matt to start pushing patches. * Martin to set up build testers. * Discuss whether we need another meeting on the 26th at next week’s leadership meeting.
## Agenda & random notes below.
* How do we approach this without turning coreboot into UEFI. 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. * Extend [Yabits]? This hasn’t had any new commits in over 3 years. It also leverages libpayload which is not so much alive either these days. * Through depthcharge, libpayload is probably the most exercised payload code you'll find these days that isn't a Linux kernel. * Fork EDK2 * There are already many private forks. It would be useful to have a central location to merge these. There is a worry about who will review the patches. I don’t think we want everyone on the internet to be able to submit and merge patches, so we probably want to create a group who can merge them. * Set up a jenkins builder * What codebase do we start with? * Extend Ron’s [Voodoo] project * This is now passing one of the tests from u-boot efi_selftest * Port to arm in progress * Write something from scratch * Add code to coreboot to create HOB structures and other requirements. * This was the initial suggestion that was proposed in the coreboot meeting last week. * Pull in u-boot’s UEFI implementation * How much of the [UEFI spec] is needed? * ARM has a [trimmed down UEFI spec]. Can a similar one be made for x86? * Boot services * Runtime services * Secure boot * Boot Variables * User identification? * Apparently EBBR requires mass storage as part of the spec, so more a payload matter
[Bluejeans]: https://www.bluejeans.com/downloads [UEFI spec]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf [Yabits]: https://github.com/yabits/uefi [Voodoo]: https://github.com/linuxboot/voodoo [trimmed down UEFI spec]: https://arm-software.github.io/ebbr/