| Filename | Latest commit message | Latest commit date |
|---|---|---|
96e10adfcb
EFI status 0x5 is EFI_BUFFER_TOO_SMALL, and that is the whole bug: the loader
asked the firmware for its memory map with a 32 KB buffer, which is about 680
descriptors -- generous next to QEMU's map and not generous at all next to a
machine whose firmware has carved out every reserved range it has ever needed.
The descriptor count is a property of the vendor, not of the RAM, which is why
this was invisible in every test here and fatal on two real machines.
The fix is not a bigger guess. A call with a **zero size** fails on purpose and
fills in the size actually needed, and it allocates nothing -- so the map key
from the real call immediately after is still valid, which is the constraint
this whole sequence is written around and the reason the buffer has to be
static. 256 KB now, which is 5461 descriptors, and a machine that somehow
exceeds even that is told in numbers rather than in a status code:
schos: the firmware's memory map needs 5664 bytes and this loader has 512
schos: memory map larger than the loader's buffer (status 0x...0005)
That line is real: the failure path was provoked by shrinking the buffer to 512
and booting, which is also how the 5664 was measured -- QEMU needs 118
descriptors, so hardware needs more.
**A second limit is nearby, and it is only a warning.** SCHBOOT_E820_MAX is 40
entries, fixed by the hand-off block's layout; build_e820() merges adjacent
regions of the same type, so 40 survives a long map. If it ever does truncate,
what is dropped is the high end -- the map arrives sorted and phystop is capped
below 4 GB regardless -- so it stays a warning. But it now appears on screen as
well as on the serial line, because after the splash print() goes to a port a
laptop does not have, and "some RAM was quietly unused" is not a thing to
discover months later from a total that never looked right.
Both supported configurations: one boot each, no traps, no panics, socktest and
memfdtest green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
| .. | ||
| 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.