4 ms·

? 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 sup

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

nickik 7y ago
> ? Which of those aren't provided by edk2? 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.
- StillBored 7y ago
  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.
pgeorgi 7y ago
> 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. From my perspective EDK2 is the also-ran.
- StillBored 7y ago
  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. https://www.tianocore.org/ https://www.tianocore.org/
  - pgeorgi 7y ago
    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"?

nickik 7y ago

> ? Which of those aren't provided by edk2? 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.

StillBored 7y ago
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.

pgeorgi 7y ago

> 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. From my perspective EDK2 is the also-ran.

StillBored 7y ago
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. https://www.tianocore.org/ https://www.tianocore.org/
- pgeorgi 7y ago
  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"?