Skip to content
swift-os
Run locally
StatusQuickstartDocsArchitectureDesign Run locally
Deep dive

How swift-os boots

From QEMU firmware to a Swift login prompt in under a second — deterministic, signed, and easy to reason about.

2 Jun 2026 · 7 min read

A boot is a chain of trust and a sequence of handoffs. swift-os keeps both short, and treats boot time as a product feature.

The chain

  1. Firmware — QEMU virt, or a UEFI environment that loads BOOTAA64.EFI and calls ExitBootServices.
  2. The kernel takes over at EL1, brings up an early UART console, builds translation tables, and enables the MMU.
  3. It initializes the GIC and the generic timer, then the scheduler and process substrate.
  4. It mounts the three storage tiers: a signed, read-only packed base, a RAM tmpfs at /tmp, and — when a data disk is present — the persistent /data filesystem (datafs).
  5. It spawns /bin/swos-init → /bin/console-login → the shell.

Why determinism matters

Boot defers optional drivers, services, and diagnostics until after the first shell runs, and favors packed precomputed metadata over probing loops. Every boot starts from the same known-good, signed image — so a boot is reproducible, and /tmp being volatile is a feature, not a limitation. Both the direct -kernel path and the UEFI/GPT path are tested on every change, on 1 CPU and -smp 4.

← All
Articles