What are the options for using TF-M with MCUboot?

[Riku Karttunen]

Hi,

I would like to use MCUboot together with TF-M for an application running on nRF9160 in order to have the security features provided by TF-M while having upgrade capabilities. I can see that currently there are limitations when it comes to using the Nordic security backend + TF-M + MCUboot. What are my options for making this combination (TF-M + MCUboot) work currently? Is there an alternative to the Nordic backend and how would it differ if so? Can we expect the limitation regarding the Nordic backend to be removed any time soon?

[Elfving]

Hmm no that error is a bit new to me.

It could be the custom board. Could you try it with a DK as well to verify if that is the case?

Best regards,

Elfving

[Riku Karttunen]

Hey,

I've done some more testing and it seems that I'm missing something when trying to add MCUboot to an app that is using TF-M. For example my own custom application on a custom board ends up stuck in a hard fault handler or somewhere completely random place in the code (seen when printing backtrace after attaching to the frozen app with a debugger) straight from boot. All I can see before that is this:

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

I also did a quick test with Zephyr's tfm_ipc sample where I just added CONFIG_BOOTLOADER_MCUBOOT=y. This resulted in a boot loop repeating these messages:

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot

I don't know if this boot loop and the situation of my own application are related in any way but it feels like this could be the same problem but different symptoms. It seems that I'm missing something important when trying to integrate MCUboot + TF-M. Can you see anything obviously wrong here and do you have any pointers on how to do this kind of integration?

The board I used in my own application is a custom one but it is equivalent to nrf9160dk except the peripherals are different. I used nrf9160dk when testing with the tfm_ipc sample.

[Elfving]

Hey again Riku!

Yes, this second error is familiar. It might occur because you don't disable FPROTECT and ARM_MPU on the MCUBoot image. Though it is a bit hard to say, as TF-M will reboot on an internal error, so it could be anything really. 

Riku Karttunen said:

I don't know if this boot loop and the situation of my own application are related in any way but it feels like this could be the same problem but different symptoms.

Well I am not sure about the first error, but does this help anything?

Best regards,

Elfving

[Riku Karttunen]

Hey,

I managed to get both the sample and my application booting successfully into the application and everything seems to work nicely. The key was CONFIG_MCUBOOT_CLEANUP_ARM_CORE=y.

Now the way I ended up with this solution doesn't make sense to me. When I build the tfm_ipc sample with these changes

diff --git a/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf b/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf
new file mode 100644
index 0000000000..c8ecce2427
--- /dev/null
+++ b/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf
@@ -0,0 +1,2 @@
+CONFIG_FPROTECT=n
+CONFIG_ARM_MPU=n
diff --git a/samples/tfm_integration/tfm_ipc/prj.conf b/samples/tfm_integration/tfm_ipc/prj.conf
index 7a4c680c6c..d5ba8884f5 100644
--- a/samples/tfm_integration/tfm_ipc/prj.conf
+++ b/samples/tfm_integration/tfm_ipc/prj.conf
@@ -1,6 +1,7 @@
 CONFIG_BUILD_WITH_TFM=y
 CONFIG_TFM_IPC=y
 CONFIG_REBOOT=y
+CONFIG_BOOTLOADER_MCUBOOT=y
 
 # The Zephyr CMSIS emulation assumes that ticks are ms, currently
 CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000

and this build command

west build -p -b nrf9160dk_nrf9160_ns -- -Dmcuboot_OVERLAY_CONFIG=$(pwd)/mcuboot_overlay.conf

the sample ends up in a hard fault handler with these prints

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

Now when I apply those two overlay config options via the command line like this

west build -p -b nrf9160dk_nrf9160_ns -- -Dmcuboot_CONFIG_FPROTECT=n -Dmcuboot_CONFIG_ARM_MPU=n

the sample works perfectly fine.

I checked the diff for .config of those two builds and the only thing that changes is that CONFIG_MCUBOOT_CLEANUP_ARM_CORE=y gets set in the one where I pass the options via the command line. Why does this happen? I'm using the current sdk-nrf master branch (a8100e9bd0a602365fe86a8248d233017cab0c50) without any changes to the revisions in sdk-nrf west.yml.

[Elfving]

Hey Riku!

Ah right, seems that I forgot about CONFIG_MCUBOOT_CLEANUP_ARM_CORE. You would need that as well. I am a bit surprised it wasn't added automatically in the master branch though. You said you were using the master for both of those cases?

Best regards,

Elfving