Infineon: Add cyw20829 platform, shared slot feature, json memory map, psoc6 xip
Based in 1.8.0 release of MCUBoot library
This commit adds CYW20829 Infineon platform support with following capabilities:
1. Overwrite and swap upgrade mode support
2. Multi-image with up to 4 images
3. Hardware security counter is supported for CYW20829 platform
Add XIP support for PSOC6 platform - place BOOT slot in external memory and execute it in place using SMIF in XIP mode
and some new features for Infineon devices.
1. Shared upgrade slot feature - use one shared area for upgrade slots of multiple images
2. Memory map defined using JSON file - define memory regions for bootloader and user app in conventional way using JSON file
diff --git a/docs/design.md b/docs/design.md
old mode 100644
new mode 100755
index a50feeb..e5e94b3
--- a/docs/design.md
+++ b/docs/design.md
@@ -3,7 +3,7 @@
- Copyright (c) 2017-2020 Linaro LTD
- Copyright (c) 2017-2019 JUUL Labs
- - Copyright (c) 2019-2020 Arm Limited
+ - Copyright (c) 2019-2021 Arm Limited
- Original license:
@@ -96,6 +96,8 @@
* Image header flags.
*/
#define IMAGE_F_PIC 0x00000001 /* Not supported. */
+#define IMAGE_F_ENCRYPTED_AES128 0x00000004 /* Encrypted using AES128. */
+#define IMAGE_F_ENCRYPTED_AES256 0x00000008 /* Encrypted using AES256. */
#define IMAGE_F_NON_BOOTABLE 0x00000010 /* Split image app. */
#define IMAGE_F_RAM_LOAD 0x00000020
@@ -110,7 +112,8 @@
#define IMAGE_TLV_RSA3072_PSS 0x23 /* RSA3072 of hash output */
#define IMAGE_TLV_ED25519 0x24 /* ED25519 of hash output */
#define IMAGE_TLV_ENC_RSA2048 0x30 /* Key encrypted with RSA-OAEP-2048 */
-#define IMAGE_TLV_ENC_KW128 0x31 /* Key encrypted with AES-KW-128 */
+#define IMAGE_TLV_ENC_KW 0x31 /* Key encrypted with AES-KW-128 or
+ 256 */
#define IMAGE_TLV_ENC_EC256 0x32 /* Key encrypted with ECIES-P256 */
#define IMAGE_TLV_ENC_X25519 0x33 /* Key encrypted with ECIES-X25519 */
#define IMAGE_TLV_DEPENDENCY 0x40 /* Image depends on other image */
@@ -269,13 +272,26 @@
#define IMAGE_EXECUTABLE_RAM_SIZE <area_size_in_bytes>
```
+For multiple image load if multiple ram regions are used platform must define
+the `MULTIPLE_EXECUTABLE_RAM_REGIONS` flag instead and implement the following
+function:
+
+```c
+int boot_get_image_exec_ram_info(uint32_t image_id,
+ uint32_t *exec_ram_start,
+ uint32_t *exec_ram_size)
+```
+
When ram-load is enabled, the `--load-addr <addr>` option of the `imgtool`
script must also be used when signing the images. This option set the `RAM_LOAD`
flag in the image header which indicates that the image should be loaded to the
RAM and also set the load address in the image header.
-The ram-load mode currently supports only the single image boot and the image
-encryption feature is not supported.
+When the encryption option is enabled (`MCUBOOT_ENC_IMAGES`) along with ram-load
+the image is checked for encryption. If the image is not encrypted, RAM loading
+happens as described above. If the image is encrypted, it is copied in RAM at
+the provided address and then decrypted. Finally, the decrypted image is
+authenticated in RAM and executed.
## [Boot Swap Types](#boot-swap-types)
@@ -335,14 +351,14 @@
### [Revert mechanism in direct-xip mode](#direct-xip-revert)
The direct-xip mode also supports a "revert" mechanism which is the equivalent
-of the swap mode's "revert" swap. It can be enabled with the
-MCUBOOT_DIRECT_XIP_REVERT config option and an image trailer must also be added
-to the signed images (the "--pad" option of the `imgtool` script must be used).
-For more information on this please read the [Image Trailer](#image-trailer)
-section and the [imgtool](imgtool.md) documentation. Making the images permanent
-(marking them as confirmed in advance) is also supported just like in swap mode.
-The individual steps of the direct-xip mode's "revert" mechanism are the
-following:
+of the swap mode's "revert" swap. When the direct-xip mode is selected it can be
+enabled with the MCUBOOT_DIRECT_XIP_REVERT config option and an image trailer
+must also be added to the signed images (the "--pad" option of the `imgtool`
+script must be used). For more information on this please read the
+[Image Trailer](#image-trailer) section and the [imgtool](imgtool.md)
+documentation. Making the images permanent (marking them as confirmed in
+advance) is also supported just like in swap mode. The individual steps of the
+direct-xip mode's "revert" mechanism are the following:
1. Select the slot which holds the newest potential image.
2. Was the image previously selected to run (during a previous boot)?
@@ -426,7 +442,7 @@
either decreasing this size, to limit RAM usage, or to increase it in devices
that have massive amounts of Flash or very small sized sectors and thus require
a bigger configuration to allow for the handling of all slot's sectors.
-The factor of min-write-sz is due to the behavior of flash hardware. The factor
+The factor of min-write-size is due to the behavior of flash hardware. The factor
of 3 is explained below.
2. Encryption keys: key-encrypting keys (KEKs). These keys are needed for
@@ -689,6 +705,41 @@
+ Boot into image in the primary slot of the 0th image position\
(other image in the boot chain is started by another image).
+### [Multiple Image Boot for RAM loading and direct-xip](#multiple-image-boot-for-ram-loading-and-direct-xip)
+
+The operation of the boot loader is different when the ram-load or the
+direct-xip strategy is chosen. The flash map is very similar to the swap
+strategy but there is no need for Scratch area.
+
++ Loop 1. Until all images are loaded and all dependencies are satisfied
+ 1. Subloop 1. Iterate over all images
+ + Does any of the slots contain an image?
+ + Yes:
+ + Choose the newer image.
+ + Copy it to RAM in case of ram-load strategy.
+ + Validate the image (integrity and security check).
+ + If validation fails delete the image from flash and try the other
+ slot. (Image must be deleted from RAM too in case of ram-load
+ strategy.)
+ + No: Return with failure.
+
+ 2. Subloop 2. Iterate over all images
+ + Does the current image depend on other image(s)?
+ + Yes: Are all the image dependencies satisfied?
+ + Yes: Skip to next image.
+ + No:
+ + Delete the image from RAM in case of ram-load strategy, but
+ do not delete it from flash.
+ + Try to load the image from the other slot.
+ + Restart dependency check from the first image.
+ + No: Skip to next image.
+
++ Loop 2. Iterate over all images
+ + Increase the security counter if needed.
+ + Do the measured boot and the data sharing if needed.
+
++ Boot the loaded slot of image 0.
+
## [Image Swapping](#image-swapping)
The boot loader swaps the contents of the two image slots for two reasons:
@@ -973,8 +1024,8 @@
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 or the ram-load
-upgrade strategy is selected.
+Note: Image encryption is not supported when the direct-xip upgrade strategy
+is selected.
### [Using Hardware Keys for Verification](#hw-key-support)
@@ -1264,6 +1315,7 @@
are issued from the MCUboot source directory):
```sh
+$ mkdir docker
$ ./ci/fih-tests_install.sh
$ FIH_LEVEL=MCUBOOT_FIH_PROFILE_MEDIUM BUILD_TYPE=RELEASE SKIP_SIZE=2 \
DAMAGE_TYPE=SIGNATURE ./ci/fih-tests_run.sh
@@ -1285,4 +1337,4 @@
the shell returns, and it is possible to investigate the results. It is also
possible to stop the test with _Ctrl+c_. The parameters to the
`execute_test.sh` are `SKIP_SIZE`, `BUILD_TYPE`, `DAMAGE_TYPE`, `FIH_LEVEL` in
- order.
\ No newline at end of file
+ order.