6.3 KiB
Roadmap and current status
Documentation index · Master plan · M0 evidence
M0–M12 software acceptance is complete. Physical Pi testing is deferred. The user has additionally authorized Dasung base integration: an imported daemon, ARM package, mandatory base selection, and s6 service sources. M2 starts it under native s6 in a booted ARM virtual machine. This is a sequence of acceptance milestones, not a release-date schedule. The user authorized continued implementation through M12, deferring physical Pi testing. Work proceeds in order with software/VM evidence recorded in the implementation ledger.
Current development additionally implements workstation software cartridges and QEMU hotplug tooling. Its acceptance record is separate from the frozen 0.1.0 artifacts below.
Milestones and acceptance boundaries
| Milestone | Status | Deliverable and acceptance |
|---|---|---|
| M0 — Build host | Verified | On x86_64 Arch, bootstrap the pinned Void build environment, cross-build an aarch64 glibc package, and build/inspect a static-musl Rust executable. See the recorded skips below. |
| M1 — Base rootfs | Implemented | fds-base, fds-base-files, and out/rootfs-aarch64.tar with glibc, GNU tools, XBPS and Dasung; no BusyBox, systemd, runit or musl runtime package. Usage · Evidence. |
| M2 — Native s6 | Verified in ARM VM | Native s6 PID 1, read-only root, eudev/getty/Dasung supervision, test-service control, and orderly power-off. Usage · Evidence. |
| M3 — FDS tooling foundations | Verified | Add shared Rust code and CLI/stage0 skeletons; verify static-musl AArch64 artifacts without a glibc runtime dependency. |
| M4 — Pi boot | Software verified; hardware deferred | Kernel/initramfs/SYSTEM/boot-volume builds and nine VM boot cases passed. The ordinary-user prompt follows in M5; physical NVMe/RP1/display acceptance is deferred. Evidence. |
| M5 — Fast console | Software verified; physical timing deferred | Ordinary-user console, boot tracing and regression checks passed. Evidence. Physical performance targets remain unmeasured. |
| M6 — Cartridge daemon | Software verified; physical calibration deferred | Handle events, configured 12-bay topology, metadata, mounting, and eject; virtual hotplug checks passed. Twelve-device stress follows in M11 and physical calibration remains deferred. |
| M7 — DATA integration | Software verified; physical media behavior deferred | Integrate data/home mounts and safe eject; leave the filesystem clean after sustained writes and ejection. |
| M8 — WindowMaker | Software verified; physical display deferred | Xorg/WindowMaker, grayscale theme, ENVIRONMENT activation, managed PROGRAMs and Ethernet passed virtual display/network tests. Usage · Evidence. |
| M9 — Media tools | Software verified; physical media behavior deferred | ARM image creation, protected and confirmed writes, readback verification, and boot of a newly written SYSTEM passed. Usage · Evidence. |
| M10 — Shutdown | Software verified; physical timing/durability deferred | Ordered native halt/reboot, busy refusal, persistent DATA faults and independent filesystem checks passed. Usage · Evidence. |
| M11 — Hardware stress | Software verified; physical tests deferred | Twelve-device cold/hotplug and I/O stress, native reboot/halt, readiness independence and six media failure cases passed. Usage · Evidence. |
| M12 — Production hardening | Software verified; hardware deferred | Signed local FDS/OS 0.1.0, exact frozen inputs, two matching offline builds, recovery/internal settings, documentation and reversible EEPROM previews. Final evidence. |
Detailed requirements remain in sections 53–65 of the master plan. The ledger distinguishes implemented software, remaining work, and tests that still require physical hardware.
What M0 completion means
The initial validation successfully ran make bootstrap, make smoke-test, and
make check. It produced and inspected an actual ARM glibc GNU hello package and
an actual static-musl ARM Rust executable. It also checked failure cases for ELF
validation, source pin drift, modified upstream files, and overlay conflicts.
It did not run the ARM program in QEMU, boot a Pi, test a physical bay map, or measure boot/shutdown performance. QEMU was absent and was explicitly reported as an optional skip. The later snapshot and offline-build work belongs to M12. See M0 validation for the exact environment, outputs, and hashes.
From native init to cartridge boot
M1 changes the output from isolated test artifacts to a base operating-system filesystem. Its first result is a rootfs archive with an explicit package set and exclusions. That archive alone will not establish native init or Pi boot; those are M2 and M4 acceptance boundaries.
M2 now boots that filesystem with a generic ARM kernel and exercises native
s6 supervision. make init-test automates the acceptance test; make vm opens
a temporary development shell. Neither supplies a Pi boot image or measures
physical boot performance. M3 adds verified FDS Rust foundations;
tooling usage explains its commands. M4's boot guide
covers the Pi kernel, initramfs, SYSTEM image, boot volume, and full stage0 tests.
Find the current command interface
The master plan includes a design directory sketch as well as runtime commands. The checkout now implements the complete build interface, cartridge inspection and media management, and native power-off/reboot. A few script locations and configuration formats differ from the original sketch; the implementation ledger maps those entries to the actual interfaces. Use Development for targeted rebuilds and the project overview for the complete build/VM path.
Use make help to inspect the current build entry points. Follow
Your first build for the complete usable workflow today.