| 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>
|
||
| .. | ||
| bios | ||
| common | ||
| uefi | ||
| README.md | ||
Booting SchOS
Two firmware paths, kept apart on purpose:
boot/
bios/ legacy BIOS: MBR, El Torito CD stub, real-mode stage 2
uefi/ UEFI application (not written yet)
They are separate directories rather than #ifdefs in one because they share
almost nothing. A BIOS loader lives in 16-bit real mode, talks to the firmware
through software interrupts, and has to walk itself up into long mode. A UEFI
loader is a 64-bit PE executable that the firmware has already placed in long
mode with paging on, and it asks for services by calling through a table of
function pointers. The only things genuinely in common are the logo bitmap, the
menu's appearance, and the hand-off contract below.
What the loader must hand the kernel
Whichever path runs, the kernel expects the same things. This is the contract; a second loader is correct exactly when it satisfies it.
| Where | Notes | |
|---|---|---|
| Kernel image | loaded per its ELF program headers | entry at entry64 |
| CPU state | see below -- the two paths differ here | |
| Memory map | E820_MAP_ADDR, 24-byte entries, count at E820_COUNT_ADDR |
kernel/arch/x86_64/e820.c reads it |
| Framebuffer | VBE_INFO_ADDR |
address, pitch, width, height, depth |
| Verbose flag | BOOT_VERBOSE_FLAG_ADDR |
set by the F8 menu |
The addresses are defined once, in include/memlayout.h and
boot/bios/stage2main.c. A UEFI loader must fill the same structures — the
kernel does not care which firmware produced them, and that is what keeps the
split cheap.
Two entry points, because the two firmwares hand over differently
The BIOS path enters the kernel in 32-bit protected mode at the multiboot
entry, with EAX holding the framebuffer address; mboot_entry then builds page
tables and climbs into long mode itself.
UEFI hands a loader long mode with paging already on. Dropping back to
protected mode only to climb out again is a mode switch whose failure mode is a
triple fault with no console, so the kernel publishes a second entry instead.
kernel/arch/x86_64/entry.S carries a sch64_header — magic SCH64BOO,
8-byte aligned within the first 16 KB, followed by a 64-bit physical address —
found by scanning, exactly as the BIOS loader scans for the multiboot magic.
include/schboot.h holds the magic so loader and kernel cannot disagree.
What that entry expects:
- long mode, interrupts off
- CR3 pointing at tables that identity-map the low 4 GB and map the same
4 GB at
0xffff800000000000.entry64low's first instruction is amovabsto a high address, so identity alone triple faults immediately. - RBX = the framebuffer physical address, and never 1 — that value marks an
application processor in
entry64high.
The kernel loads its own GDT at that entry (entry64uefi), rather than the
loader doing it. A loader arriving in long mode is still on the firmware's
descriptors, and the first thing the kernel does that depends on its own
selectors takes a #GP against a GDT the firmware no longer owns — it
surfaced as unexpected trap 13 ... cs=38, a long way from the cause.
e820.c reads a BIOS memory map. UEFI hands out a different structure
(EFI_MEMORY_DESCRIPTOR, from GetMemoryMap), so the UEFI loader has to
translate it into the same 24-byte entries rather than inventing a second
format for the kernel to learn.
The BIOS path today
bios/bootasm.S— the literal MBR sector. Signed to 512 bytes bytools/sign.pl, loads stage 2 from LBA 1 and jumps.bios/cdboot.S— the same job for optical media, as an El Torito no-emulation image. Separate because the loader never uses INT 13h and so needs a real ATAPI read.bios/stage2.S— collects the E820 map, sets a VBE mode, enters protected mode.bios/stage2main.c— the boot menu and splash, then loads the kernel and enters long mode.
STAGE2_SECTORS is defined once, in the Makefile, and passed to both the
assembler and the dd that writes the image. It used to be written out by hand
in five places and silently truncated the loader when they disagreed.
Why UEFI is worth doing
Everything since roughly 2012 boots UEFI by default, and Secure Boot machines will not run the BIOS path at all without firmware settings most people never touch. The BIOS loader stays regardless: it is what QEMU's default machine and older hardware use, and it costs nothing to keep once the two are separated.