Secure Firmware Update for M33-TD flavor

Applicable for

STM32MP21x lines, STM32MP23x lines, STM32MP25x lines

1. Article Purpose[edit | edit source]

This article describes the Firmware Update (FWU) architecture used for the M33-TD flavor use case on STM32MP2 series platforms. M33-TD flavor FWU extends the A35-TD flavor FWU flow described in Secure Firmware Update.

It explains how firmware update is handled for both:

Cortex-A35 software components, such as:
- FIP
- Linux kernel
Cortex-M33 firmware components, such as:
- tfm_s_ns
- ddr_fw

The FWU behavior depends on the storage organization implemented on the platform. Two configurations are supported:

single storage
dual storage

This article presents the main Firmware Update actors and the update sequence associated with each configuration.

2. Architecture overview[edit | edit source]

In the M33-TD flavor use case, firmware update is distributed between two execution domains:

the Cortex-A35 world, running Linux
the Cortex-M33 world, running TF-M-based firmware

Linux is the main orchestration side for the global update flow.

For Cortex-A35 components, the update flow relies on an Update Agent. For Cortex-M33 components, the update implementation depends on the storage configuration.

2.1. Firmware Update components[edit | edit source]

The Firmware update architecture involves software actors on both the Cortex-A35 and Cortex-M33 sides.

2.1.1. Cortex-A side[edit | edit source]

The main Firmware Update actors on the Cortex-A35 side are:

Update agent
- used as the Linux Firmware Update framework
- manages Cortex-A35 update artifacts and associated slots
- updates Cortex-A35 firmware, and also Cortex-M33 firmware when Linux has direct access to Cortex-M33 storage, that is, in single storage mode
- usesm33rpfwu to access the Cortex-M33 FWU service in dual storage mode
  - is also used to recover Cortex-M33 Firmware Update boot information
m33rpfwu user-space tool
- used in dual storage mode to control Cortex-M33 Firmware Update operations
- is used to retrieve Cortex-M33 boot information when required
- writes Cortex-M33 firmware binaries into shared DDR memory
- sends FWU commands to the Cortex-M33 through RPMsg
- receives FWU status responses from the Cortex-M33
RPMsg framework
- provides the command channel between Linux and the Cortex-M33
UIO^[1] shared memory device
- provides the data path used to transfer firmware binaries to the shared memory region
- used only in dual storage mode
TF-A BL2^[2] (Secure Bootloader for Cortex-A)
- supports firmware update^[3]
  - handles Cortex-A35 image boot selection through the metadata partition
  - supports trial and rollback behavior

Cortex-A35 responsibilities typically include:

downloading or receiving update packages
updating Cortex-A35 owned firmware images
preparing Cortex-M33 firmware payloads
triggering Cortex-M33 update requests when required
validating or rejecting trial images after reboot

2.1.2. Cortex-M side[edit | edit source]

The main Firmware Update actors on the Cortex-M33 side are:

Firmware Update manager task (FWU NS app)
- receives Firmware Update requests from Linux
- interprets the commands
- calls the PSA firmware update services
- sends responses back to Linux
TF-M FWU partition
- the firmware update partition provides the secure firmware update service
- exposes and implement the PSA Firmware Update API ^[4] to the non-secure application side
PSA Firmware Update API^[4]
- used by the non-secure side to call Firmware Update operations exposed by the FWU partition, such as:
  - start, write, finish, install, accept, reject
MCUboot BL2 (Secure Bootloader for Cortex-M)
- handles Cortex-M33 image boot selection
- supports trial and rollback behavior for updated images

Cortex-M33 responsibilities typically include:

managing access to Cortex-M33 owned storage
writing new firmware images to storage managed by Cortex-M33 secure software^[5]
preparing updated images for installation^[5]
requesting the final reboot after staging^[5]
supporting post-reboot confirmation or rejection^[5]

2.2. Single storage[edit | edit source]

