BFE EngineeringandClaude Opus 4.8
4ee4dfcf88
First recursive code-review-harness pass over the authored SDK code (sim/,
config-lint, flowgen, drivers/{relays,freshness}, build/, ci.yml). Four parallel
dimension reviewers; all findings at every severity corrected per workspace rule.
Correctness / reliability:
- freshness.c min_budget_ms: use a `seen` flag, not `best==0`, as the empty
sentinel — a zero-tolerance (max_stale_ms==0) binding was silently widened to a
looser neighbour's budget. Regression test added; still 66/66 MC/DC.
- config-lint parse_reserved_ranges: match `reg` as a whole property token (ident
boundary before, `=` after) so `reg-names` / a `region-*` label no longer
mis-parses into a bogus reserved range.
- config-lint loader check: fail closed — flag any loader with a LOAD_ADDR that is
not a known-safe boot component, instead of only known MCU names, so a future
coprocessor ("Rtos"/"Bl32") can't slip past the 0x40000-brick gate.
- build-kernel.sh: sha256 verification is now mandatory (refuse to build if the pin
is missing) and the mktemp scratch tree is removed on exit (trap), while a
caller-provided WORK is left intact for CI artifact upload.
Test quality:
- freshness: added the age==max_stale boundary case and a clock-wraparound
(now < last_ok) fail-safe-to-UNKNOWN test.
- relays: unsetenv(WARDEN_GPIO_ROOT) at main() so the NULL-env arm is hermetic.
Security / CI:
- ci.yml: top-level `permissions: contents: read` (badges overrides to write);
pin taiki-e/install-action to commit SHA (v2.86.7).
Maintainability / docs:
- drivers/enforce-mcdc.sh: one shared, name-derived gate replaces the two
copy-pasted per-driver scripts; Makefiles call ../../enforce-mcdc.sh.
- docs/architecture.md: §3/§4/§6/§7 rewritten to match reality — NPU/RGA models,
config-lint, and the relays+freshness MC/DC harnesses are done; kernel §6 now
reflects the 5.10->6.18.46 forward-port (ADR-0001), not the superseded plan44/6.6.
- README: status blurb + layout table corrected (kernel/, .github/; stale ci/ and
patches/ descriptions fixed). hpmcu "8 tests" -> 7 in docs.
- freshness.{c,h}: ADR reference points at flare-edge ADR-0004 (warden-sdk's
ADR-0004 is the CI runner — number collision).
- normalize rustfmt drift across sim/ + config-lint.
All green: sim 37 tests, config-lint 8 tests, both drivers 100% MC/DC (relays
40/40, freshness 66/66), clippy clean under -D warnings, gitleaks clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
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 ours,
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 our board'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.