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
- tools/flowgen.py: generates docs/workflows/<name>.md — one outcome-first mermaid
flowchart per workflow the SDK tests (hpmcu watchdog, modbus read, cru ladder,
rga offload, relay drive, freshness contract), each stamped with its benchmark
ns/op or 100% MC/DC result. Deterministic; reads the cargo-bench trend json.
- drivers/README.md: honest Tier-1 (relays + freshness, 100% MC/DC here now) vs
Tier-2 (modbus/rga — serious testing + fault-injection + benchmarks via sim
models; driver sources migrate in with the flare-edge unification) per ADR-0002/0005.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
Registered a 3rd repo-scoped runner on bfe-mpc-0640 (label warden-sdk,
bfe-mpc-0640-warden-sdk) per ADR-0004. It is offline pending the sudo-gated steps
(service install + CPUQuota/MemoryMax cgroup cap + toolchain/python provisioning),
documented in docs/ci-cd.md as a [maintainer] handoff. kernel-build stays dispatch-gated
and passes JOBS=4 as a belt-and-braces resource bound.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
Investigated whether the RV1106 NPU (RKNPU) could do 3D rendering or other
graphical work as we port its driver to 6.18. Verdict: no. Read the vendored
rknpu driver directly — it executes a pre-compiled regcmd list from Rockchip's
closed RKNN compiler; no register ISA, no arbitrary-kernel submit path. Only the
vertex-transform stage (GEMM) maps at all, and rasterization/depth/texture/
shading/framebuffer have no mapping to a conv/pool op set — absent, not slow. For
every CNN-shaped graphical candidate the SoC already has a better fit (RGA 2D,
idle RKIVE classic-CV), and there's no camera. Recommend porting rknpu.ko only
for future non-visual inference, never for graphics.
Caveat flagged in the doc: the no-rasterizer claim is from the RKNN op taxonomy +
architecture, not register-level ground truth (TRM Part 2 is unpublished).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
The device counterpart to warden-modbus's master/scanner: request-frame in,
response-frame out, in host memory. CRC16 is byte-identical to the master
(poly 0xA001, low-first; known vector 01 03 00 00 00 01 -> 84 0A verified).
Implements the data plane — read/write holding & input registers, coils,
discrete inputs (FC 0x01-0x06, 0x0F, 0x10) + Report Slave ID (0x11) — with
exception replies (illegal function/address/value) and the two real-world
faults the master must survive: a device that silently ignores a request
(drop_next) and one that NAKs everything (force_exception). This is what the
modbus-master MC/DC harness drives against; MEI (0x2B/0x0E) is a follow-up.
11 tests, sim crate 25/25 green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
The c8a3 brick was a memory-map fault no behavioural sim can catch: 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. config-lint is
the static gate for it — parse the rkbin loader .ini for every LOADERn=Hpmcu
LOAD_ADDR, parse the target devicetree for reserved-memory ranges, fail if any
MCU load lands outside a reservation.
Tests encode the brick as a regression against the REAL Thunder-Boot .ini
(Hpmcu@0x40000): fails with no rtos@40000 node, passes once reserved; our
board's non-TB loader (no boot-loaded MCU) always passes. 6/6 green; CLI
verified against the on-disk rkbin .ini files.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
Models the RV1106 reset ladder + boot-mode register on the MemBus seam, so
flared's devmem::hard_reset ladder and the boot-mode -> MaskRom recovery
maneuver are testable entirely on the host. Bakes in the two hardware facts
that cost real bench time as regression tests:
- the CRU global-reset register is 0xff3b0c08/0xfdb9; the magic at the wrong
offset 0xff3a0614 (from other Rockchip SoCs) is a SILENT NO-OP here;
- the boot-mode register 0xff020200 survives a warm reset (the mechanism that
makes "set MaskRom, then reset" drop the SoC into BootROM download), and a
power-on reset clears it.
6 tests (both rungs, pet, the wrong-offset no-op, MaskRom-survives-warm-reset,
POR-clears-request); the sim crate is 14/14 green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
Grounded in a full survey of the flare-edge firmware: catalogs every hardware
seam (register/MemBus, resource-path env-override, RGA compile-time), the tiered
MC/DC target (our code real MC/DC via the uboot-ab pattern; blobs fault-injection),
the target-config-lint class that the sim CANNOT cover (the 0x40000 brick), and
the ordered plan. Notes the flared<-warden-sim Cargo dep needs a repo remote
([maintainer] go-ahead).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wB8KB3MMQztRDXCMCkPrf
