boot: Introduce direct execute-in-place (XIP) mode
This patch introduces the direct execute-in-place (XIP) mode in addition
to the other upgrade modes (swap strategies, overwrite-only). When
direct-XIP is enabled with the MCUBOOT_DIRECT_XIP option, mcuboot
selects the newest valid image based on the image version numbers from
the image header, thereafter the selected image runs directly from its
flash partition (slot) instead of moving it. Therefore the images must
be linked to be executed from the given image slot. It means that in
direct-XIP mode either of the primary and the secondary slots can hold
the active image.
This patch is based on the NO_SWAP upgrade strategy which was first
introduced in the Trusted Firmware-M project.
Source TF-M version: TF-Mv1.0.
Change-Id: If584cf01ae5aa7208845f6a6fa206f0595e0e61e
Signed-off-by: David Vincze <david.vincze@linaro.org>
diff --git a/docs/design.md b/docs/design.md
index 9e3550c..697243a 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -1,7 +1,7 @@
<!--
- SPDX-License-Identifier: Apache-2.0
- - Copyright (c) 2017 Linaro LTD
+ - Copyright (c) 2017-2020 Linaro LTD
- Copyright (c) 2017-2019 JUUL Labs
- Copyright (c) 2019-2020 Arm Limited
@@ -166,10 +166,11 @@
A portion of the flash memory can be partitioned into multiple image areas, each
contains two image slots: a primary slot and a secondary slot.
-The boot loader will only run an image from the primary slot, so images must be
-built such that they can run from that fixed location in flash. If the boot
-loader needs to run the image resident in the secondary slot, it must copy its
-contents into the primary slot before doing so, either by swapping the two
+Normally, the boot loader will only run an image from the primary slot, so
+images must be built such that they can run from that fixed location in flash
+(the exception to this is the [direct-xip](#direct-xip) upgrade mode). If the
+boot loader needs to run the image resident in the secondary slot, it must copy
+its contents into the primary slot before doing so, either by swapping the two
images or by overwriting the contents of the primary slot. The bootloader
supports either swap- or overwrite-based image upgrades, but must be configured
at build time to choose one of these two strategies.
@@ -215,11 +216,33 @@
manufacturer's specified number of erase cycles. In general, using a ratio that
allows hundreds to thousands of field upgrades in production is recommended.
-The overwrite upgrade strategy is substantially simpler to implement than the
-image swapping strategy, especially since the bootloader must work properly
-even when it is reset during the middle of an image swap. For this reason, the
-rest of the document describes its behavior when configured to swap images
-during an upgrade.
+### [Equal slots (direct-xip)](#direct-xip)
+
+When the direct-xip mode is enabled the active image flag is "moved" between the
+slots during image upgrade and in contrast to the above, the bootloader can
+run an image directly from either the primary or the secondary slot (without
+having to move/copy it into the primary slot). Therefore the image update
+client, which downloads the new images must be aware, which slot contains the
+active image and which acts as a staging area and it is responsible for loading
+the proper images into the proper slot. All this requires that the images be
+built to be executed from the corresponding slot. At boot time the bootloader
+first looks for images in the slots and then inspects the version numbers in the
+image headers. It selects the newest image (with the highest version number) and
+then checks its validity (integrity check, signature verification etc.). If the
+image is invalid MCUboot erases its memory slot and starts to validate the other
+image. After a successful validation of the selected image the bootloader
+chain-loads it.
+Handling the primary and secondary slots as equals has its drawbacks. Since the
+images are not moved between the slots, the on-the-fly image
+encryption/decryption can't be supported (it only applies to storing the image
+in an external flash on the device, the transport of encrypted image data is
+still feasible).
+
+The overwrite and the direct-xip upgrade strategies are substantially simpler to
+implement than the image swapping strategy, especially since the bootloader must
+work properly even when it is reset during the middle of an image swap. For this
+reason, the rest of the document describes its behavior when configured to swap
+images during an upgrade.
## [Boot Swap Types](#boot-swap-types)
@@ -890,6 +913,9 @@
If you want to enable and use encrypted images, see:
[encrypted_images](encrypted_images.md).
+Note: Image encryption is not supported when the direct-xip upgrade strategy
+is selected.
+
### [Using Hardware Keys for Verification](#hw-key-support)
By default, the whole public key is embedded in the bootloader code and its