OTA Configuration

OTA is used to configure OTA policies and security counters for anti-rollback attacks.

OTA Configuration Table

The OTA configuration table is a CSV file. Below is a configuration example:

Field	Value
strategy	SWAP
app_security_counter	3

The partition table has two fixed columns:

strategy - Optional, indicates the MCUBOOT OTA strategy, can be SWAP, XIP or OVERWRITE, corresponding to MCUBOOT_SWAP_USING_MOVE, MCUBOOT_DIRECT_XIP and MCUBOOT_OVERWRITE_ONLY strategies in MCUBOOT respectively.

app_security_counter - Optional, indicates the version security counter. Must be configured when secure boot is enabled, used to prevent rollback attacks. After secure boot verifies the version is legitimate, it will read this value and compare it with the security counter in OTP/NV. It will only allow booting when the upgrade version’s security counter is not less than the value in OTP/NV.

OTA Upgrade Strategies and Corresponding Partition Requirements

Below are the three upgrade strategies based on MCUBOOT. Please refer to the partition configuration document Partition Table to understand them together.

SWAP

In SWAP, the program always runs in the primary partition. The firmware to be upgraded is placed in the secondary partition during OTA download. Both partitions must be the same size. During upgrade, MCUBOOT will swap the contents of the secondary partition with the primary partition and try to run the firmware in the primary partition at that time. If it can run successfully, the contents of the primary partition at that time will be retained and boot from the primary partition thereafter. If boot fails, the contents of the secondary partition will be swapped back to the primary partition, ensuring you always have a runnable version.

XIP

XIP also requires two partitions of the same size, but the two no longer have a primary-secondary distinction. During upgrade, it will directly try to boot from the other partition. For example, when the program is running in partition A, if firmware to be upgraded is downloaded via OTA and placed in partition B, MCUBOOT will try to run the firmware in partition B. If it can run successfully, it will continue to run from partition B thereafter. If it fails, MCUBOOT will run the previous firmware from partition A again. This also ensures you always have a runnable version. For consistency, we still keep the primary_ and secondary_ prefixes, with the primary partition as partition A and the secondary partition as partition B.

OVERWRITE

In OVERWRITE, there is only one primary partition to run firmware, and no secondary partition. We use the ota partition to store the firmware to be upgraded, and this partition size can be significantly smaller than the primary partition. In the OVERWRITE strategy, we compress the firmware to be upgraded and place it in the ota partition. This partition does not serve as an executable partition but decompresses and overwrites the primary partition during upgrade. The program still runs in the primary partition. Using this strategy has one disadvantage and one advantage. The disadvantage is that if the firmware to be upgraded cannot run, the board will be bricked. This strategy can only guarantee the legitimacy of the firmware to be upgraded, i.e., the firmware is complete, not tampered with, and secure, but cannot guarantee the firmware itself is fault-free and runnable. The advantage is that it can save a lot of space. The size of the ota partition can be determined based on the compressed size of the firmware to be upgraded. We recommend setting the ota partition size to 50% of the total size of all primary partitions.

Warning

When using the OVERWRITE strategy, please make sure that the upgraded firmware is runnable, otherwise it will be irrecoverable!