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 0500e4382d boot: one hand-off contract, defined once 
Groundwork for the unified loader: before the two paths can share code,
they have to agree on what they are producing, and until now they only
agreed by coincidence.

Every field of the loader/kernel hand-off was #defined in whichever file
happened to need it -- kernel/core/main.c, kernel/dev/vga.c,
kernel/arch/x86_64/e820.c, boot/bios/cdboot.S, boot/bios/stage2main.c and
boot/uefi/main.c, six copies of the same addresses. schboot.h existed for
exactly this and held only the entry magic and the RSDP slot, with a
comment describing the rest of the block it did not define.

The whole block lives there now: the VBE info fields, the verbose and
media flags (with the real-mode segment:offset spelling cdboot.S needs),
the e820 count, map and cap, and the RSDP. Every one of those files
includes it instead of restating it.

This is not a tidy-up. It is the same hazard as defining the entry magic
twice, only quieter -- nothing breaks until one copy moves, and the two
loaders diverging is precisely what produced the EFER.SCE and RSDP bugs,
where a fix on one path silently did not exist on the other.

Verified on both firmwares: BIOS boots to schinit with the same e820,
ACPI and VGA lines as before; UEFI reaches cpu0 with 1018 MB in 7 regions
and its own 1280x800 mode. `make iso` still builds. bootcheck 108 [ok].

Next: the loaders become starters that gather firmware-specific facts and
hand to one common stage. That needs the BIOS side to climb to long mode
first, since common code can only be compiled for one CPU mode -- which
is the risky part, and is why the contract went first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 21:37:36 +02:00
..
efi.h boot/uefi: choose a resolution with R, the same as the BIOS path 2026-08-10 05:30:03 +02:00
main.c boot: one hand-off contract, defined once 2026-08-10 21:37:36 +02:00
README.md boot: separate BIOS from UEFI 2026-08-09 16:00:03 +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

Not written yet. This directory exists so the BIOS path could be moved into boot/bios/ without pretending the split was hypothetical.

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 BIOS path fills.

The image goes at EFI/BOOT/BOOTX64.EFI on a FAT ESP, which also means the ISO gains an El Torito EFI entry alongside the BIOS one it already has.