# 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/[email protected]/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f)
 
<https://lore.kernel.org/linux-efi/[email protected]/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f](https://lore.kernel.org/linux-efi/[email protected]/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.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to