BFE Engineering
c756622c96
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
1.7 KiB
config-lint
Static target-config gates: catches flash-time config faults the behavioural sim cannot: mistakes in the
memory map, not the logic. The first check is the one that would have caught the
c8a3 brick — a boot-loaded coprocessor firmware dropped at 0x40000, which is
a reserved-memory carve-out on Thunder-Boot boards but plain kernel RAM on the 86 Panel,
so the MCU and the kernel fought over the same DRAM and the board hung before eth0.
The check
Every address the idblock loader drops MCU firmware to must sit inside a
reserved-memory node in the target devicetree.
- MCU loads come from the rkbin loader
.ini: eachLOADERn=Hpmcu(any hpmcu/mcu/amp entry) in[LOADER_OPTION], with itsLOAD_ADDRfrom[LOADERn_PARAM]. - Reserved ranges come from the devicetree: every
reg = <addr size>inside areserved-memory { … }node.
A load outside all reservations is a failure (non-zero exit).
Use
cargo run -p warden-config-lint -- --ini <loader.ini> --dt <devicetree.dts>
In CI, feed the flattened devicetree so includes and overlays are resolved:
dtc -I dtb -O dts build/.../rv1106g-warden.dtb > /tmp/warden.dts
config-lint --ini .../RKBOOT/RV1106MINIALL*.ini --dt /tmp/warden.dts
Exit 0 = every MCU load is reserved (or there are none); 1 = a collision was
found; 2 = usage/IO error.
Test
cargo test -p warden-config-lint
The suite encodes the brick as a regression: the real Thunder-Boot .ini
(Hpmcu @ 0x40000) fails against a DT with no rtos@40000 node and passes
once the reservation is added — and the 86 Panel's non-TB loader (no boot-loaded MCU)
always passes. See ../../docs/architecture.md §5 and, for the hardware hazard,
the boot-loaded-mcu-0x40000-hazard note.