56139bd0e6
Loads the kernel from the ESP, places its ELF segments, records the framebuffer, translates the UEFI memory map into E820 entries, exits boot services, builds the page tables the kernel expects and jumps. Verified under OVMF: the kernel starts, brings up PCI, VGA, e1000 and the RTC, and reaches "cpu0: starting". UEFI structures are written from the specification rather than importing gnu-efi or EDK II -- a large dependency for two hundred lines of use, and a licensing question the project does not need to answer. clang emits PE/COFF directly, so this needs no new toolchain. The kernel gained a second entry point. The multiboot entry is 32-bit code that climbs into long mode itself, and firmware that already put us there would have to drop back down only to climb out again -- a mode switch whose failure mode is a triple fault with no console. So entry.S publishes its 64-bit entry the same way it publishes the multiboot header: a magic to scan for, SCH64BOO, with include/schboot.h owning the constants so the two cannot disagree. That header goes *after* the multiboot header, never before: header_addr says the multiboot header lives at mboot_load_addr, and the BIOS loader computes the kernel's file offset from it. The kernel loads its own GDT at that entry rather than the loader doing it. Arriving in long mode means arriving on the firmware's descriptors, and the first thing depending on the kernel's own selectors faulted -- "unexpected trap 13 ... cs=38", a long way from the cause. KNOWN LIMITATION, diagnosed and not yet fixed: e820_init takes the usable run *containing the kernel*, which under OVMF ends at 8 MB -- the firmware places an ACPI NVS region at 0x800000, so the run is genuinely fragmented. The map is truthful and untruncated (21 entries); the assumption of one contiguous run is BIOS-shaped. The fix is for the kernel to free each usable region rather than one range, which touches kalloc and deserves its own change rather than the tail of this one. BIOS boot is unaffected: 27 checks, no failures.
93 lines
4.4 KiB
Markdown
93 lines
4.4 KiB
Markdown
<!-- SPDX-License-Identifier: Apache-2.0 -->
|
|
# 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 `#ifdef`s 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 a `movabs`
|
|
to 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
|
|
|
|
1. **`bios/bootasm.S`** — the literal MBR sector. Signed to 512 bytes by
|
|
`tools/sign.pl`, loads stage 2 from LBA 1 and jumps.
|
|
2. **`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.
|
|
3. **`bios/stage2.S`** — collects the E820 map, sets a VBE mode, enters
|
|
protected mode.
|
|
4. **`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.
|