As someone who doesn't know what Coreboot does, not having this information in the first paragraph of this post isn't super useful. Add to the problem that clicking on the Coreboot logo only takes me to the front page of the blog - and there are no links to the actual homepage...
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
https://coreboot.org/
Which means nothing other than its open source and doesn't follow any standards.
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.
Yes I know it can "chainload" edk, people have done similar things with uboot in the past. The point being that the low level init code could conform to the PE spec, which would be a lot cleaner implementation.
> The point being that the low level init code could conform to the PE spec
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."
? Which of those aren't provided by edk2? Have you see how fast it is on small embedded boards? Its basically instant boot the same way as uboot is, it also supports the secure boot standard, capsule update, and most of what one expects out of a modern BIOS.
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.
No, my argument was that the description was market-speak and doesn't actually tell you anything useful. Faster than what? More secure than what, how? Its not class leading in either of those cases.
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.
> Its basically instant boot the same way as uboot is
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.
The edk2 project is a branch of edk, which itself is a branch. According to their about page the original tiano project was started in 2004 as the opensource fork of intel's internal uefi implementation. This did create some problems early on, but the code is basically BSD licensed at this point since AFAIK, they are dropping the bsd+patent restriction. So technically you could probably work on it without ever looking at the UEFI specifications these days as much of the platform code/etc is actually in a different repo. Given that its mostly a plugin API that isn't really a problem, its a matter of flipping a few switches in the config files to enable functionality on top of whatever platform init is necessary.
I might be able to work on it (and indeed, I sometimes do), but your argument was in favor of implementing a spec.
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"?
