# 9 November 2021 - coreboot EFI working group
Attendees: Martin Roth, Felix Held, Michael Niewöhner, Matt DeVillier, Nate DeSimone, Patrick Georgi, Tim Crawford, Werner Zeh
## Agenda:
* [Edward] Supporting some UEFI interfaces continues to be a hot topic, one such area is ESRT table ASL generation within coreboot to better support platform firmware topology descriptions up the stack. quasisec@ is working on a proposal in the not so distant future.
* [Patrick] It looks like the push to require linux to use EFI is coming from the “Universal” Scalable Firmware project. * [UniversalScalableFirmware/linuxpayload](https://github.com/UniversalScalableFirmware/linuxpayload) https://github.com/UniversalScalableFirmware/linuxpayload](https://github.com/UniversalScalableFirmware/linuxpayload) * [David] I think this has more to do with distros and OEMs expecting them for their manufacturing and testing purposes, for example [ubuntu-bios-uefi-requirements](https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf) https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf) * 9.1. Legacy BIOS compatibility Ubuntu has been tested with UEFI-only mode BIOS and is also known to work with legacy BIOS compatibility mode (known as a Compatibility Support Module, or “CSM”) enabled. However, enabling legacy support will affect secure boot functionality, because it needs native-UEFI drivers and to be signed for validation during booting up * This looks like Intel trying to shape the future of firmware to suit their needs instead of coreboot's needs. * Are there any distros other than Ubunty looking at requiring UEFI? * [Nate] I believe these requirements are straight from Linux kernel. * [Patrick] In that case, they're probably an addition, not replacing the existing boot procedures. * Chip-agnostic loading would require this. * Someone from ARM proposing it. * [Nate] Linux is using EFI boot services to provide a more architecture agnostic Linux kernel launch [arch-agnostic initrd loading method for EFI systems](https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.la...) https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f](https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f) * What boot parameters are still actually used? Need to go through the kernel source to find out. (that’s what Patrick G did when building the linux trampoline in cbfstool) * Supports native X64 launch.
* Matt could use additional reviewers on his patches. Initial patches were simple, but the later patches could definitely use more reviewers. The concern is that there are probably better ways to do these later patches. If they don’t get reviewed, they’ll be merged regardless so that we have a working branch, but it would be better if reviewed and reworked as needed. [edk2 project search](https://review.coreboot.org/q/project:edk2) https://review.coreboot.org/q/project:edk2](https://review.coreboot.org/q/project:edk2)
* [Martin] Yabits tested, and as previously reported is not currently working. More testing and debug is needed. * Nate: It looks like there are a number of fundamental issues with yabits, so the U-Boot implementation might be a better choice as a 2nd implementation. There were rumors about that version being dead, or having been canceled, but it looks like patches are still being merged.
* [Martin] Documentation about coreboot’s EFI plans is started and will be shared before the next meeting.
* Jitsi performed very well compared to all of the other open source solutions that we’ve used. The only issue is a lack of call-in numbers. Patrick will look at setting up a server to test more.