MCUboot Direct-XIP Slot Addresses: Qualify ROM-Fixed Images Before Placement
Match a direct-XIP image’s placement metadata to the exact slot-offset convention used by the deployed MCUboot port. Then qualify executable correctness and authentication separately. A valid signature cannot repair a slot-specific image installed at the wrong execution location.
This guide pins MCUboot v2.2.0’s direct-XIP loader and image-tool header generation. It is a placement review, not a flashing procedure. No images were signed, programmed or booted, and no production trust settings were changed.
1. Confirm that the product really uses direct-XIP
The direct-XIP design runs an image from either slot without moving its payload into the primary slot. The image producer and update client must account for the corresponding execution placement.
Record the resolved boot mode, board port, flash map and final loader binary. Do not apply this article’s gate to RAM-load destination checks or to swap modes that relocate an image. Similar header field names can serve different mode-specific purposes.
Create a slot-specific artifact inventory rather than one undifferentiated “firmware file” entry. Include intended component, slot, build/link configuration, header metadata, public signing identity and artifact digest.
2. Trace the compared address domain
The boot_img_slot_off() helper returns flash_area_get_off(), documented as the slot’s offset from the beginning of its flash device. The direct-XIP comparison uses that value, not an independently calculated CPU virtual address.
For the actual port, trace the flash-area accessor and how the device maps into the processor’s execution space. Distinguish device-relative slot offset, CPU execution address, image-header start and payload/entry location. Do not add a flash mapping base or header size to the comparison value merely because another tool displays those quantities.
| Placement worksheet field | Evidence source |
|---|---|
| Flash device identity | Actual platform flash-area mapping |
| Slot offset returned by the accessor | Compiled map and reviewed accessor implementation |
| Image header address field | Bounds-checked inspection of the final artifact |
| ROM_FIXED flag | Decoded final header, not just signing-job arguments |
| CPU execution placement | Linker/map and platform handoff evidence |
| Artifact identity and intended slot | Approved release inventory |
3. Apply the exact flag-conditioned predicate
In boot_rom_address_check(), an image is rejected by this gate only when ROM_FIXED is set and its header address differs from the selected slot offset. With no flag, the helper returns success without enforcing that equality.
The caller marks a mismatched candidate’s slot unavailable and continues selection before reaching its normal validation step. A resulting fallback therefore need not mean the candidate’s signature was invalid.
| Header condition | Placement-gate result | Remaining obligation |
|---|---|---|
| ROM_FIXED set; address equals slot offset | Pass this equality check | Verify executable build, authentication and board applicability |
| ROM_FIXED set; address differs | Skip this slot candidate | Diagnose artifact/slot/offset mismatch |
| ROM_FIXED absent | Equality is not enforced by this gate | Establish placement correctness independently |
Do not describe the last row as permission to place an image anywhere. The loader skipping one check does not make fixed-address code position-independent or establish correct vector and entry behavior.
4. Inspect the final flag, especially for zero
The tagged image-tool implementation sets ROM_FIXED when its rom_fixed value is truthy and packs the corresponding value into the shared header address field. A zero-valued argument does not set this flag in that path.
Consequently, recording that a build job supplied zero does not demonstrate that the final image carries an enforced zero-offset placement requirement. Inspect both field and flag. Keep this exact tool-version behavior separate from a general statement about all image generators.
If a zero-offset policy is required, stop and resolve the supported packaging contract with the maintained tool and port. Do not manually patch a signed header or clear the flag to conceal a mismatch. Any corrected artifact must follow the authorized build/signing and qualification process.
5. Qualify the slot matrix without live writes
First compare preserved artifacts against a read-only slot-map snapshot. Use symbolic slot offsets S0 and S1 so reviewers can see which address domain is being compared without relying on an unrelated board’s numeric memory map.
| Proposed fixture | Expected placement evidence |
|---|---|
| Flagged S0 image evaluated for slot S0 | Equality gate passes |
| Same artifact evaluated for distinct S1 | Equality gate rejects |
| Flagged S1 image evaluated for S1 | Second slot’s positive control passes |
| Flag absent with a mismatching address field | No equality enforcement at this gate; correctness remains unproven |
| Zero tool input | Inspect final header and expose the flag boundary |
| Correct placement with invalid required signature | Later authentication rejects independently |
These are proposed fixtures, not executed results. A host comparison can check metadata relationships; it cannot prove that instructions execute correctly from the mapped slot. Later boot qualification requires recoverable development devices, original artifacts and the approved restoration path.
Hypothetical wrong-slot delivery
A fictional direct-XIP product has distinct offsets S0 and S1. A release prepared for S0 reaches the S1 destination with its ROM_FIXED declaration intact. The loader skips it at the placement gate even though the signing process used the approved identity.
Compare the intended artifact, selected destination and accessor value before investigating cryptography. Correct the release routing through the approved workflow, then qualify both placement and execution. Re-signing unchanged bytes for the same wrong location would not answer the placement problem.
6. Preserve separate release conclusions
Record placement-gate outcome, signature outcome, observed boot identity and application acceptance separately. Include the exact tool and port revisions, especially when address mappings or partition layouts change.
A passed offset comparison is narrow evidence. It does not prove board compatibility, correct linking, rollback acceptance or physical memory accessibility. The useful deliverable is a reproducible artifact-to-slot mapping with every additional acceptance gate still visible.
