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

48
boot/cdboot.S
View file

@ -1,48 +0,0 @@
# Stage 1 for optical media -- the El Torito "no emulation" boot sector.
#
# This exists because bootasm.S cannot boot a CD. It loads stage 2 by talking
# straight to the primary IDE controller's ATA registers, and a CD is not an
# ATA disk: it answers to the ATAPI packet interface instead, and under
# El Torito it may not even be the drive at 0x1F0. Rather than teach a
# 512-byte sector two protocols, optical media get their own first stage.
#
# It has almost nothing to do, because El Torito's "load segment / sector
# count" fields do the reading for us: tools/mkiso.sh asks for
# 1 + STAGE2_SECTORS virtual sectors at 0x7C00, so by the time this runs the
# BIOS has already placed stage 2 at 0x7E00 -- exactly where bootasm.S would
# have put it. The only real work is recording *which* medium we came from,
# since stage2main.c has to read the kernel back with the matching protocol.
#
# The flag goes next to the verbose-boot flag, one byte past it, for the same
# reason that one sits where it does: it is clear of the 256-byte VBE mode
# info block at 0x30000 that stage2.S fills in a moment from now.
#define STAGE2_ADDR 0x7E00
#define BOOT_MEDIA_FLAG_SEG 0x3000
#define BOOT_MEDIA_FLAG_OFF 0x101
#define BOOT_MEDIA_CD 1
.code16
.global start
start:
cli
xorw %ax, %ax
movw %ax, %ds
movw %ax, %ss
movw $0x7c00, %sp
# "You were booted from a CD." stage2main.c reads this to decide between
# ATA and ATAPI; without it the loader would read the kernel off whatever
# happens to be sitting at 0x1F0, which on a CD boot is usually nothing.
movw $BOOT_MEDIA_FLAG_SEG, %ax
movw %ax, %es
movw $BOOT_MEDIA_FLAG_OFF, %di
movb $BOOT_MEDIA_CD, %al
movb %al, %es:(%di)
# stage2.S expects zeroed segments and an inherited stack, same as it gets
# from bootasm.S.
xorw %ax, %ax
movw %ax, %es
ljmp $0, $STAGE2_ADDR