Problems on enabling TF-M's BL2

[jli157@intel]

A question regarding to nRFSDK 1.7: why does nRFSDK disable using BL2 inside TF-M? If our device needs BL2 with TF-M, how can we enable it?
I can't enable CONFIG_TFM_BL2 if using nrfsdk v1.7.0 since it is disabled by default. 

Should I use nrfsdk-mcuboot to replace it? If so, it seems nrfsdk-mcuboot has not been well aligned to TF-M, right?

Another question is regarding o use the nRF security backend with TF-M: is the CryptoCell is enabled automatically if nRF security backend is enabled? I don't see any static libraries inside "nrfxlib/crypto" have been linked to TF-M. Is TF-M's PSA crypto actually using "cryptocell-312-runtime"? If so, why is the nrf_security backend still needed? 

[Einar Thorsrud]

Hi,

BL2 is not supported with TF-M right now. You can use BOOTLOADER_MCUBOOT instead for now. Can you elaborate on what you mean by MCUBoot not being well aligned to TF-M?

Regarding nrf_security, the CryptoCell is enabled by default when you use TF-M. Checking the build/tfm/build.ninja file will show the linking commands with the crypto libraries.

[jli157@intel]

Hi Einar, 

Thanks for the support again! 

I just realized that nrfsdk-mcuboot is actually used by Nordic to replace TF-M's BL2 thus the BL2 inside TF-M is disabled. So, will you continue this way in the future or you will enable TF-M's BL2 at sometime? 

I saw BL2 inside TF-M has some special customized code based on mcuboot, like the shared data with Firmware Update secure partition. Does nrfsdk-mcuboot work with firmware update secure partition? Or you have another plan to support firmware update? 

Does nrfsdk-mcuboot support using QSPI flash memory as the swap storage on nrf53 DK? 

As for nrf_security, yes I also found the build script extracts the library nrfxlib/crypto/nrf_cc312_mbedcrypto/lib/cortex-m33/soft-float/no-interrupts/libnrf_cc312_mbedcrypto_0.9.11.a and chooses the object files based on the enabled macros. 

However, I'm wondering why Nordic chose using the static library instead of the package "cryptocell-312-runtime" inside TF-M to enable CryptoCell for TF-M? Are there some special considerations or some limitations? 

 

Is it okay I'm using the same thread to ask more questions about nrf_security? I'm still having a couple of questions. Or should I open a new thread? 

[Einar Thorsrud]

Hi,

jli157@intel said:

I just realized that nrfsdk-mcuboot is actually used by Nordic to replace TF-M's BL2 thus the BL2 inside TF-M is disabled. So, will you continue this way in the future or you will enable TF-M's BL2 at sometime? 

There are no work on supporting BL2 now. I cannot say if it will come at some point in the future or not, though.

jli157@intel said:

I saw BL2 inside TF-M has some special customized code based on mcuboot, like the shared data with Firmware Update secure partition. Does nrfsdk-mcuboot work with firmware update secure partition? Or you have another plan to support firmware update? 

Perhaps you can elaborate? Is the question here if/how you can update TF-M?

jli157@intel said:

Does nrfsdk-mcuboot support using QSPI flash memory as the swap storage on nrf53 DK? 

Yes, you can have the secondary slot (1) on external flash, and then copy it to slot 0 during activation.

jli157@intel said:

However, I'm wondering why Nordic chose using the static library instead of the package "cryptocell-312-runtime" inside TF-M to enable CryptoCell for TF-M? Are there some special considerations or some limitations? 

The cryptocell-312-runtime is provided by ARM for use on some other devices, but it not and cannot be used on Nordic devices. The nrf_cc312_mbedcrypto is based on ARM libraries but has (among other things) adaptations for the nRF platform.

jli157@intel said:

Is it okay I'm using the same thread to ask more questions about nrf_security? I'm still having a couple of questions. Or should I open a new thread? 

I would prefer it if you make a new thread for separate questions. That makes it easier to maintain the overview, and also makes it easier to delegate some questions to other colleagues of mine.

Einar

[jli157@intel]

We are thinking to use the firmware update secure partition from TF-M to do the firmware update in the future, which means the Zephyr application will use the firmware update TF-M APIs to populate new firmware data to the secondary partitions. What's your suggestions for this feature? 

Okay, I'll open a new ticket for other questions for nrf_security. 

[Einar Thorsrud]

Hi,

We do not currently have any solution for updating only the secure partition. I have asked the team working on it to look into it.

For now, you can either enable serial recovery in MCUBoot or use the dfu_target_mcuboot APIs or direct flash read/write to secondary partition (dfu_target_mcuboot.c). Or see in dfu_target_stream.c how it's implemented there with flash read/writes. Then to set the image as active you would have to use mcuboot.h if you use flash write/read operations directly.