nRF9160 + external flash + MCUboot: buggy flash protection configuration in SDK

[kFYatek]

There seems to be a bug in the nRF Connect SDK when attempting to use external flash for the secondary MCUboot partition on nRF9160.

Please see the minimal project for nRF9160DK (HW revision 0.14.0 or newer) that exhibits this issue here: https://drive.google.com/file/d/1kOiagY32qmYNR3Wf0BVROqHCjH_8xePm/view?usp=sharing

When MCUboot and TrustedFirmware-M are both in use, the CONFIG_BOOTLOADER_MCUBOOT option is propagated to TF-M (https://github.com/nrfconnect/sdk-nrf/blob/v2.0.0/modules/tfm/zephyr/CMakeLists.txt#L115), which in turn enables the BL2 option (https://github.com/nrfconnect/sdk-nrf/blob/v2.0.0/modules/tfm/tfm/boards/CMakeLists.txt#L34) and that declares a flash region (https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.5.0-ncs2/platform/ext/target/nordic_nrf/common/nrf9160/target_cfg.c#L420) which TF-M will try to configure as non-secure (https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.5.0-ncs2/platform/ext/target/nordic_nrf/common/nrf9160/target_cfg.c#L552).

Apparently the flash protection only works for the internal flash, so the spu_regions_flash_config_non_secure() function hard-faults and consequently the board enters a boot loop.

A workaround is to manually override the TFM_CMAKE_OPTIONS property (see the commented out line in the attached project's CMakeLists.txt) so that CONFIG_BOOTLOADER_MCUBOOT is set to false in the TF-M child image. However I believe this should be addressed somewhere in the SDK itself, so that setting flash protection for the secondary partition is not attempted when the secondary MCUboot partition lies on external flash.

[Charlie]

Hi KFyatek,

I got some feedback from our development team:
We don't use BL2 but we do have region_defs.h file with a lot of partition information that just uses this. It seems we have misused the BL2 constructs (we probably didn't have time to rename and come up with something defined by us) so this is clearly something we should clean up.

We are a little pressed for resources in our team because of summer vacation, so I'm assuming the proper solution won't be available until maybe a couple of weeks. Sorry for the inconvenience, I will keep monitoring the development state and keep you updated.

Best regards,
Charlie

[GiulianoFranchetto]

Hi Charlie,

Where are we with this issue? I faced the same problem as described here, but fortunately, the workaround seems to be working.

This is a show-stopper issue, it needs to be addressed ASAP.

Regards