0500e4382d
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>
46 lines
1.8 KiB
ArmAsm
46 lines
1.8 KiB
ArmAsm
# 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
|
|
#include "../../include/schboot.h"
|
|
|
|
.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 $SCHBOOT_MEDIA_SEG, %ax
|
|
movw %ax, %es
|
|
movw $SCHBOOT_MEDIA_OFF, %di
|
|
movb $SCHBOOT_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
|