| Filename | Latest commit message | Latest commit date |
|---|---|---|
751f5718cd
The screenshot was mode 16. OVMF advertises it as 1366 wide; asking for it produces a framebuffer QEMU scans out at 1360, so every row written lands six pixels further along than the one above and the whole screen shears. The firmware never says it rounded, and nothing in the mode information hints at it -- PixelsPerScanLine agrees with the width it claims. So a mode is only usable if its width is a multiple of 8, which is the VGA scanout granularity. Checked rather than assumed: 1400x1050 and 1280x720 render perfectly centred, 1366x768 does not, and it is the only advertised width that is not a multiple of 8. The single cycling row is now a list. Every usable mode the firmware offers, deduplicated -- it advertises the same geometry several times with different internals, and a menu with 1280x1024 in it three times is one nobody trusts -- plus a row for typing a size. A typed size is matched against the same filtered list, so a mode that would shear cannot be reached by typing it either, and a size that does not exist says so rather than silently keeping the old one. Also fixes the panel layout you spotted: the title band was exactly as tall as the heading, so the rule was drawn through the lettering and the first row sat on its baseline; and the selected row's highlight had a fixed 3px offset against a 24px row, so it sat on the text rather than around it. Verified by applying four resolutions from the list -- 1280x800, 1024x768, 1280x960, 1600x1200 -- and checking the panel is centred in each. bootcheck 108 [ok]. BIOS still asks in a text prompt before the framebuffer exists, and that is the remaining half of "the same for both". See the next commit message or the note in stage2.S: VBE is INT 10h, so it needs real mode, and a graphical chooser needs either unreal mode before the switch or a return to real mode after it. 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.