1.8 KiB
M3 static Rust tooling validation
Validated on 2026-09-21 (Asia/Shanghai), x86_64 Arch Linux with pinned Rust 1.98.0. This records the M3 diagnostic foundation before M4 adds the real boot handoff. See tooling usage and the through-M12 ledger.
Commands completed successfully:
make tooling
make tooling-test
make bootstrap
make smoke-test
make check
Both exported binaries were AArch64 static ELF executables without a dynamic
interpreter, shared-library requirements or GLIBC symbol requirements. Supplemental
ldd printed not a dynamic executable. At this milestone:
| Artifact | Bytes | SHA-256 |
|---|---|---|
out/fds |
537424 | 04052554eef3c592230aa912d6dbcaec9bc37c168c0e240b924a4fb215a68815 |
out/fds-stage0 |
375824 | 930afd537aaf8e90715e5ec73d70480b44fbe9dfe3c0615014ed78b36239bd7c |
Six shared-library tests passed. Actual ARM execution then verified tool identity, JSON output, the master-plan manifest example, strict/bounded manifest rejection, missing/unique/ambiguous SYSTEM selection, device-path rejection, explicit recovery selection, and duplicate boot-option rejection. All filesystem fixtures were temporary; no physical block device or monitor was accessed.
Build/source hashes are in out/manifests/fds-tools*.sha256; logs are in
out/logs/m3-tooling.log, m3-tooling-test.log, m3-bootstrap.log,
m3-smoke-test.log, and m3-check.log. Later milestones will replace these tool
artifacts; the hashes above describe the validated M3 version.
The M0 smoke script's optional host-PATH QEMU execution was skipped, as before; the M3 integration script explicitly ran both ARM tools using container QEMU. No physical Pi result or boot-speed claim is made. M3's stage0 refused normal boot invocation rather than claiming its diagnostic skeleton could switch roots.