UEFI Programming – First Steps (2009) | Hacker News Reader

UEFI Programming – First Steps (2009)

x86asm.net

120 pointskqr218 comments

I've worked on non-trivial UEFI stuff, and the main problem I had was achieving a state outside of the UEFI. IIRC I had problems EFI malloc'ing / free'ing memory, because some UEFI bioses require a double free, or something. It's about a year ago.

UEFI is a documented minefield, where the Specs are badly-followed when you hit actual implementations.

The term used to describe it to me was "shit show" which seems to be in line with your experience. "Glorified Legacy BIOS loader" was another term used.

I don't like to be so negative but UEFI feels like a step backwards.

It would have been a huge step forward but they allowed for backward compatibility by permitting BIOS modules. So instead of using the new system, vendors just use it to load legacy BIOS modules.

Apple is the only one not doing that.

Yep, this talks about EDK1-based development. These days, you can also build Tiano Core EDK2 on Unix-like systems with GCC, and target Arm and AArch64. Like the EDK, there is still an Nt32 simulation target. Unlike EDK, EDK2 has real buildable firmware for Qemu, KVM and XEN and a simulation envo for Linux and OSX.

Probably should avoid developing under the old EDK, as the libraries and build system jave somewhat changed (yes, there is a compat package for mastodonts, but, just don't).

Why do third-party BIOS vendors exist in the first place? Any reason why Intel, AMD and the motherboard vendors can't make their own BIOS, perhaps leveraging CoreBoot?

It dates back to the 1980s when the IBM PC BIOS has to be reverse engineered, though even Open Firmware used to have several vendors.

Some motherboard vendors do make their own. I've seen a few Intel boards sporting an EDK2 derivative. The IBVs basically exist to take the hassle out of UEFI development for the hardware vendors. It's a very convoluted spec, and integrating all of the different parts is a very daunting project that most OEMs would just rather not bother with.

My guess: It’s cheaper and not every motherboard is the same. Some have features added by the manufacturer such as Aura RGB

In many ways UEFI on x86 resulted in a loss of firmware talent across the board since all OEMs were basically doing is selling Intel reference platforms, with Intel's UEFI drivers for everything on top of a "proprietary" firmware that amounts to Intel's reference (edk2) and maybe some buggy useless customization on top (mouse-driven configuration interfaces and other nonsense).

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.

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

Most BIOSes out there are based on the Intel UDK, which in turn periodically forks from the open source edk2 firmware. There are customizations depending on the hardware, but most of it is the same.

This should have a 2009 tag. Several points in the article are very outdated.

Do you have a better reference, or can you indicate which portions are outdated? This is an interesting topic.

https://github.com/tianocore/tianocore.github.io/wiki/Gettin...

Also, see the "Resources" section of this: https://github.com/tianocore/edk2

Every computer coming out these days should be on EDKII based UEFI Firmware

Windows devs may want to look at https://github.com/ionescu007/VisualUefi

I've done some very basic stuff in EFI before and it's pretty rough. It's one of those things where I feel like you had to have worked in that area to not have to spend a week on a simple gotcha that has certain implicit behavior.

The docs are decent, but not great, and the lack of stackoverflow answers hurts.

Reply on news.ycombinator.com