Hi everybody,
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
thanks for getting this set up Patrick!
On Tue, Oct 12, 2021 at 1:10 PM Patrick Georgi via coreboot coreboot@coreboot.org wrote:
Hi everybody,
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.
SMMSTORE_V2 is fully working with the current coreboot default option for Tianocore (UEFIPAYLOAD), and is selected by default. It should work on all boards for which the default Tianocore option does; currently it persists most (all?) EFI variables, including the boot order entries. Most of the credit for this goes to the fine folks at 9elements.
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
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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.
SMMSTORE_V2 is fully working with the current coreboot default option for Tianocore (UEFIPAYLOAD), and is selected by default.
We are still using v1, but I want to switch us to v2 on our next edk2 update. My only concern is migrating the store from the v1 to the v2 format (or rather, the format edk2 writes when using v2). I was planning on doing it in our firmware-smmstore UEFI app, but if anyone else would need this functionality it would probably be better to add it somewhere in BlSMMStore.
I will rebase our changes on Matt's branch to see how many our fork still needs, probably some time next week.
-
Matt DeVillier -
Patrick Georgi -
Tim Crawford