| Filename | Latest commit message | Latest commit date |
|---|---|---|
799abbc19a
The BIOS loader drew its own splash and the UEFI loader drew a different
one, which is how two implementations of a single screen end up looking
nothing alike: only one of them ever got a change. stage2main.c's
fourteen drawing functions are deleted and it calls boot/common/ui.c,
which is what the UEFI loader already used. There is one splash now.
What changed in the look, in order of how much it mattered:
- No product name under the mark. The name is *in* the mark, and
setting it again underneath read as a placeholder nobody removed.
- The mark is scaled to the bar's width and sits directly above it, so
the two are one object rather than a large logo with an unrelated
line beneath. Box-filtered down from the source mask, never up:
point-sampling a coverage mask drops half the edge pixels and puts
holes in the thin strokes.
- Metal rather than flat grey. A vertical gradient with a knee near the
top where a highlight falls, applied to the mark, the bar fill and
panel headings. A single colour on a dark ground looks printed; the
knee is what makes it look lit. No texture -- at this size noise
reads as dirt.
- The boot manager is a panel with a lit selected row, replacing a
screen laid out in literals with a magic y of 340 that only ever
looked right at 800x600.
Three defects found by reading pixels rather than code:
- the UEFI loader kept calling print() after the splash, and ConOut on
a graphical firmware renders into the same framebuffer -- a
screenshot showed firmware text across our mark from the left edge.
Diagnostics go to COM1 directly now, which is where they were being
read from anyway, and the console is cleared before drawing so the
firmware has nothing to put back.
- SPLASH_UP was declared and read but never assigned, so that redirect
was dead code and the "serial works" reading was OVMF's own console.
- stage2 overflowed its allocation -- 25440 bytes against 24576 -- and
the build did not stop. The kernel is written at sector
1 + STAGE2_SECTORS, so a stage2 past its allocation is overwritten by
the kernel it is loading. STAGE2_SECTORS is 64 now, and the padding
tool's check does fire; it had simply not been re-run.
Verified from the host on both: BIOS 800x600 and UEFI 1280x800 both draw
a centred group with zero stray pixels, UEFI's spanning x 576-703 which
is exactly the mark width centred. bootcheck 108 [ok], iso builds.
Still text-mode: the resolution menu. On BIOS it necessarily is -- it
runs in real mode before any framebuffer exists, which is the whole
reason it can set one. On UEFI it could be graphical and is not yet.
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.