To facilitate cooperation on UEFI-as-a-payload work, we established a mirror of tianocore's edk2 repo at https://review.coreboot.org/edk2. Unlike other mirrors on review.coreboot.org, it's open for development.

It's updated regularly, but the default branch that we set up, coreboot-stable202108, is based on edk2-stable202108, so there won't be changes flowing in automatically to the branch we will focus on.

We will set up builders on qa.coreboot.org to cover that repo, so we get the same "at the very least, it builds" guarantees that we have for any coreboot contributions. Maybe we'll even get boot tests in the future, who knows?

If you want to make coreboot+edk2 a viable option for starting hardware (with the bonus compared to "regular" edk2 flows that hardware init happens on the coreboot side, so if you want the same hardware to boot differently, it can easily be made to be coreboot+SomethingElse!), there's plenty of opportunities for developers.

Matt DeVillier (Mr. Chromebox) offered to push his patch train there which (as I understand it) is an amalgamation of changes made in various edk2 forks in the coreboot ecosystem.

Something people have talked about is adding Microsoft's Project Mu (https://microsoft.github.io/mu/) UI improvements to tianocore-as-a-payload, which could find a good home there, as well.

Finally, SMMSTORE: it exists, it helps where it is supported to persist UEFI variables, but as I understand it, actual support for devices is rather limited.

Making coreboot+edk2 the premier option for booting UEFI platforms would give the rest of us something to work with that is more pleasant than trying to NERF vendor firmware until it stops doing all the things we don't need it to do.

And if you don't care about UEFI (or if that's putting it mildly, even), don't worry: this is only a payload. Just like we have FILO on our server or SeaBIOS or depthcharge, this is just another option. But given the market penetration of UEFI interfaces, it's an important one to get right.

Patrick