Why do even need swap partitions

[nihalpasham]

Why do even need swap partitions

[nihalpasham]

rustBoot is designed to run on anything from a tiny microcontroller to a microprocessor, one important design consideration is support for various execution contexts/environments.

position-dependent code: In the context of a microcontroller, we must figure-out i.e. know 'at compile time' if we are building an image for partition A or partition B. In other words, compiled images are position dependent. Example: say, we have 2 flash partitions, partition A and partition B and we use the A/B update method

• We would have to build two binaries for each update and serve one depending on the partition address/label (i.e. update could be programmed into either part-A or part-B).
• Technically, this is possible but to do this in the A/B context, we must have a way to communicate extra information to an update-backend.

The firmware's update client can either

• use an update-specific protocol or instruction when signaling the backend to return an update for partition A (or B) or
• use some binary-encoding scheme (i.e. byte-representation) embedded in the image to signal this information.

In practice, this is a bit difficult to deploy and error-prone. The other issue with an A/B approach is that we cant use external devices/memories that are not memory mapped for updates. For ex: we cant use SPI-flash

Fixed boot partition and swapping: This approach is also referred to as the boot/update approach. All images are compiled to boot from partition A, updates are stored in partition B and swapped in the event of an update.

• This is a more flexible approach and is generally easier to deploy in the field (without the risk of bricking or corrupting the system).
• The flip-side though is that the 'swapping-logic or code' needs to be reliable and safe. (this is where rust comes in)

Support for A/B partitions: for rustBoot, the swap model makes sense as its supposed to be micro-architecture and OS agnostic. However, in the case of Linux, I presume none of the above applies as compiled kernel images (i.e. binary) are not position dependent.

• In this case, instead of the direct-XIP method or execute-in-place from flash used by mcu's, we can simply do a RAM-BOOT
• either load from the active partition (say A) into RAM or download the update image into the inactive partition (say B), verify it and if it checks-out, load into RAM and pass control to it.
• i.e. no swapping involved
• The plan to support ram-boot exists but since this is the preferred way to boot linux images, we can priortize this.
• Note - for devices that support it, we will add dual-bank flash swaps as well.