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 93d3b123c5 uefi: stage what the firmware still holds; copy it home after it exits 
The kernel goes at fixed physical addresses, 1 MB to about 34 MB with
the RAM disk inside it. When AllocatePages refused part of that, the
loader said "could not reserve" and read the kernel there anyway -- over
the firmware's own memory, with the firmware still running on it. An HP
all-in-one from 2012 froze at the start of the loading bar.

Now every free page of the range is claimed first. A segment wholly on
claimed pages is read straight home; one that is not is read into a
buffer elsewhere and copied home after ExitBootServices, when
boot-services memory is ours. Memory under the kernel that outlives
the firmware (ACPI NVS, runtime services) is named, and so is the loader
or its stack sitting in the range.

Segments are read a megabyte at a time, so the bar moves through the
RAM disk and shows where a machine stopped.

Under OVMF the data segment (over ACPI NVS and boot-services data at
8 MB) is now staged, and it boots both as a CD and as a USB disk.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2026-10-24 00:04:17 +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: stage what the firmware still holds; copy it home after it exits 2026-10-24 00:04:17 +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.