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
SchOS/boot/uefi
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz 726091000e uefi: copy the kernel home and jump from a page it cannot reach 
The staged segments were copied home after ExitBootServices by the
loader itself -- on code, a stack and a copy list the firmware had
placed wherever it liked. On an HP all-in-one some of that was in the
kernel's range: "Placing the kernel", then a triple fault and a reset.

The copy and the jump now run from one page below the kernel's lowest
address, allocated as loader code before the firmware exits: a short
position-independent routine, the copy list, and a stack. It switches
to the loader's page tables and its own stack before copying anything.
Called sysv_abi, because UEFI code is the Microsoft convention and the
first try loaded the framebuffer address into rsp.

The framebuffer address handed over in rbx is 64-bit now too; the
kernel already read the full one from the hand-off block.

Also write.sh: writes schos.iso to a USB stick, after showing the
device and asking for its name to be typed back; refuses partitions,
the system disk and non-removable disks; reads the result back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2026-10-24 11:00:02 +02:00
..
efi.h display: a 64-bit framebuffer address, no mirroring onto itself 2026-10-23 15:46:42 +02:00
main.c uefi: copy the kernel home and jump from a page it cannot reach 2026-10-24 11:00:02 +02:00
README.md licence: SchOS is GPL-2.0-or-later, no longer Apache-2.0 2026-10-22 08:48:45 +02:00
startup.nsh boot/uefi: a working UEFI loader, with one known limitation 2026-08-09 17:13:09 +02:00

README.md

UEFI loader

The loader. This directory once existed only so the BIOS path could be moved into boot/bios/ without pretending the split was hypothetical; it is now the only path there is.

See ../README.md for the hand-off contract a loader has to satisfy. The short version: the kernel wants long mode with paging on, its ELF segments placed, a 24-byte-entry E820-shaped memory map, and framebuffer geometry — and it does not care which firmware produced them.

What this will need, in rough order:

  1. A PE/COFF target. clang can emit one directly (--target=x86_64-unknown-windows -fuse-ld=lld-link), so no new toolchain: the same LLVM install already builds every other target here.
  2. The handful of UEFI structures actually used — the system table, boot services, LOADED_IMAGE, SIMPLE_FILE_SYSTEM, GRAPHICS_OUTPUT. Written from the specification rather than by importing gnu-efi or EDK II, which is both a licence question and a large dependency for something this small.
  3. GetMemoryMap translated into the same 24-byte entries e820.c already parses. Not a second format for the kernel to learn.
  4. ExitBootServices before touching the memory it described.
  5. Graphics Output Protocol for the framebuffer, filling the same VBE_INFO_ADDR structure the kernel reads.

The image goes at EFI/BOOT/BOOTX64.EFI on a FAT ESP, which also means the ISO carries a single El Torito EFI entry.