Introduction
Standard Trusted Firmware‑M (TF‑M) targets in Zephyr, including RW61x‑based platforms, assume the presence of BL2 (MCUboot) as the second-stage bootloader. BL2 is responsible for image authentication, upgrade handling, and flash layout enforcement.
However, many NXP devices provide a ROM‑based secure boot / dual‑boot mechanism capable of authenticating firmware and directly transferring control to a secure image. In such cases, BL2 is redundant and can be disabled to reduce boot time and flash usage.
This article describes how to disable BL2 in TF‑M and configure Zephyr to boot directly from ROM into the TF‑M Secure image, followed by the Non‑Secure application.
Typical TF‑M Boot Flow (With BL2)
The default Zephyr TF‑M boot chain is:
BootROM → BL2 (MCUboot) → TF‑M Secure → Non‑Secure application
BL2:
- Owns the flash layout (primary/secondary slots)
- Performs image authentication
- Manages firmware upgrades
Example with samples/tfm_integration/config_build
Target Boot Flow (ROM Boot, No BL2)
When using the ROM bootloader:
BootROM → TF‑M Secure → Non‑Secure application
In this scenario:
- ROM performs authentication and version checks
- TF‑M Secure becomes the first executable stage
- No firmware swapping or secondary slots are required
Example with samples/tfm_integration/config_build
Disable BL2 in TF‑M
Kconfig Changes
Disable BL2 explicitly in the project configurations and update the base address:
This removes MCUboot from the build and prevents generation of BL2 artifacts.
Secure Image Entry Requirements
When BL2 is removed, the ROM must jump directly to the TF‑M Secure vector table.
Ensure that:
- The Secure image is linked at the ROM‑expected address
- The Secure vector table is valid
- The Secure reset handler init
- No BL2 handoff logic is required.
Non‑Secure Image Considerations
The TF‑M Secure image will transfer control after initialization.
- Built as a direct‑boot Zephyr application
- No MCUboot headers
- Linked at the Non‑Secure offset defined in the partition layout
Dual Boot Enablement (ROM‑Managed A/B Images)
On RW61x‑class devices, the ROM expects the Secure image to start at offset 0x1000 within a bootable slot, with the Non‑Secure image located at offset 0xA0000. Each boot slot therefore contains a complete Secure + Non‑Secure pair at fixed offsets.
The ROM authenticates the slot, jumps to the Secure offset, and TF‑M later transfers control to the Non‑Secure image.
BootROM
├─ Authenticate Slot 0 → Secure@+0x1000 → Non‑Secure@+0xA0000
└─ Authenticate Slot 1 → Secure@+0x1000 → Non‑Secure@+0xA0000
No BL2 or runtime image swapping is involved.
Example Flash Layout (Corrected)
Slot 0
Slot 1
Each slot is independently bootable and contains no shared state with the other slot.
ROM Boot Expectations
For each slot, the ROM expects:
- Slot authentication data (signature / manifest)
- A valid Secure vector table at
slot_base + 0x1000 - A valid Secure reset handler
The ROM never jumps to Non‑Secure directly.
Using the SEC tool to enable dual boot
First we'll create two images one for slot 0 and one for slot 1. The difference will be noted in the text of the non-secure image.
1. Build Zephyr Images (Slot‑A and Slot‑B)
For each slot, build:
- TF‑M Secure image (linked at
+0x1000) - Zephyr Non‑Secure image (linked at
+0xA0000)
Slot 0, I modified the non-secure image to print a quick message identifying the slot it was programmed in.
Slot 1, I modified the non-secure image to print a quick message identifying the slot it was programmed in.
Using the SEC tool, we will use the "Merge Tool" to merge the secure and non-secure binaries with the appropriate offset.
2. Merge Secure + Non‑Secure Images
ROM expects one contiguous image per slot, not two independent binaries.
In SEC Tool:
- Open Merge Tool
- Select:
- Secure binary(without boot header) → offset
0x1000 - Non‑Secure binary → offset
0xA0000
- Secure binary(without boot header) → offset
- Output a single merged image
* If you are using the kconfig options as described above, the FCB will be attached to the secure binary, therefore please ensure that your offset for secure binary considers the FCB location which is offset 0x400
3. Assigning Version Metadata
Dual‑boot selection is driven entirely by ROM metadata.
For each merged image:
- Set Image Version
Example:
- Slot A version:
1 - Slot B version:
2
ROM rules are typically:
- Boot highest valid version
- Use fallback slot if authentication fails
Select the merged image for the slot you would like to program first. Select the version that will be used with that slot.
Next, open "Dual Image Boot"
For Slot 0, select "Image 0" and select the offset you would like to use for the slot division. For Slot 1, select "Image 1".
4. Program Slot 0 (Initial Boot)
- Program Slot 0 only
- Reset device
Expected behavior:
- ROM authenticates Slot 0
- ROM jumps to
slot 0 + 0x1000 - TF‑M Secure initializes
- Non‑Secure app runs
5. Program Slot 1 (Upgrade Test)
- Program Slot 1
- Update slot metadata (version > Slot 0)
- Reset device
Expected behavior:
- ROM selects Slot 1
- Slot 1 Secure executes
- Slot 1 Non‑Secure message appears
Common Mistakes to Avoid
- Merging images at wrong offsets (
0x0instead of0x1000) - Forgetting to bump the version for Slot B
- Leaving MCUboot headers enabled
- Assuming TF‑M controls slot selection
Conclusion
Disabling BL2 in TF‑M and booting directly from ROM is a valid, efficient, and production‑ready configuration when the device ROM already provides secure boot and dual‑boot services. In this architecture, the ROM is the authority for authentication, version selection, and rollback, while TF‑M Secure becomes the first executable firmware stage.
When combined with ROM‑managed A/B dual boot, this approach provides:
- Independent, fully self‑contained Slot A and Slot B images
- Deterministic boot behavior based on ROM policy (version or fallback)
- Secure rollback without runtime image swapping
- No dependency on MCUboot or BL2 infrastructure
The key requirements for success are:
- Explicitly disable BL2 in TF‑M
- Link the Secure image at the ROM‑required offset (
+0x1000) - Link the Non‑Secure application at the fixed Non‑Secure offset (
+0xA0000) - Merge Secure and Non‑Secure binaries into a single slot image
- Use the SEC tool to:
- Assign image versions
- Enable dual‑boot policy
- Authenticate and sign each slot image
In this model, TF‑M and Zephyr are slot‑agnostic: they do not manage upgrades, slot selection, or rollback. All boot decisions are made before execution begins, by the ROM, based on SEC‑provided metadata.
This design reduces boot time, simplifies flash layouts, removes firmware‑swap complexity, and aligns well with high‑reliability production systems where firmware updates are performed out‑of‑band and enforced by ROM‑level security.
