# 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. ## The boot manager `F8` (or `o` on a serial line) opens a Niveus-styled boot manager, drawn by `../common/ui.c` in Instrument Sans (`include/gfx/nvfont.h`, regenerate with `make nvfont`). It takes keyboard and pointer, lists other systems it finds on the disks and can chain-load them, and has working Firmware Setup, Restart and Shut Down. See [docs/architecture/boot.md](../../docs/architecture/boot.md#the-boot-manager).