SchOS/boot/uefi/README.md
Nexoniarz dee3affa3b Boot manager: Niveus window, keys and wells, Instrument Sans, pointer, other systems, working power entries
The F8 menu is redrawn in the Niveus language: a window with three lights,
bevelled keys with a lit edge, wells for panels, anti-aliased corners and a
soft shadow, set in Instrument Sans rasterised into include/gfx/nvfont.h
(tools/python/mknvfont.py, make nvfont). Scale doubles on screens 1400 px tall
or more. Lists taller than the screen scroll.

The keyboard still drives everything, and a mouse, touchpad or tablet does
too: both UEFI pointer protocols are polled, hover moves the highlight, a
click activates. The cursor stays hidden until the pointer has really done
something, since the firmware installs a pointer protocol with or without a
mouse. The 'keep this resolution?' countdown is one ten-second budget however
many times the pointer moves.

Loaders found at well-known paths on any volume (Windows, Ubuntu, Debian,
Fedora, Arch, openSUSE, systemd-boot, rEFInd, other BOOTX64.EFI) are listed
and chain-loaded with LoadImage/StartImage. 'Reboot to firmware' used to halt;
it now sets OsIndications and restarts, and Restart and Shut Down call
ResetSystem.

Checked under QEMU+OVMF: menu, resolution list (incl. 2560x1600 at double
scale), system information, shut down, firmware setup, chain-loading a copy of
the loader from a second disk, and a full boot of the ISO to the login prompt.
Pointer hover and click were checked only with synthetic events: in this setup
a USB mouse or tablet delivered no event to the loader (one USB I/O handle
appeared but no pointer protocol came from it), and why was not established.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
2026-10-26 15:31:39 +01:00

37 lines
1.9 KiB
Markdown

<!-- SPDX-License-Identifier: GPL-2.0-or-later -->
# 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:
1. 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.
2. 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.
3. `GetMemoryMap` translated into the same 24-byte entries `e820.c` already
parses. Not a second format for the kernel to learn.
4. `ExitBootServices` before touching the memory it described.
5. Graphics Output Protocol for the framebuffer, filling the same
`VBE_INFO_ADDR` structure 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.
## The boot manager
`F8` (or `o` on a serial line) opens a Niveus-styled boot manager, drawn by
`../common/ui.c` in Instrument Sans (`include/gfx/nvfont.h`, regenerate with
`make nvfont`). It takes keyboard and pointer, lists other systems it finds on
the disks and can chain-load them, and has working Firmware Setup, Restart and
Shut Down. See [docs/architecture/boot.md](../../docs/architecture/boot.md#the-boot-manager).