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:
CONFIG_TFM_BL2=n
CONFIG_FLASH_BASE_ADDRESS=0x80A0000
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 0 Base : 0x08000000
Secure Image (0) : 0x08001000
Non‑Secure Image 0 : 0x080A0000
Slot 1
Slot 1 Base : 0x08200000
Secure Image (1) : 0x08201000
Non‑Secure Image 1 : 0x082A0000
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
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
Do this for both slot images. In this example I created merged_imaged_slot_0 and merged_image_slot_1.
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
✅ Confirms your Secure → Non‑Secure chain works without BL2
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 ( 0x0 instead of 0x1000 )
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.
View full article
