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

memory: UEFI reaches userspace, and the ISO grows a hierarchy

Browse source 
Records the four bugs between "boots to cpu0: starting" and "boots to an
interactive shell", the new ioremap rule for device registers, and what
the disc now contains -- including that it is still not a live CD, and
what that would take.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-08-09 22:04:12 +02:00
commit b428a50145
4 changed files with 121 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

43
.claude/memory/schos-uefi-loader.md
View file

@ -4,7 +4,7 @@ description: "boot/uefi works under OVMF; the SCH64 entry, the GDT trap, and the
metadata:
node_type: memory
originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
modified: 2026-08-09T19:05:15.325Z
modified: 2026-08-09T20:03:43.364Z
---
**`boot/uefi/` boots.** `make uefi`, `make esp`, `make qemu-uefi`. Verified
@ -68,22 +68,37 @@ alternating rounds): boot to prompt **14.8 s vs 21.2 s**, and a cold
0.3 s. So if the allocator ever looks slow again, this is the baseline to
compare against.
## What still stops a full UEFI boot
## UEFI reaches userspace — 2026-08-09
Two separate, pre-existing problems — neither is the memory map, and both
predate the e820 work (the unfixed kernel triple faults in the same place):
**`make iso` produces a disc that boots under OVMF all the way to an
interactive shell**, verified by driving it over serial: `uname -a`, 241
binaries in `/bin`, write-then-read a file, `ps`, `/proc/schfs`. The old
`cpu0: starting` ceiling is gone.
1. **virtio-gpu's BAR lands above 4 GB.** OVMF assigns the 64-bit BAR high;
the first MMIO write faults with `CR2` around `0xffff80c000000014`, which is
`P2V` of physical **768 GB**, far outside the 4 GB direct map `kvmalloc`
builds from four 1 GB pages. Then a double fault, then a triple fault and a
reboot loop. SeaBIOS assigns it low, so the BIOS path never sees it.
**Drop `-device virtio-gpu-pci` to boot UEFI past this.**
2. **Boot stalls after `cpu0: starting`**, before `schfs: mounted`. Under UEFI
the ESP is hd0 and schfs.img is hd1; the root never mounts. Not diagnosed.
Four bugs stood between here and there. Three were pre-existing and invisible
purely because this path had never got far enough to expose them.
`cpu0: starting` remains the UEFI high-water mark, now reached with a truthful
memory map rather than a fabricated one.
1. **virtio-gpu's BAR lands above 4 GB.** OVMF puts the 64-bit BAR at about
768 GB; `P2V` of that has no translation, so the first register write page
faulted, then double, then triple, then a reboot loop. Every driver did
`P2V(bar.base)`. Fixed by a real `ioremap()` — see
[[schunix-ioremap-and-bars]].
2. **`EFER.SCE` was never set on the UEFI entry.** The 32-bit entry sets it
while climbing into long mode; `entry64uefi` skips that bootstrap because
firmware already switched modes, and UEFI has no reason to set SCE. The first
`sysretq` raised **#UD in pid 1 at zero ticks**, `rip` in `syscall_trapret`.
3. **The RSDP is not where a BIOS leaves it.** `find_rsdp()` scanned the EBDA
and `0xE0000`; OVMF publishes it in the EFI configuration table only. No
RSDP means no MADT, no IOAPIC, no IRQ routing — and since serial *output* is
polled, the machine reached a prompt and then ignored every keystroke, which
looks like a broken console. The loader now passes it at `SCHBOOT_RSDP_ADDR`.
**Do not require 16-byte alignment** when validating it: that rule is about
scanning the BIOS area, and OVMF's sits at `0x3f77e014`.
4. **The ramdisk was a v1 image** the kernel could not mount — see
[[schunix-iso-boot]].
Still true: the loader prints `could not reserve` warnings for kernel segments
the firmware already owns, and writes there anyway. It has not bitten yet.
## Testing