BlackMark
be78f38f3f
The pin crosses libavr's phase-6 close and the guideline sweep behind it. All 37 chips green, 43 tests each, the README size table matching every built image, and all 13602 flash images byte-identical to the previous pin. The bump broke one gate and exposed another as ornamental. `check_unit.cmake` matched the autobaud loader's measured unit by the symbol `unit_E`; libavr's rule-46 sweep renamed the member to `m_unit`, which the mangling spells `6m_unitE`. On the RAM-home chips the check went red and said so. On the GPIOR chips it went green - the branch that asserts the unit is *not* in RAM passes on an empty match, and an empty match is what a stale regex returns for every image. Both branches mean something again. `tools/check.sh` ran the 37-chip loop under `set -e`, so the first red chip ended the gate and the 36 behind it were never built - a stale size canary on attiny13 would have been an alibi for every loader after it. It accumulates now and fails at the end naming every red preset, which is the shape libavr's own check.sh carries and the reason it carries it. The port's own sweep, verified by byte identity: the four TSB tiers' 16-byte info block is `std::to_array` rather than an extent written beside the sixteen elements the compiler can count, the three-member serial and loader configs break one member per line, the turn-around loops are braced, and the test fixture's config pair is a deduced `std::array` (rules 36, 40, 34). Two comments stop narrating how the code came to be and one stops citing a repro at a path it left two phases ago (rules 12, 13). pureboot's identity stamp stays the raw array rule 36 bans, and now says why: its reads must fold to immediates because the bytes are in program memory and a formed address is dereferenced as data space. As a `std::array` the read loop stopped unrolling and emitted exactly that - measured at +8 B and a wrong answer on the wire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB