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.

[jli157@intel]

Einar, 

You mean you haven't enabled the firmware update secure partitions (FWU) for firmware update? So, what's Nordic's plan to support FWU? You will use another approach instead of FWU provided by TF-M?