3 ms·

Prototypes exist (eg https://github.com/pgeorgi/edk2 https://github.com/pgeorgi/edk2 or http://notabs.org/coreboot/duet-payload/ http://notabs.org/coreboot/duet

by pgeorgi 12y ago

Prototypes exist (eg https://github.com/pgeorgi/edk2 https://github.com/pgeorgi/edk2 or http://notabs.org/coreboot/duet-payload/ http://notabs.org/coreboot/duet-payload/). But UEFI just isn't that great. And when it comes to open firmware standards, why didn't Intel go with IEEE1275 but invent its own? firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard.

yuhong 12y ago
I remember reading a page that said it was because of ACPI. I will try to dig out a reference.
- pgeorgi 12y ago
  I heard that claim. I also heard the claim that it was due to Not Invented Here.
yuhong 12y ago
firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard. New Win8.x machines are required to boot using UEFI, and OF on x86 was never popular anyway. To show some of the harms this situation have caused BTW, LKML has a lot of posts about various UEFI firmware bugs, and remember that Chrome OS is based on the Linux kernel.
- pgeorgi 12y ago
  These UEFI firmware bugs are completely avoided by choosing an interface with a smaller footprint. As in: not much of an interface at all. This is what makes ChromeOS work while UEFI still fails at times. No moving parts means no worries - that's a lesson the UEFI architects never understood. So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design). And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so. Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design. UEFI is that bad.
  - yuhong 12y ago
    Yes, I know UEFI is not perfect, but the problem with PC OEMs only caring about Windows existed long before UEFI, and my point is that Chromebooks using different firmware only make the problem worse. ARM　SBSA uses UEFI and ACPI BTW even though there is no Windows Server RT.

by pgeorgi 12y ago

yuhong 12y ago

I remember reading a page that said it was because of ACPI. I will try to dig out a reference.

pgeorgi 12y ago
I heard that claim. I also heard the claim that it was due to Not Invented Here.

yuhong 12y ago

firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard. New Win8.x machines are required to boot using UEFI, and OF on x86 was never popular anyway. To show some of the harms this situation have caused BTW, LKML has a lot of posts about various UEFI firmware bugs, and remember that Chrome OS is based on the Linux kernel.

pgeorgi 12y ago
These UEFI firmware bugs are completely avoided by choosing an interface with a smaller footprint. As in: not much of an interface at all. This is what makes ChromeOS work while UEFI still fails at times. No moving parts means no worries - that's a lesson the UEFI architects never understood. So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design). And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so. Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design. UEFI is that bad.
- yuhong 12y ago
  Yes, I know UEFI is not perfect, but the problem with PC OEMs only caring about Windows existed long before UEFI, and my point is that Chromebooks using different firmware only make the problem worse. ARM　SBSA uses UEFI and ACPI BTW even though there is no Windows Server RT.