| Filename | Latest commit message | Latest commit date |
|---|---|---|
f4107177ea
Reported from a real laptop booting through Ventoy: the F8 menu appears, selecting Boot SchOS gives a black screen and a white dash in the corner. Both halves of that are bugs. The disc could not be chainloaded. Booting it directly, firmware runs the El Torito FAT image and the loader opens \schos\kernel on that volume, which is where mkiso.sh put it. Ventoy does not use El Torito at all: it mounts the ISO 9660 tree and runs \EFI\BOOT\BOOTX64.EFI from there. The loader then looks for the kernel on the volume it was itself loaded from -- the ISO tree -- and the kernel was only ever inside the FAT image. It is now in both. The comment in mkiso.sh had even described this failure, as the reason the kernel is in the FAT image, without noticing the ISO tree had the same requirement. The error was invisible. print() redirects to the serial port once the splash is up, which is right for a development machine and useless on a laptop: the loader died with a perfectly good explanation and sent it to a wire nobody was holding. What is left on screen is the firmware's own cursor -- the white dash. die() now draws the message on the framebuffer too, over a cleared band so it does not land on the logo. Verified by reproducing the exact failure: the ISO tree extracted and booted as a plain volume, as a chainloader presents it. With the kernel removed it dies visibly with "no kernel at \schos\kernel or \kernel, EFI status 0x000E" -- EFI_NOT_FOUND, which is what the laptop was hitting silently. With it present, that same volume boots through to a shell. 110 [ok] on the ESP path, the ISO check passes, no failures. |
||
| .. | ||
| efi.h | ||
| main.c | ||
| README.md | ||
| startup.nsh | ||
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:
- 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 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.