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
37 lines
1.9 KiB
Markdown
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).
|