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

boot: separate BIOS from UEFI

Browse source 
boot/bios/ now holds the MBR, the El Torito stub and the real-mode stage
2; boot/uefi/ is empty and documented.

Separate directories rather than #ifdefs, because the two share almost
nothing. A BIOS loader lives in 16-bit real mode, reaches the firmware
through software interrupts, and walks itself up into long mode. A UEFI
loader is a 64-bit PE that the firmware has already placed in long mode
with paging on, calling services through a table of function pointers.
What they do share is the hand-off contract, which boot/README.md now
writes down: ELF segments placed, long mode, a 24-byte-entry memory map
at E820_MAP_ADDR, framebuffer geometry at VBE_INFO_ADDR.

That contract is the point of documenting it now. UEFI's GetMemoryMap
returns EFI_MEMORY_DESCRIPTORs, and the right move is to translate them
into the entries kernel/arch/x86_64/e820.c already parses rather than
teach the kernel a second format.

Build output paths under $(BUILD)/boot are unchanged; only sources moved.
This commit is contained in:
Nexoniarz 2026-08-09 16:00:03 +02:00
commit 08a1a9033a
19 changed files with 125 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

28
boot/uefi/README.md Normal file
View file

@ -0,0 +1,28 @@
<!-- SPDX-License-Identifier: Apache-2.0 -->
# 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.