3 ms·

99% of all UEFI implementations are derived from EDK2/UDK. "official" firmware from companies like Aptio build on top of this code. Truth is, motherboard vendo

99% of all UEFI implementations are derived from EDK2/UDK. "official" firmware from companies like Aptio build on top of this code. Truth is, motherboard vendors don't have the skill set to deliver firmware. You are doing what amounts to new driver development, integration testing for drivers you get from silicon vendors (who are not really software guys either), and chasing weird bugs. When you toss in third-party drivers (eg for BMC), SMM/TZ, safe boot and update...you really need to have someone to own the entire firmware lifecycle. And this is regardless of the kind of firmware - uboot, uefi, coreboot or bios, it doesn't matter. Of course I make it sound like companies like Award and AMI ship great solutions. No one does, but OEM and silicon vendor-shipped firmware is much, much worse in quality. Oh, and UEFI and the reference inplementation Tiano Core (edk2) are exactly Intel's own firmware, no more no less. It now has more of a life of its own ever since it became UEFI (from EFI), and even supports ARM platforms, but a) majority of development is still intel b) edk2 would like to be platform agnostic, but the design of some components (of edk2, not uefi spec) like PCI support is very PC-centric and this will be painful until someone rewrites these and contributes back to Tiano.

derefr 9y ago
> you really need to have someone to own the entire firmware lifecycle Which is, in my mind, why having “internal clients” for your hardware in the form of a firmware department would make so much sense to me. Especially if the firmware team had ultimate authority over hardware edge-case behaviour: instead of hardware teams being lazy and passing the buck for “sanding off the edges” to complex firmware, the firmware team could be lazy and force the hardware teams to “sand off the edges” themselves. This is what you see in (some) old-school videogame console companies, at the time when the ISA was the API: since the hardware company also developed the SDK, various BIOSes, and even games, the needs of these internal clients pushed the hardware teams into making the hardware itself “user-friendly” (i.e. obeying the Principle if Least Surprise.)

derefr 9y ago

> you really need to have someone to own the entire firmware lifecycle Which is, in my mind, why having “internal clients” for your hardware in the form of a firmware department would make so much sense to me. Especially if the firmware team had ultimate authority over hardware edge-case behaviour: instead of hardware teams being lazy and passing the buck for “sanding off the edges” to complex firmware, the firmware team could be lazy and force the hardware teams to “sand off the edges” themselves. This is what you see in (some) old-school videogame console companies, at the time when the ISA was the API: since the hardware company also developed the SDK, various BIOSes, and even games, the needs of these internal clients pushed the hardware teams into making the hardware itself “user-friendly” (i.e. obeying the Principle if Least Surprise.)