BlackMark
e57b79c94b
The build emits an Intel HEX beside every loader image, but --update-loader could not consume one: load_image() anchors every image at address zero, and a loader HEX links at its base, so it decoded to a 32760-byte blob carrying 504 bytes of loader at the end. staging_content() then refused it as "loader image is 32760 B, the slot holds 512" - an error naming neither the cause nor the raw .bin the tool wanted instead. Drop the blank below the base in the update path. The base comes from the image's own info block rather than the device's, so an image built for another target survives the slice intact and the preflight still reports it as another target rather than failing to find an info block at all. Verified on an ATmega328P: the full self-update flow driven straight from pureboot_timeout-5s.hex, resident slot byte-for-byte against the image afterwards, application preserved; both refusal paths unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>