Definition
A/B Partition (A/B partition) divides device storage into two sets, A and B, separating the currently running partition from the one to be upgraded. During OTA upgrades, the idle partition is written to, and after rebooting, the system switches; in case of failure, it can quickly Rollback, achieving a seamless upgrade.
Working Principle
The A/B partition adopts a dual system slot design (Slot A and Slot B). During device operation, only one partition is activated as the main system, while the other partition remains idle or serves as a backup. When initiating a FOTA firmware upgrade, the new firmware is downloaded and written to the idle partition. After verification passes, the boot flag is updated, and the next restart will boot from the new partition. If the new firmware operates abnormally, the boot flag can quickly switch back to the original partition, achieving a rollback in seconds without needing to re-download or re-flash.
Technical advantages
Compared to single-partition upgrades, the A/B partition has the following advantages: the upgrade process does not damage the currently running system, reducing the risk of bricking; rollback does not require re-downloading, only switching the boot partition; it supports atomic switching, and business interruption time can be controlled within a single restart; suitable for scenarios requiring high availability such as industrial devices, in-vehicle terminals, and smart meters.
Storage and Implementation Considerations
The A/B partition requires the device to have at least double the system partition storage space and has explicit capacity requirements for storage media like eMMC and NOR Flash. Implementation requires coordinated design with the Bootloader, partition table (such as GPT), and OTA client to ensure consistency in partition boundaries, boot logic, and Firmware Signature verification process.
When a slot switch is allowed
An A/B partition means the bootloader recognizes only one active slot at a time. The other slot exists to receive this upgrade. After the new image is written to the idle slot, it is not yet the running system. The image check must pass, the version must be readable, and the boot flag must point at the new slot. Only the next reset starts from that slot. This fits a terminal whose system image fits in one slot, whose storage can spare an equal amount, and whose service can accept one restart. A device whose flash is already full, or whose control loop cannot accept a restart, has no room for a peer slot. Capacity planning also has to count certificates, boot logs, and read-only resources inside the slot size, or the write stops halfway when the idle slot runs out of space.
Before this is used, the bootloader, the partition table, and the update client must share one convention for slot numbers. During the write, the active slot stays bootable, and the idle slot is the only region that may be erased. A separate data partition and a configuration partition should not sit inside slot A or slot B, or switching back will also drop the site parameters. The old slot must be kept until the new system is confirmed stable. Rollback is then only a change of boot flag, not a fresh download of the full package. If an OTA job must still return to the old system after power is lost midway, the upgrade state machine has to confirm first and only then reclaim the old slot. Download complete is not a signal that the way back may be erased.
When the boot flag and the image check disagree
A common mistake is to write the difference blocks of a delta package straight into the idle slot when the device has not first assembled a complete image. The bootloader can start only a complete system. If a partial slot is marked bootable, the new slot will not come up after reset, and the old slot may no longer be selected because the flag has already moved. Another mistake is for the cloud, the update client, and the bootloader each to keep their own slot number. The job shows a successful write, the device is still running the old slot, and the next upgrade treats the running slot as idle and overwrites it. Mixing slot numbers that start at zero with numbers that start at one does not always show up in a small pilot. It shows up across the fleet after a wide push.
Writing a whole slot also increases flash wear. When releases are frequent, decide first whether the difference is suitable to assemble on the device, rather than erasing a whole slot every time. If power fails while a slot is being written, only the idle slot should be discarded, and the running slot should stay bootable. If the program erases the running slot first to free space, the pair of slots no longer has a way back. Reclaiming the old slot after the new slot has run only briefly leaves a later configuration incompatibility with nowhere to switch back. Stability should be confirmed from a result the device itself reports, such as a critical service having started and configuration being readable, not from the cloud download reaching completion. Power, the watchdog, and the boot retry count have to be designed together, so a new slot that crashes repeatedly still has a chance to put the boot flag back.
After the old slot is reclaimed too early
In a two-slot design, the old slot is the only way back that does not depend on the network. Until the new slot has run a full cycle of real service, the old slot should not be erased by the next upgrade or by log cleanup. Some implementations treat a successful boot as the instant the bootloader hands over control. The new system has just mounted the file system, the application has not yet read the existing configuration, and the cloud already allows the old slot to be reclaimed. The application then exits because the configuration is incompatible, the watchdog resets, and the bootloader finds the old slot marked invalid. The device stops with neither side able to start. Stability should come from an application-level result the device reports: a critical task is running, the existing configuration can be read, and the device can handshake with the platform again. It should not come from download progress or the first line of the bootloader log.
Capacity planning also has to leave erase margin for rollback. If the free space in the idle slot is enough for this image but not enough to keep a backup of the check data and the boot flag, a power loss writes the flag only halfway, and the next power-on cannot tell which slot to trust. A lab unit with larger storage can pass while a production model with just enough capacity fails only on the production batch. The upgrade state machine should split still-rollbackable, confirmed, and reclaim-allowed into three steps, each with a state to stay in after failure. It must not jump from download complete straight to reclaim. A spot check in the field should at least show the current active slot, whether the other slot is still complete, and whether the last switch was an upgrade success or a failure of the new slot to start.