# M4 software boot validation

Development reference and historical context. For current operating instructions, use the [user manual](../README.md). Acceptance applies only to the source and artifacts identified in each record.


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:

```text
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](boot.md) to reproduce these artifacts and understand the
distinction between a boot partition, SYSTEM cartridge and complete internal disk.