rajamesandClaude Opus 5.5
3b49cb15a2
Captain Bob, 2026-10-14: "change to PC, not SER5. it's not supposed to be specific, but PC generic." boards/ser5 -> boards/pc, TARGET=PC, lithos-pc.img; the image was never specific to one machine (the generic UEFI/ACPI path, FABRIC-3 III). The Beelink SER5 stays named where the text means the unit on the bench (its Secure Boot, BIOS, serial header) and in the records. Built: lithos-pc.img, system=v4, with its SBOM. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PC boot media (generic x86-64, UEFI)
make boot_image TARGET=PC builds build/boards/pc/lithos-pc.img: a GPT disk with one FAT32
EFI System Partition, for any x86-64 PC whose UEFI firmware boots a removable medium. Write it to
a USB stick with dd. The partition holds:
EFI/BOOT/BOOTX64.EFI: the amd64 monolithic loader, with the whole kernel embedded. Firmware finds it through the UEFI removable-media path, so no boot entry has to be created.startup.nsh: runs the loader if the firmware drops into the UEFI shell.starforth.cfg: the boot arguments --system=v4as built; change the word tosystem=v3to boot v3 (andKERNEL_ARGS="..."adds to it).
Beside the image, lithos-pc.spdx / .spdx.json: its SBOM, every file on it with its SHA-256.
Nothing in the image is specific to one machine: it follows the generic UEFI/ACPI path in
FABRIC-3.md §III. Until 2026-10-14 this target was named SER5, after the first PC to be brought
up -- a Beelink SER5 (AMD Ryzen), which is still the one on the bench (boards/BRINGUP.md).
Status: booted in QEMU (q35 + OVMF, from this image as its own disk): v4 as built, v3 with
system=v3. Not yet booted on real hardware.