| Filename | Latest commit message | Latest commit date |
|---|---|---|
9735279970
find_rsdp() scanned the EBDA and 0xE0000-0x100000. That is a BIOS convention, and UEFI firmware is under no obligation to leave a copy there -- OVMF does not. So the kernel found no RSDP, no MADT and no IOAPIC, and nothing routed IRQ 4. Serial output is polled, so the machine booted all the way to a shell prompt and then ignored every key, which reads as a broken console rather than a missing table. The UEFI loader reads the RSDP out of the EFI configuration table, preferring ACPI 2.0 for its XSDT, and leaves it at SCHBOOT_RSDP_ADDR -- the same low-memory hand-off block the e820 map already uses, now described in include/schboot.h so the two sides cannot disagree. The kernel validates it rather than trusting it: the BIOS path never writes that slot, so there it holds whatever was in memory, and following a wild pointer faults before there is anything to report the fault with. Signature and checksum do that. It deliberately does not require 16-byte alignment -- that rule is about searching the BIOS area, and OVMF's RSDP sits at 0x3f77e014, so demanding it threw away the one address this code exists to use. UEFI now reports "acpi: 1 cpu, lapic at ..., ioapic id 0" and the ISO boots to an interactive shell: uname, ls /bin (241), writing and reading a file, ps, /proc/schfs -- all driven over serial. BIOS unchanged: bootcheck 108 [ok], same ACPI line as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .. | ||
| efi.h | ||
| main.c | ||
| README.md | ||
| startup.nsh | ||
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:
- 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. - 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. GetMemoryMaptranslated into the same 24-byte entriese820.calready parses. Not a second format for the kernel to learn.ExitBootServicesbefore touching the memory it described.- Graphics Output Protocol for the framebuffer, filling the same
VBE_INFO_ADDRstructure 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.