(Although this comment discusses an AI-written project, the comment itself is entirely human-written.)
It's probably worth pointing out that, unless you're writing a replacement for GRUB, Multiboot2 is a reasonable alternative to building a UEFI PE32+ image, and it permits you to still call UEFI services: https://www.gnu.org/software/grub/manual/multiboot2/multiboo...
I was pleased last month that I could elicit enough of a UEFI environment from Opus 5.5 to be able to build an UEFI application without enormous, un-auditable dependencies like gnu-efi. Claude distilled the relevant parts of the UEFI interface into a 289-line header file. The example application just displays the keyboard and mouse events on a UEFI framebuffer using a vendored pixel font, thus the name "inputmon": http://canonical.org/~kragen/sw/inputmon-3.tar.gz
The Makefile includes a "run" target to boot it under QEMU with the OVMF implementation of UEFI.
It does have the enormous, un-auditable dependency of LLVM and Clang, but that's a horror I'm already resigned to. But with clang, lld, and make, you can build the image from source, and with QEMU and OVMF you can run it in a virtual machine.
I think it's a little bit debatable to call UEFI "bare metal" (Boone responds: "this is a fair criticism"), and I'm particularly skeptical of Boone's claim that you can guarantee microsecond response times in the face of SMM, but whatever.
I think "leveraged this coding methodology" is an unjustifiably positive way to describe the results of the process. I think "spread this disease" would be more accurate. UTF-16 strings, really? VFAT? PE32+ is maybe justifiable, but VFAT? And even in 01998 it should have been apparent that UTF-16 was not a sane format for strings.
This guide is fantastic for getting rolling in the UEFI space. I used this as one of the references when building a bootloader with Zig. Has its own set of issue, especially that 16bit character situation.
Once you dig into those there are a bunch of sharp edges, or maybe it's just that that EFI environment is so weird compared to typical Linux system or application development.
One thing I would add to the intro: calling this "bare metal" is almost a cheat compared to the BIOS days. You start with a working console, a memory map, and even a file system service; then ExitBootServices takes every bit of that away. That is the real bare-metal moment, and it is exactly where a series like this earns its keep.
Two things that always bite people on this path:
- The memory map key returned by GetMemoryMap goes stale the moment anything allocates. Hand the freshly fetched key straight to ExitBootServices; if it comes back EFI_INVALID_PARAMETER, that is why. The firmware is right, even though it feels unfair.
- QEMU with OVMF (code and vars as separate pflash files) gives a far faster edit-run loop than rebooting hardware, and it is stricter about struct layout and protocol revisions than most real firmware. When something boots on metal but not in OVMF, it is almost always an alignment or version assumption, not a QEMU bug.
The pragmatic digression in Part 4 was a good call. The gap between "it built" and "it boots" is where most of the learning (and quitting) happens.
It's probably worth pointing out that, unless you're writing a replacement for GRUB, Multiboot2 is a reasonable alternative to building a UEFI PE32+ image, and it permits you to still call UEFI services: https://www.gnu.org/software/grub/manual/multiboot2/multiboo...
I was pleased last month that I could elicit enough of a UEFI environment from Opus 5.5 to be able to build an UEFI application without enormous, un-auditable dependencies like gnu-efi. Claude distilled the relevant parts of the UEFI interface into a 289-line header file. The example application just displays the keyboard and mouse events on a UEFI framebuffer using a vendored pixel font, thus the name "inputmon": http://canonical.org/~kragen/sw/inputmon-3.tar.gz
The Makefile includes a "run" target to boot it under QEMU with the OVMF implementation of UEFI.
It does have the enormous, un-auditable dependency of LLVM and Clang, but that's a horror I'm already resigned to. But with clang, lld, and make, you can build the image from source, and with QEMU and OVMF you can run it in a virtual machine.
I think it's a little bit debatable to call UEFI "bare metal" (Boone responds: "this is a fair criticism"), and I'm particularly skeptical of Boone's claim that you can guarantee microsecond response times in the face of SMM, but whatever.
And on "Be aware of the Windows-ness of EFI" commentary the resemblance to Windows coding style https://computernewb.com/~lily/files/Documents/NTDesignWorkb... is no accident. We leveraged this coding methodology as we evolved the original Intel Boot Initiative then EFI and then UEFI code and specification https://www.intel.com/content/dam/www/public/us/en/documents...
Once you dig into those there are a bunch of sharp edges, or maybe it's just that that EFI environment is so weird compared to typical Linux system or application development.
Two things that always bite people on this path:
- The memory map key returned by GetMemoryMap goes stale the moment anything allocates. Hand the freshly fetched key straight to ExitBootServices; if it comes back EFI_INVALID_PARAMETER, that is why. The firmware is right, even though it feels unfair.
- QEMU with OVMF (code and vars as separate pflash files) gives a far faster edit-run loop than rebooting hardware, and it is stricter about struct layout and protocol revisions than most real firmware. When something boots on metal but not in OVMF, it is almost always an alignment or version assumption, not a QEMU bug.
The pragmatic digression in Part 4 was a good call. The gap between "it built" and "it boots" is where most of the learning (and quitting) happens.