Files
bfe-core1106-sdk/qemu/payload/README.md
T
BFE Engineering c756622c96 docs: reposition as the 86 Panel development environment
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
2026-08-30 22:19:12 -06:00

976 B

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:

# flared (static musl armv7)
tools/build-flared.sh --local
# warden-modbus and friends: see tools/build-firmware.sh for the recipes

Then:

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.