2022-03-01 - coreboot UEFI working group meeting minutes - coreboot

1 Mar 2022


      # 2022-03-01 - coreboot EFI working group meeting minutes
## Attendees:
Martin, Sheng, Daniel Maslowski, Nate Desimone, Ron Minnich, Jay
Talbott, Ahamed Husni, Matt Devillier, Sean Rhodes, Matt
Papageorge,Tim Crawford, David Hendricks
## Minutes:
* [Martinr]: This meeting has been restarted as a monthly (every 4
weeks) meeting.  If you want an invite, please add a comment to the
meeting agenda document requesting to be added.
    * Agenda/Minutes
https://docs.google.com/document/d/13RjAddskjjCGhzIwxDTE1-w6HOIwhyoZsZUIOcau...
    * Next meeting is 2022-02-29.  The schedule is posted on the
coreboot calendar. https://coreboot.org/calendar.html
* [Sheng] Need to discuss the edk2 branching plan. Had a discussion
with Intel folks to make Sean Rhodes as maintainer of
edk2uefipayloadpkg maintainer (done). Sean is uploading all coreboot
edk2 patches to EDK2 masterbranch to get merged, 9elements will follow
afterwards. Will need help to review.
    * Most of the patches in Matt’s fork are already approved.  There
are a couple of stragglers and a couple more that they don’t want.
    * How do we want to handle the EDK2 codebase going forward?  Do we
want to just use the upstream branch?
        * This should be decided by the community, probably led by Sean & Matt
        * If we do go with upstream, we should keep an older branch
around to support the older thinkpads that don’t work with the current
upstream.
        * Also, we can apply a list of coreboot-specific patches to
the upstream codebase.
* Matt DeVillier and Matt Papageorge can help review the changes.
* [Martinr] Where do we find the source for the U-Boot UEFI
implementation?  Is this it?
[https://source.denx.de/u-boot/custodians/u-boot-efi%5D(https://source.denx.d...)
    * Was the suggestion to use U-Boot as a payload with it’s UEFI code?
        * [Ron] We should look at using their code and pulling it in
so that coreboot can use it.  Very different approach - just implement
the block drivers for example, main point is they have about 12
protocols they implement, don’t need specific types, e.g. no usb block
or nvme block protocol
        * Martin - don’t want to pull it in to coreboot - want to use a payload.
            * see also 64-bit U-Boot in
[https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/coreboot/corebo...)
                “In addition to the 32-bit 'coreboot' build there is a
'coreboot64' build. This produces an image which can be booted from
coreboot (32-bit). Internally it works by using a 32-bit SPL binary to
switch to 64-bit for running U-Boot. It can be useful for running UEFI
applications, for example.”
        * Ron - Just use the U-Boot implementation as a direction that
we want to go in.  See if it can be compiled against
* Ahamed:  Gsoc project Idea
    * Hasn’t worked with UEFI. Tried running an EFI application in
coreboot/u-boot.
    * Has sent an email to the mailing list.
    * [https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/SV6XH...)
* [Sheng] Need feedback on how to move ahead with hostbridge resources
allocation in UEFI payload. Patrick has submitted a WA:
[https://github.com/9elements/edk2/commit/070ce932bdf0feb13c47bcd172c55319cef...)
    * The path forward is to report the right resources from coreboot
to edk2 payload
    * chain loading was suggested earlier, but doesn't seem to have
been worked on?
        * Could this be a GSOC project?
    * Add devicetree to CBMEM for something to parse into a format
that the UEFI payload can use?
    * Why is chain-loading needed?
        * [Martin] Maybe it isn’t.  Chain loading was suggested for
adding a parser for coreboot data and turning it into something that
can be used by the EDK2 payload.
* [Daniel] Trammell Hudson is working on Getting UEFI mapped into
linux.  Coreboot could boot into something that provides a UEFI
environment, then into linux, which could then load other operating
systems.
    * You can talk to him on the Efi boot support channel in slack.
    * [Nate] Might need to save the efi memory map so that data isn’t
lost when converting to an e820 memory map and back. Linux may rely on
GRUB doing that - so look into GRUB.