nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

boot: the BIOS loader is gone

Browse source 
1449 lines of boot/bios/, tools/sign.pl and tools/padstage2.pl, plus the
build rules, the disk image and the ISO entry that existed to carry them.

Everything since roughly 2012 boots UEFI, and CSM -- the firmware-side
BIOS emulation that lets a legacy loader run on such a machine at all --
has been going away since Intel dropped support for it in 2020. So this
is not a path being retired early; it is one whose remaining hardware is
already the exception.

The cost was never the code, it was the tax on everything near it. Stage
2 had a 65-sector ceiling it overflowed silently -- 25440 bytes against
24576 -- and because the kernel is written at sector 1 + STAGE2_SECTORS,
an overflowing loader was overwritten by the very kernel it was loading.
The resolution list could not be shared with UEFI either: VBE mode
setting is INT 10h, so matching it needed unreal mode, which is the
riskiest code in the tree for a feature that already worked elsewhere.

What replaces schos.img is the staged ESP, handed to QEMU as a virtual
FAT volume. That is a development arrangement and not an installable
disk; a real GPT image with a real FAT partition is the installer's job,
and until it exists nothing here writes a disk a machine boots unaided.
Secure Boot is untouched too -- the loader is unsigned.

The ISO keeps one El Torito entry, the FAT image holding loader and
kernel. It never booted from a USB stick via BIOS anyway: the firmware
presents the stick as a hard disk while stage2main.c read the kernel back
over ATAPI.

The 32-bit multiboot entry in entry.S now has no caller and is left in
place. Deleting kernel entry code is its own change with its own way of
failing silently, and it should not ride along with this one.

Ported with it: run.ps1, the six screenshot tools, and schcom_test.sh,
each with its own OVMF varstore copy so no run inherits another's UEFI
variables.

Two things this shook out. OVMF now belongs in `all`: nothing boots
without firmware, `make clean` wipes build/ including the copy fetched
from the host, and a clean followed by a build left every run script
throwing. And it cannot be listed as a prerequisite at the top of the
file -- make expands prerequisites when it reads the line, and
$(OVMF_CODE) is defined further down, so naming it there appends nothing
and says nothing.

Verified from a clean tree: 110 [ok] and no failures on the full suite,
the ISO boots with no hard disk attached, schfs-check passes, schcom's
end-to-end pixel test passes, and fbshot captures a real 1280x800 frame.
This commit is contained in:
Nexoniarz 2026-08-11 10:20:28 +02:00
commit 651899220c
23 changed files with 317 additions and 1826 deletions
Download patch file Download diff file Expand all files Collapse all files

82
boot/README.md
View file

@ -1,21 +1,30 @@
<!-- SPDX-License-Identifier: Apache-2.0 -->
# Booting SchOS
Two firmware paths, kept apart on purpose:
One firmware path:
```
boot/
bios/ legacy BIOS: MBR, El Torito CD stub, real-mode stage 2
uefi/ UEFI application (not written yet)
uefi/ the loader: a 64-bit PE application
common/ the user interface, shared with nothing else now
```
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.
There were two. `boot/bios/` held an MBR, an El Torito CD stub and a real-mode
stage 2, and it was a separate directory rather than `#ifdef`s because the two
shared almost nothing: a BIOS loader lives in 16-bit real mode and talks to the
firmware through software interrupts, while UEFI hands a loader long mode with
paging already on and a table of function pointers to call.
That asymmetry is what removed it. Everything since roughly 2012 boots UEFI,
CSM — the firmware-side BIOS emulation that let legacy loaders run at all — has
been going away since Intel dropped support for it in 2020, and the cost of the
second path was not the code but the tax on everything that touched it: stage 2
had a 65-sector ceiling that it silently overflowed, and the resolution menu
could not be shared because VBE mode setting is `INT 10h` and needs real mode.
The contract below survives it. It was written to let a second loader exist, and
it is worth keeping in that shape: it is what the kernel expects, stated once,
rather than a description of whoever happens to be calling.
## What the loader must hand the kernel
@ -30,24 +39,24 @@ a second loader is correct exactly when it satisfies 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.
The addresses are defined once, in `include/memlayout.h` and `include/schboot.h`.
The kernel does not care which firmware produced them.
## 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.
## The entry point
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.
triple fault with no console, so the kernel publishes an entry that takes the
machine as it already is.
`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.
found by scanning. `include/schboot.h` holds the magic so loader and kernel
cannot disagree.
The 32-bit multiboot entry is still in `entry.S` and now has no caller: the
BIOS loader was the only thing that used it. It is left in place rather than
removed in the same change that removed the loader, because deleting kernel
entry code is its own piece of work with its own way of failing silently.
What that entry expects:
@ -69,25 +78,16 @@ surfaced as `unexpected trap 13 ... cs=38`, a long way from the cause.
translate it into the same 24-byte entries rather than inventing a second
format for the kernel to learn.
## The BIOS path today
## What booting looks like now
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.
`make esp` stages `EFI/BOOT/BOOTX64.EFI` and `schos/kernel`, and QEMU is
pointed at OVMF with that directory as a virtual FAT volume — `make qemu`.
`make iso` builds a disc with a single El Torito entry pointing at a FAT image
holding the same two files.
`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.
Neither is an installable disk. A real GPT image with a real FAT partition is
the installer's job, and until it exists there is nothing here that writes to a
disk a machine could boot from unaided.
## 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.
Secure Boot is not addressed either: the loader is unsigned, so a machine
enforcing it will refuse to run this.