| Filename | Latest commit message | Latest commit date |
|---|---|---|
c4dd76cc66
Two bugs on the ExitBootServices path, both invisible under OVMF and both aimed squarely at real firmware. The retry did not re-translate. If ExitBootServices returns an error the loader re-reads the memory map and tries again -- correct, and the specification expects it -- but the e820 table handed to the kernel was still the one built from the *previous* map. The retry exists precisely because the map changed, so the kernel was being given a description of memory the firmware had already rearranged. QEMU never takes this path, which is why it survived. Translation is now a function called on both. Truncation was silent. phystop comes from the largest usable region, so dropping the tail of the map can leave the kernel believing a large machine has a fraction of its RAM -- and nothing said so, because the loop simply stopped at the cap. It now warns while there is still a console to warn on; after ExitBootServices there is nowhere to report anything. SCHBOOT_E820_MAX goes from 32 to 40. The map sits at BASE+0x208 and the next field is at BASE+0x600, so 1016 bytes are reserved and 42 entries of 24 bytes fit. Real firmware emits far more descriptors than QEMU's; the headroom was already allocated and unused. Coalescing adjacent same-type runs is what keeps any of this in budget, and it works because boot services memory becomes usable at this point -- that is most of the fragmentation in a UEFI map. 110 [ok], no failures, and the map still reads 7 regions under OVMF. |
||
| .. | ||
| efi.h | ||
| main.c | ||
| README.md | ||
| startup.nsh | ||
UEFI loader
The loader. This directory once existed only so the BIOS path could be moved
into boot/bios/ without pretending the split was hypothetical; it is now the
only path there is.
See ../README.md for the hand-off contract a loader has to satisfy. The
short version: the kernel wants long mode with paging on, its ELF segments
placed, a 24-byte-entry E820-shaped memory map, and framebuffer geometry — and
it does not care which firmware produced them.
What this will need, in rough order:
- A PE/COFF target. clang can emit one directly
(
--target=x86_64-unknown-windows -fuse-ld=lld-link), so no new toolchain: the same LLVM install already builds every other target here. - The handful of UEFI structures actually used — the system table, boot
services,
LOADED_IMAGE,SIMPLE_FILE_SYSTEM,GRAPHICS_OUTPUT. Written from the specification rather than by importing gnu-efi or EDK II, which is both a licence question and a large dependency for something this small. GetMemoryMaptranslated into the same 24-byte entriese820.calready parses. Not a second format for the kernel to learn.ExitBootServicesbefore touching the memory it described.- Graphics Output Protocol for the framebuffer, filling the same
VBE_INFO_ADDRstructure the kernel reads.
The image goes at EFI/BOOT/BOOTX64.EFI on a FAT ESP, which also means the
ISO carries a single El Torito EFI entry.