If google put 1/2 the effort into edk2 the world would be a lot closer to a general purpose opensource firmware that actually works with things like option roms, and booting on random boards instead of some tiny subset of boards that google has beaten people into porting it onto.
I think you missed the first sentence.
So, yah, if you turn on boot debugging, and enable a pile of drivers for USB/PCIe/etc it gets slower because it can actually probe and boot from random USB & PCIe devices, and display a graphical boot menu using a random GPU. Still, the longest delay tends to be the boot prompt sleep/delay which can be shortened/removed.
What does that have to do with anything?
Your argument was that the description was not descriptive but it was. So your point was wrong and made no sense.
Then you start ranting about coreboot. So clearly your argument was not about the description, you just wanted to shit on coreboot.
And just btw, building a whole new OS to put under your OS is nonsense from pretty much every perspective.
Further the project is yet another CADT model project which further fragments a problematic portion of the ecosystem while bringing little to the table technically.
And while I picked edk2/uefi, there are a dozen other firmware projects including one that actually does put a full blown OS in the firmware. So, if your augment is trying to be technical by saying edk2 does to much, that doesn't address boot loaders like uboot, while simultaneously failing to understand the why's of standardized boot-loaders.
We regularly run into issues where coreboot boots so fast that the peripherals can't catch up and we're the first to notice. So yes, our boot process is pretty quick compared to other stuff.
> it also supports the secure boot standard, capsule update, and most of what one expects out of a modern BIOS.
Absence of runtime services (while still doing a secure boot flow and firmware updates). UEFI doesn't do that.
Also, coreboot provides these things since ~2005 (the verified boot flow was a bit late) while EDK2 started out around 2007 and only gained secure boot in 2012.
From my perspective EDK2 is the also-ran.
Any change that modifies the resulting binary might have my copy deviate from the spec and I have little way of knowing. How useful is that when trying to "implement PEI"?
Coreboot is actually the easiest way to get pure EDK2 (without anything from vendor UEFI builds) running on any random Intel mainboard :)
The spec that is available under "read only, but don't implement" terms[0] unless you manage to join a club that may or may not let you in[1] and can kick you out at any time with 30 days notice[2]? Not sure that's a good base for an open source project.
[0] https://uefi.org/specifications "By downloading any of the UEFI Specifications, you acknowledge that no license, express or implied, is granted to you to distribute, additionally reproduce, implement or otherwise use for any purpose (other than to read only) the UEFI Specifications"
[1] Section 2.1 in the "UEFI Adopter's Agreement" (https://uefi.org/sites/default/files/resources/UEFI_Adopters...): "This Agreement shall become effective only: (a) if executed by the Secretary (or another authorized representative of the Forum) and the Adopter"
[2] Section 2.2 of the same agreement: "shall continue until [...] terminated by either the Forum or the Adopter on 30 days’ written notice."