
UEFI Programming – First Steps (2009) - kqr2
http://x86asm.net/articles/uefi-programming-first-steps/
======
fao_
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.

~~~
cptskippy
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.

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

~~~
cptskippy
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.

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

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

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

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

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

~~~
cognitivedev
[https://github.com/tianocore/tianocore.github.io/wiki/Gettin...](https://github.com/tianocore/tianocore.github.io/wiki/Getting-
Started-with-EDK-II)

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

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

------
voltagex_
Windows devs may want to look at
[https://github.com/ionescu007/VisualUefi](https://github.com/ionescu007/VisualUefi)

------
david-cako
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.

