Replace every em dash with real punctuation (rewrites, not hyphen swaps)
in docs, code comments, scripts, configs, and the port records; convert
en dashes, curly quotes, ellipsis glyphs, arrows, and section signs to
ASCII; drop machine-writing tell phrases from living docs. ADR titles
now use a colon. The M2 bring-up DTS model string carried an em dash
into the patch series and its record echoes; fixed at both, and the full
series re-verified to apply cleanly onto pristine 6.18.46. One comment
in freshness.h deliberately names the em dash glyph the UI renders as
the unknown mark; that is data, kept as prose naming it.
Verified: cargo tests (sim, config-lint, rs485-bridge), shellcheck,
both driver MC/DC harnesses, patches-apply.
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
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
BFE Engineering