# 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: 1. 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. 2. 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. 3. `GetMemoryMap` translated into the same 24-byte entries `e820.c` already parses. Not a second format for the kernel to learn. 4. `ExitBootServices` before touching the memory it described. 5. Graphics Output Protocol for the framebuffer, filling the same `VBE_INFO_ADDR` structure 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.