avr/bootloader
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

build: the libavr pin advances past the audit sweep, and two gates start meaning something

Browse Source 
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>
This commit is contained in:
BlackMark
2026-08-12 15:05:07 +02:00
parent d3d8d07905
commit be78f38f3f
12 changed files with 78 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
test/check_unit.cmake
View File

@@ -11,26 +11,26 @@ if(NOT _res EQUAL 0)
message(FATAL_ERROR "${OBJDUMP} -t ${ELF} failed")
endif()
# The symbol line: "00800100 l O .noinit 00000002 <mangled>unit_E".
string(REGEX MATCH "\n0*([0-9a-f]+)[^\n]+[ \t][^ \t\n]*unit_E\n" _line "${_syms}")
# The symbol line: "00800100 l O .noinit 00000002 <mangled>6m_unitE".
string(REGEX MATCH "\n0*([0-9a-f]+)[^\n]+[ \t][^ \t\n]*6m_unitE\n" _line "${_syms}")
if(GPIOR)
if(_line)
message(FATAL_ERROR "unit_ RAM symbol present although the unit's home is GPIOR ${GPIOR} - "
message(FATAL_ERROR "m_unit RAM symbol present although the unit's home is GPIOR ${GPIOR} - "
"the host peeks the pair, and a RAM copy would be dead weight")
endif()
message(STATUS "no unit_ RAM object - the unit lives in the GPIOR pair at ${GPIOR}")
message(STATUS "no m_unit RAM object - the unit lives in the GPIOR pair at ${GPIOR}")
return()
endif()
if(NOT _line)
message(FATAL_ERROR "no unit_ symbol in ${ELF} - is this the autobaud loader?")
message(FATAL_ERROR "no m_unit symbol in ${ELF} - is this the autobaud loader?")
endif()
# AVR data-space symbols carry the 0x800000 VMA offset.
math(EXPR _want "0x800000 + ${RAM_START}" OUTPUT_FORMAT HEXADECIMAL)
math(EXPR _have "0x${CMAKE_MATCH_1}" OUTPUT_FORMAT HEXADECIMAL)
if(NOT _have STREQUAL _want)
message(FATAL_ERROR "unit_ sits at ${_have}, ram_start is ${_want} - the host peeks ram_start")
message(FATAL_ERROR "m_unit sits at ${_have}, ram_start is ${_want} - the host peeks ram_start")
endif()
message(STATUS "unit_ at ${_have} == ram_start")
message(STATUS "m_unit at ${_have} == ram_start")