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