08a1a9033a
boot/bios/ now holds the MBR, the El Torito stub and the real-mode stage 2; boot/uefi/ is empty and documented. Separate directories rather than #ifdefs, because the two share almost nothing. A BIOS loader lives in 16-bit real mode, reaches the firmware through software interrupts, and walks itself up into long mode. A UEFI loader is a 64-bit PE that the firmware has already placed in long mode with paging on, calling services through a table of function pointers. What they do share is the hand-off contract, which boot/README.md now writes down: ELF segments placed, long mode, a 24-byte-entry memory map at E820_MAP_ADDR, framebuffer geometry at VBE_INFO_ADDR. That contract is the point of documenting it now. UEFI's GetMemoryMap returns EFI_MEMORY_DESCRIPTORs, and the right move is to translate them into the entries kernel/arch/x86_64/e820.c already parses rather than teach the kernel a second format. Build output paths under $(BUILD)/boot are unchanged; only sources moved.
28 lines
1.4 KiB
Markdown
28 lines
1.4 KiB
Markdown
<!-- SPDX-License-Identifier: Apache-2.0 -->
|
|
# UEFI loader
|
|
|
|
Not written yet. This directory exists so the BIOS path could be moved into
|
|
`boot/bios/` without pretending the split was hypothetical.
|
|
|
|
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 BIOS path fills.
|
|
|
|
The image goes at `EFI/BOOT/BOOTX64.EFI` on a FAT ESP, which also means the
|
|
ISO gains an El Torito EFI entry alongside the BIOS one it already has.
|