# 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.