Every sigilOS test to date has run in QEMU. That changes now. The Director has directed the fleet to produce a bootable x86-64 disk image that runs sigilOS on real hardware — UEFI boot, GOP framebuffer, real AHCI/NVMe, real PCI enumeration. This is the first real-silicon acceptance artifact and the first entry in the Hardware Compatibility Program (sigil-os#17). (sigil-os#18)
Why QEMU isn't enough
QEMU is fast and deterministic, which is why the entire fleet has run inside it. But QEMU fakes exactly the parts that real hardware doesn't: it uses its own UEFI stub instead of real firmware, provides a software VGA instead of a real GOP framebuffer, and stubs out AHCI/NVMe timing, real PCI enumeration, and real ACPI tables. A sigilOS build that passes 336/336 MANIFEST tests in QEMU has never seen any of those things.
The x86-64 boot image forces every one of them to be real. UEFI GetMemoryMap, the GOP blit address, ACPI table walking, PCI config space, xHCI timing — all real, all on grioghar's box. This is the batched real-hardware acceptance pass, pulled forward now that the OS is far enough along to run it.
Deliverable
sigilos-x86_64-test.img — a raw disk image (dd or Rufus to USB stick) that POSTs on a real x86-64 PC and brings the OS up. UEFI first; legacy-BIOS/CSM as a stretch goal. The image is cc0-emitted — no Python in the product path. Boots are non-destructive: the image runs from USB and does not touch internal disks.
Three milestones
Each milestone is gated on a real-hardware screendump on grioghar's box — not a QEMU screendump.
UEFI stub → kernel long-mode entry → serial + GOP framebuffer banner. Proves the boot path from UEFI handoff through BOOTX64.EFI, memory map via GetMemoryMap, and the real GOP framebuffer base address on real firmware. This is the acceptance gate for the whole boot path — if M1 passes, the kernel is running on real silicon.
COTS drivers enumerate grioghar's actual hardware: storage (AHCI or NVMe), USB (xHCI keyboard), NIC. The hw-probe app (sigil-os#17) auto-runs and prints a hardware profile — grioghar's box becomes HCL entry #1, and the profile tells the fleet exactly which drivers need to be confirmed on this specific hardware combination.
GOP/VESA framebuffer → compositor → the Lumen login screen on real display hardware, with USB HID keyboard and mouse live. This is the same Lumen desktop already verified in QEMU, now running on the real GPU's linear framebuffer. M3 ties directly to sigil-os#19 (login screen visual fix) — the first screen on grioghar's real hardware should be the polished one.
What's different on real hardware
| Component | QEMU (verified) | Real hardware (M1–M3) |
|---|---|---|
| Firmware | QEMU UEFI stub (OVMF) | Real motherboard UEFI firmware |
| Memory map | Fixed QEMU layout | UEFI GetMemoryMap (variable, firmware-supplied) |
| Framebuffer | QEMU VGA / Bochs VBE | GOP linear framebuffer (real GPU) |
| Storage | virtio-blk | AHCI or NVMe (COTS driver) |
| USB | QEMU xHCI (emulated) | Real xHCI controller, real timing |
| PCI | QEMU PCI bus (enumerable) | Real PCI config space + ACPI tables |
| Network | virtio-net | Real NIC (driver confirmed by hw-probe M2) |
Guardrails
- Non-destructive. The image runs from USB. It does not touch grioghar's internal disks, does not partition, does not install. Boots are read-only observers of the hardware.
- Sigil-only, capability-secure. No ambient authority in the booted image. The same capability model that runs in QEMU runs on real silicon —
Cap<Display>for the framebuffer,Cap<Storage>for disk access, etc. - cc0-emitted. The image is built by cc0, not by a Python script or a shell pipeline. No Python in the product path.
- Reproducible. The same source tree produces the same image byte-for-byte. This is a requirement for the Hardware Compatibility Program (sigil-os#17).