| Filename | Latest commit message | Latest commit date |
|---|---|---|
64e4835524
The first piece of the two loaders that is genuinely common code rather than a contract they both honour. It can be, because the difference between the firmwares is entirely in how a framebuffer is *obtained* -- VBE in real mode, or GOP -- and not in what you do with one afterwards. boot/common/ui.c takes a base, a size and a stride and draws; it knows nothing about disks, memory maps or mode setting, which is what lets it compile into a 16/32/64-bit BIOS loader and a PE/COFF UEFI application without either leaking into it. The look is deliberately quiet: dark ground, the mark centred, one thin bar beneath it, nothing on screen that is not load-bearing. The whole group is laid out from the centre outwards rather than from the top down, so it sits identically at 800x600 and at 1600x1200 instead of drifting up the screen as the mode grows. UEFI had no graphical splash at all -- it printed text to a console the QEMU window is usually not even showing. It draws the same screen as the BIOS path now, with the bar tracking bytes of kernel actually written rather than a segment count, which says nothing about how long each takes. Two ordering bugs found by looking at the pixels rather than the code: setup_framebuffer ran *after* the kernel was read, so every progress tick went to a framebuffer that did not exist yet and the splash then painted over the result; and that also put the resolution prompt after the slowest step instead of at the start. The display is set up first now. Verified from the host with screendump: background is exactly SCH_BG, the bar is 4px tall and width/4 wide at y=495 on a 1280x800 screen, which is where centring the group puts it. UEFI still boots to cpu0; BIOS bootcheck 27/27. Not yet shared: the BIOS loader still draws with its own copy of this code. Deleting that copy in favour of this one is the next step and the point of the exercise -- until then this is one loader using shared code and one duplicating it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .. | ||
| efi.h | ||
| main.c | ||
| README.md | ||
| startup.nsh | ||
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:
- 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 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.