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>
37 lines
1.5 KiB
CMake
37 lines
1.5 KiB
CMake
# Asserts the autobaud loader's measured unit sits where the host will read
|
|
# it (--info's measured clock - the address is wire contract). Two homes: on
|
|
# a chip with the GPIOR pair the unit lives there and the image must carry no
|
|
# RAM word for it at all; elsewhere it is the first RAM object at SRAM start.
|
|
# Run as
|
|
# cmake -DOBJDUMP=... -DELF=... -DRAM_START=<data address> [-DGPIOR=<data address>]
|
|
# -P check_unit.cmake
|
|
|
|
execute_process(COMMAND ${OBJDUMP} -t ${ELF} OUTPUT_VARIABLE _syms RESULT_VARIABLE _res)
|
|
if(NOT _res EQUAL 0)
|
|
message(FATAL_ERROR "${OBJDUMP} -t ${ELF} failed")
|
|
endif()
|
|
|
|
# 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 "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 m_unit RAM object - the unit lives in the GPIOR pair at ${GPIOR}")
|
|
return()
|
|
endif()
|
|
|
|
if(NOT _line)
|
|
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 "m_unit sits at ${_have}, ram_start is ${_want} - the host peeks ram_start")
|
|
endif()
|
|
message(STATUS "m_unit at ${_have} == ram_start")
|