In the single storage configuration, storage drivers are owned by the Cortex-A side. As a result, Linux has direct access to all firmware storage areas, including the areas used for Cortex-M firmware.

In this configuration:

Linux updates Cortex-A35 components through the Update Agent or a dedicated user-space script
Linux also updates Cortex-M33 components through the same Linux-controlled flow, with Cortex-M33 metadata located at the end of the image slot^[6]
no dedicated Cortex-M33 FWU write path is required for storage access
the TF-M FWU partition is used only to recover Cortex-M33 boot information and confirm the active image version

This model provides a centralized update flow, fully managed from the Linux side.

Main characteristics:

a single software domain controls storage access
Linux performs image writes for the full platform
integration is simpler from a FWU orchestration perspective

In single storage mode, Linux remains responsible for the end-to-end update procedure for both Cortex-A35 and Cortex-M33 firmware components.

2.3. Dual storage[edit | edit source]

In the dual storage configuration, storage ownership is split between the Cortex-A35 and the Cortex-M33:

storage associated with the Cortex-A35 is accessible from the Cortex-A side
storage associated with the Cortex-M33 is accessible only from the Cortex-M secure side

In this configuration, Linux cannot directly write M33 firmware storage.

To support Cortex-M33 firmware update, the FWU architecture uses:

the TF-M FWU partition on the Cortex-M33, implementing the Arm PSA FWU API^[4]
a dedicated RPMsg endpoint between Linux and the Cortex-M33
a shared DDR memory region used to transfer binary payloads

The overall logic is the following:

Linux prepares the Cortex-M33 firmware image.
Linux copies the binary into shared memory.
Linux sends FWU commands to the Cortex-M33.
The Cortex-M33 performs secure FWU operations on its own storage.

The last part of this procedure is executed with the Cortex-A35 stopped, because the M33 cannot respond to other requests during storage erase operations.

This model preserves the storage isolation between execution domains while keeping Linux as the global FWU orchestrator.

In dual storage mode, Linux controls the FWU sequence, but the actual write and install operations for Cortex-M33-owned firmware are executed by the Cortex-M33 secure side.

2.4. Bootloader linked revert mechanism[edit | edit source]

During the trial boot phase, Cortex-A35 and Cortex-M33 firmware updates are not handled by the same boot chain:

the Cortex-A35 update flow is handled through the Cortex-A35 boot path via TF-A BL2^[2]
the Cortex-M33 update flow is handled through the Cortex-M33 boot path via MCUboot BL2^[7]

As a consequence, a specific mechanism is required to keep both sides consistent when an updated image fails during boot validation.

The purpose of the bootloader linked revert mechanism is to ensure that a Cortex-A35 revert is also triggered when a revert has already occurred on the Cortex-M33 side during boot.

This mechanism avoids situations where the Cortex-M33 has reverted to its previous image and the Cortex-A35 still runs the new image.

Such a situation would leave the platform in a mixed software state, with the two domains running software versions that may no longer be compatible.

2.4.1. Principle[edit | edit source]

After a FWU sequence, both Cortex-A35 and Cortex-M33 may boot using newly installed images.

If the M33 bootloader detects that the updated Cortex-M33 image is not valid, it may automatically revert to the previous image during boot.

When this happens, the platform must also ensure that the Cortex-A35 side reverts to its previous image. To support this, the Cortex-M33 boot path stores a revert indication in backup register 73^[8].

This revert information is then checked by the Cortex-A bootloader (TF-A BL2).

If the indication is present, the Cortex-A35 side selects the previous Cortex-A35 image and completes the revert sequence.

This mechanism ensures that the platform does not remain in a mixed-version state with an old Cortex-M33 image and a new Cortex-A35 image.

3. Update sequence[edit | edit source]

The firmware update sequence depends on the storage configuration.

3.1. Single storage[edit | edit source]

In single storage mode, Linux manages the complete update flow for both Cortex-A35 and Cortex-M33 firmware components.

A typical update sequence is:

