Watch

Nexoniarz 651899220c boot: the BIOS loader is gone

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.

2026-08-11 10:20:28 +02:00

5.1 KiB

Raw Blame History

Moving the project to a Linux machine

Written for the move to /home/nexoniarz/Documents/SchOS on Fedora 44. Nothing here is Fedora-specific except the package names.

1. Copy the repo

Copy the whole directory, .git included. Everything that matters is committed — 17 commits, no remote — and that includes the project memory, which lives in .claude/memory/ precisely so it survives this.

# whatever transport suits: a USB stick, rsync, scp
rsync -a /path/to/SchOS/ /home/nexoniarz/Documents/SchOS/
cd /home/nexoniarz/Documents/SchOS
git log --oneline | head -3     # should show the same commits
git status                      # should be clean

What is not in the repo

build/, sysroot/ and dist/ are all gitignored, so rsync -a of the working tree carries them but a git clone would not. Two are worth thinking about:

dist/ holds the upstream tarballs — musl, toybox, mksh, the DOOM WADs, usb.ids. 61 MB of other people's release artefacts. Copy it to save the download, or let the build fetch them again; make ports calls curl and verifies each against a known SHA-256, so a re-download is safe either way. Without a network connection, copy it.
sysroot/ is assembled by the build, so it does not need copying — and on this machine it should not be. Its bin/ holds musl, toybox and mksh, staged once because Windows cannot build them. Linux can, so let make ports produce them rather than carrying stale binaries across: the staged copies predate the rename, and sysroot/bin/sh still contains __schunix_tp.
build/ is pure output. Delete it and forget it.

2. Restore the memory

Claude Code keeps per-project memory under a key derived from the project's absolute path, so it differs per machine:


`D:\DEV\SchOS`	`D--DEV-SchOS`
`/home/nexoniarz/Documents/SchOS`	`-home-nexoniarz-Documents-SchOS`

One command puts it where this machine looks:

tools/posix/memory-sync.sh status   # shows both sides, changes nothing
tools/posix/memory-sync.sh import   # repo -> ~/.claude/projects/<key>/memory/

That writes to /home/nexoniarz/.claude/projects/-home-nexoniarz-Documents-SchOS/memory/.

After a session that learned something, export and commit, so the knowledge travels back:

tools/posix/memory-sync.sh export && git add -A && git commit -m "memory: ..."

3. Install the toolchain

tools/posix/setup-fedora.sh --check   # report what is missing
tools/posix/setup-fedora.sh           # install it

That covers clang, lld, llvm, make, gcc, perl, python3, qemu-system-x86, edk2-ovmf, xorriso and mtools. See building.md for what each is for and for the other supported hosts.

PowerShell is the one thing dnf cannot supply. tools/windows/bootcheck.ps1 is the boot test suite, and pwsh runs it on Linux perfectly well — there is simply no Fedora package. The script prints the two ways to get it. Nothing else needs it: make, make schfs-check and make qemu all work without.

4. Build and check

make                    # kernel + root filesystem
make schfs-check        # B-tree, object and image suites -- all host-native
make qemu               # boot it

Two things will behave differently here, both improvements:

make ports works. musl, toybox and mksh build from source. On Windows the build skips them and uses whatever is staged.
The SchFS round-trip test runs. It needs symlinks and hard links, which Git Bash cannot create, so on Windows it skips with a message. This is the first machine that can actually exercise that path — worth running early, since it is the one part of SchFS never yet tested.

5. KVM

A Ryzen 7000 has SVM, so QEMU can run at native speed instead of emulating:

ls -l /dev/kvm                       # should exist
sudo usermod -aG kvm $(id -un)       # if it exists but is not readable

Then add -enable-kvm to a QEMU command line. It is deliberately not the default in the Makefile: the test suite's timings were established under TCG, and changing the execution engine underneath them is a variable worth introducing on purpose rather than by accident.

6. UEFI

make qemu-uefi boots the UEFI path under OVMF. The Makefile searches the usual locations for the firmware and Fedora's edk2-ovmf (/usr/share/edk2/ovmf/OVMF_CODE.fd) is among them.

Note the open bug before spending time on it: under OVMF the kernel reports e820: only 8 MB usable, because e820_init takes the usable run containing the kernel and OVMF puts an ACPI NVS region at 0x800000, genuinely fragmenting it. The loader's map is correct; the kernel's one-contiguous-run assumption is BIOS-shaped. The fix is to free each usable region rather than one range, which touches kalloc.

The hardware, for reference

Fedora 44, Ryzen 5 7000-series, RTX 4050, 16 GB DDR5. Nothing in the build cares about the GPU — QEMU runs headless for tests and uses its own emulated display otherwise. The Nvidia driver matters only if you want a QEMU window, and the nouveau/proprietary choice makes no difference to SchOS either way.

5.1 KiB Raw Blame History