| Filename | Latest commit message | Latest commit date |
|---|---|---|
3c5212a7c7
A laptop has no serial port, and the machine we are trying to boot stops with the loader's splash still on screen. Three completely different things look exactly like that: the jump never landed, the kernel started and hung, or the kernel started and panicked with a full report drawn into a framebuffer nobody can see. They call for different next steps, so the kernel now says which without needing a console at all. **A bar, as the kernel's first act.** Eight lines of accent colour across the top of the framebuffer, written straight through the handoff block before a single subsystem exists -- no gfx, no scanout, no allocator, nothing that can itself fail. If it appears over the splash, the jump landed and the kernel is executing. If it does not, nothing below that point is worth looking at. Skipped when the framebuffer is above the direct map, because a fault there leaves the machine quieter still, and free on a boot that works: the console clears the screen a few lines later. **Blinking keyboard lights, on panic.** Scroll, Num and Caps together, about three times a second, for ever. It is the one output every PC has had since before any of this existed -- no driver, no interrupt, no memory -- and it works when the graphics do not. Linux does the same thing for the same reason. Every wait in it is bounded. It runs after `panicked` is set so there is nothing left to protect, but a machine that hangs inside its own death rattle tells you less than one that stops quietly. The delay is microdelay, which spins on the TSC: no timer, no interrupt, no calibration -- all three of which a kernel that died during boot may not have. That makes the three cases distinguishable from across the room: no bar and no blink is a jump that did not land; a bar and no blink is a kernel that hung; a blinking keyboard is a panic, and the report is in /proc/kmsg after a restart. **And the loader now describes the mode it is actually handing over**, not only the one the firmware started in. On a machine where changing the resolution loses the splash entirely, the difference between those two lines is the bug report; on a boot that works nobody sees either, because ClearScreen runs a few lines later. Verified: `echo c > /proc/sysrq`, then QMP polled for five and a half seconds afterwards -- the machine answers throughout and a screendump still shows the panic report intact, so the blink loop runs without faulting, resetting, or scribbling on what it is there to accompany. Both supported configurations boot clean with the early bar in place. 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.