Linux receives or downloads the update package.
Linux updates Cortex-A35 components using an Update Agent.
Linux writes the Cortex-M33 firmware images directly to their target storage areas.
Linux updates the related boot or slot metadata if required:
1. for Cortex-A35, the metadata partition must be updated as in the A35-TD flavor Secure Firmware Update flow
2. for Cortex-M33, Firmware Update metadata are stored at the end of the image slot, as specified in the MCUboot documentation^[6]
The platform reboots.
Bootloaders (MCUboot and TF-A BL2) select the updated images.
After validation, the updated software can be accepted:
1. for Cortex-A35, using the same flow as in A35TD Secure Firmware Update
2. for Cortex-M33, by updating MCUboot flags in the image slot

In this mode:

Linux is responsible for the complete FWU flow
image transfer and storage writes are performed on the Cortex-A35 side
no dedicated Cortex-M33 storage access sequence is required

3.2. Dual storage[edit | edit source]

In dual storage mode, the FWU sequence is split between Linux and the Cortex-M33.

Linux remains the orchestrator, but Cortex-M33 firmware images are written by the Cortex-M33 using secure FWU services.

A typical Cortex-M33 FWU sequence is:

Linux receives or downloads the update payload.
Linux updates Cortex-A35 components through the usual Linux FWU flow, as described in A35TD Secure Firmware Update.
Linux uses the m33rpfwu tool for Cortex-M33 firmware components.
The tool locates the RPMsg endpoint named fwu.
The tool locates the UIO shared memory device named uio-fwu-shmem.
Linux copies the target firmware binary into the shared DDR memory region.
Linux sends an install command to the Cortex-M33 through RPMsg to indicate which component is updated.
The Cortex-M33 FWU manager receives the command and updates its internal FWU state.
When Linux sends the reboot command, the Cortex-M33 starts the Firmware Update apply sequence.
The Cortex-M33 requests the stop of the Cortex-A35 side.
After Cortex-A35 shutdown, the Cortex-M33 performs the FWU operations through the PSA Firmware Update service API:
- psa_fwu_start() for each component
- psa_fwu_write() until all firmware data are copied in their respective slots
- psa_fwu_finish() for each component
- psa_fwu_install()
Once all selected components are prepared, the Cortex-M33 calls psa_fwu_request_reboot(), and the platform reboots.
The updated images are now considered as in trial state and are selected by their respective bootloader.
After validation, Linux can confirm or reject the updated images:
- accept confirms the image permanently
- reject requests rollback behavior according to the boot policy
- These operations rely on the PSA Firmware Update API for Cortex-M and on metadata partition updates for Cortex-A

Specific points for dual storage mode:

shared DDR memory is used for binary transfer
the Cortex-A35 stop request is part of the secure FWU apply phase

3.2.1. Example commands for dual storage mode with m33rpfwu tool[edit | edit source]

The following examples illustrate a typical Cortex-M33 only Firmware Update sequence from Linux, using the user-space tool to communicate with the Cortex-M33 firmware:

m33rpfwu list
m33rpfwu info
m33rpfwu write -c tfm_s_ns -b /home/root/download/tfm_s_ns.bin
m33rpfwu install -c tfm_s_ns
m33rpfwu reboot
m33rpfwu accept

3.2.2. Additional notes[edit | edit source]

The FWU command protocol uses a common binary structure containing:

command identifier
component identifier
PSA status
image version information

4. References[edit | edit source]

[1] ttps://kernel.org/doc/html/v7.0/driver-api/uio-howto.html

[:3-2] 2.0 ^2.1 TF-A BL2 overview

[3] ttps://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-update.html

[:0-4] 4.0 ^4.1 ^4.2 https://arm-software.github.io/psa-api/fwu/

[:1-5] 5.0 ^5.1 ^5.2 ^5.3 In dual storage only

[:4-6] 6.0 ^6.1 https://docs.mcuboot.com/design.html#image-swapping

[7] MCUboot overview

[8] STM32MP2 backup registers

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]