The repo's documentation framed it as a support repo for one product (WardenOS). Since going public the real audience is anyone with a Luckfox Pico 86 Panel: a maintained 6.18 kernel, an off-device development loop, and a device simulator that exist nowhere else for this board. Reframe the README and top-level docs board-first, with WardenOS documented as the downstream consumer it is (ADR-0008). Also an editorial pass over the whole doc set: - every H1/H2 is now a short title, not a sentence (ADRs, qemu/, patches/, drivers/, architecture, NPU feasibility, config-lint, payload); workflow flowchart titles fixed at the source in tools/flowgen.py and regenerated with fresh bench numbers - README Quick Start commands verified against the scripts; requirements corrected (curl, bare python, gcc >= 14) and the MC/DC gate added as a step (run green locally on gcc 14.2) - dropped the 'needs python (not python3)' vendor dig: build-kernel.sh inherited the same requirement (filed #10 to remove it) - glossed MC/DC and HPMCU on first use; marked the tests/uboot-ab reference as flare-edge; deduplicated the three-simulator list into the root README table
27 lines
976 B
Markdown
27 lines
976 B
Markdown
# Guest Payloads
|
|
|
|
Drop **static musl armv7** binaries in this directory (contents are
|
|
gitignored — binaries are never committed); `qemu/mkimage.sh` copies everything
|
|
in this directory (except this README) into `/usr/bin/` of both rootfs slots.
|
|
Static musl is the same target the device uses for its Rust daemons, so the
|
|
exact production binaries run unmodified in the VM.
|
|
|
|
Typical payload, built in a flare-edge checkout:
|
|
|
|
```sh
|
|
# flared (static musl armv7)
|
|
tools/build-flared.sh --local
|
|
# warden-modbus and friends: see tools/build-firmware.sh for the recipes
|
|
```
|
|
|
|
Then:
|
|
|
|
```sh
|
|
cp <flare-edge>/target/armv7-unknown-linux-musleabihf/release/warden-flared qemu/payload/
|
|
```
|
|
|
|
Stage-2 init starts `warden-flared`, `warden-modbus`, and `warden-ui` (the
|
|
UI additionally needs `--display on|headless` + the virt.fragment kernel for
|
|
/dev/fb0) automatically when present (logs land in `/tmp/<name>.log` inside
|
|
the guest). An empty payload is valid — the image boots busybox-only.
|