Hi,
Just a heads-up for the coming changes related to MCUBoot. Some of them requires installing new tools in build system others could affect devices on the field (if there is any) after SW upgrade.
Short term, within one week:
1. Official imgtool enablement: * The official released version of the image signings script will be used. * Must be installed in the build system. It is a PyPI package: imgtool v1.6 * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4564/6 2. Encrypted image support: * This feature already exists in the upstream repo for a while * This change makes possible to turn it on in TF-M build system * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4565/6
Long term, but still expected in Q3:
1. Removal of forked MCUBoot from TF-M: * Only upstream MCUBoot will supported * Platform and project related files will be kept:
i. shim layer to match MCUBoot HAL's to TF-M's HAL
ii. bl2_main.c, example signing keys, keys.c
iii. platform code: flash and UART drivers, implementation of boot_hal.h
* When building TF-M with upstream MCUboot it is a mixture of files from the two repo + crypto code from mbedcrypto repo. * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4953 * The removal of the fork depends on the feature upstream to MCUBoot repo:
i. https://github.com/JuulLabs-OSS/mcuboot/pull/739
ii. RAM_LOAD: PR will come a bit later
1. Removal of LEGACY_TFM_TLV_HEADER support * This is a compatibility mode. It was introduced to hide the difference in the definition of the TLV header int he shared data between bootloader and runtime SPE. * If forked removed, then this is not necessary anymore, unless an forked version of MCUBoot wants to cooperate new SPE. * Please check and indicate if you think that this is a valid use case and compatibility mode must be kept!
Tamas