fds-os/docs/m4-validation.md

M4 software boot validation

Validated on the x86_64 Arch workstation on 2026-09-21 (Asia/Shanghai). Physical Pi testing is deferred by the user. This report establishes the software boot machinery, not the physical NVMe/RP1/display path or performance targets. M5 supplies the ordinary-user FDS console and timing instrumentation.

Verified path

The cross-built Pi 5 kernel loaded the actual Rust-only initramfs, discovered GPT partition identity, mounted EROFS read-only, transferred proc/sys/dev mounts, stopped and reaped the early Dasung controller, and executed native s6. Guest checks confirmed 16 KiB pages, s6-svscan as PID 1, the static packaged FDS CLI, matching module release, loading/unloading the dummy kernel module, and one base Dasung process. Ownership, ping capabilities, volatile filesystems and start/restart/stop of the test service also passed.

The final VM matrix, out/m4-vm.flkV6j/, passed nine cases:

1. Uncompressed initramfs.
2. Gzip initramfs.
3. Legacy-LZ4 initramfs.
4. Zstandard initramfs.
5. No SYSTEM at startup, followed by virtual USB insertion and automatic boot.
6. Two SYSTEMs refused, followed by explicit console recovery.
7. Recovery selected by kernel option while SYSTEM is also present.
8. Invalid SYSTEM filesystem refused, with recovery still usable.
9. Foreign OS root refused, with recovery still usable.

Each case reached the guest checks and orderly power-off. Input image hashes were unchanged. The test uses QEMU 11.1.1, virt, max CPU, TCG, 1 GiB RAM and two virtual CPUs, without networking or host-device passthrough. Its recovery disk is a selection fixture, not the independent M12 recovery product.

The FAT32 boot builder produced a 512 MiB FDS_BOOT partition, checked it with fsck.fat, extracted it with mtools and compared every file hash. Two consecutive builds matched byte-for-byte. Two full kernel builds also produced identical kernel Image, Pi 5 DTB and XBPS package hashes. These narrow reproducibility results do not establish a complete offline release rebuild.

Commands and artifacts

The completed sequence included make kernel, make tooling, make tooling-test, make rootfs PROFILE=cli, initramfs construction, and these final regression gates:

make bootstrap
make smoke-test
make check
make rootfs-test
make init-test
make system-card
make boot-volume
make boot-test
make dasung-test

Final logs are out/logs/m4-final-*.log; rootfs construction is recorded in out/logs/m4-rootfs.log. The configured rootfs is out/rootfs-build.p0HSQv/: 111 packages, 1,168 inspected ARM ELF files, and a 407,009,280-byte tar.

Artifact	SHA-256
Rootfs tar	ba06bdcb8f4fc537c8cb4ce9d31404d3cd1d14f01b41cb597a53ec48f0ba6710
SYSTEM GPT image	d15af6feccbaeba77920e0b5ee13076dbdc80a076c973068a1f68e86bb599bf1
Pi kernel Image	78f027ad3124da7b06d4559f49ea7f63c312cd24e653d0f8e29ee2391f520bc4
Kernel XBPS package	6c361df5bf31ef517b6bad7e44220a8126f7c2fac341379e8c1d6b39fcbe8c20
Uncompressed initramfs	bc8905c5ca40fe827a44f7dd73f88aa1c99a3b84fa474535ccb36a212682b514
Production FAT boot partition	940b7d62ba5923a3f92db6939aca1534f0f2061376c1fec7604a50e6d3b3f0b8

The kernel is 6.12.87-fds1, built from Raspberry Pi commit ae4d75fb36deba0fe1a986d9bfae65755e082dd0 with the FDS configuration delta. Void remains pinned to 02a3cbc132c3c4a3a9d59e9b98f517af5dd11cd1 with no tracked upstream changes. Firmware package/version/hash are pinned in config/pi-firmware.conf. Detailed package inventories and source inputs remain beside each versioned build.

Findings and limits

The original Cortex-A72 VM CPU did not support the retained 16 KiB kernel page configuration; max successfully runs the Pi kernel. A repeated VM test exposed getty's shutdown hangup discarding pending serial output. The checker now stops getty after verifying it and reopens the console before final service checks; no boot delay was added.

The M0 host-PATH QEMU execution remains an optional skip. Actual ARM userspace and full-system VM execution passed using project-local emulators. Physical Pi firmware boot, EEPROM changes, NVMe/RP1, monitor EDID acceptance, image quality, cold-power display recovery, bay wiring/power and real boot/shutdown timings remain explicitly untested.

Use the boot guide to reproduce these artifacts and understand the distinction between a boot partition, SYSTEM cartridge and complete internal disk.