Comment by xvilka
7 years ago
UEFI is still a bad guy, because it is overengineered. And precisely because of that FastBoot mode was invented. Neither Windows, nor Linux (or whatever else) require 90% of UEFI features.
7 years ago
UEFI is still a bad guy, because it is overengineered. And precisely because of that FastBoot mode was invented. Neither Windows, nor Linux (or whatever else) require 90% of UEFI features.
FastBoot just caches a bunch of known things that your system was able to boot with and then doesn't bother re-initializing/re-training/re-discovering various bits and bobs in the hardware.
It's not taking away some 90% of what UEFI does - it's letting UEFI do its thing, writing down what was done for your hardware configuration and the location of your boot image, and then reusing exactly that again on each boot.
That's simple optimization - not a fundamental change to UEFI. Though it is good optimization which certainly could have been baked in from the start.
I never said FastBoot takes 90% away. But it is the example of how simpler things can help firmware be faster and more efficient. I have quite an experience with legacy BIOS modification and RE, UEFI modification and RE, and coreboot development. So I know what I am talking about. One more example of such overengineered thing is the ACPI standard. Especially, since 6.0 version it is tied up to UEFI. EUFI was not designed to be open anyway since it effectively hides the hardware initialization (PI stage) in binary blobs.
UEFI is a beast from the worst times of Microsoft and Intel - this is why it uses PE (Portable Executable) as a format, didn't even bother for optimization, that caused some of the vendors to invent TE format (Terse Executable), which is leaner a bit. And the code, the EDK1/EDK2 code is a perfect example of poorly-written code. Compare it to coreboot or Linux kernel codebase.