Support on nrf9160 SDK V2.2 to V2.4 OTA upgrade

RE: Support on nrf9160 SDK V2.2 to V2.4 OTA upgrade

Didrik Rokhaug — Mon, 31 Jul 2023 13:07:23 GMT

[quote user="GD_Electronics"]1) The current application based on V2.2 has default partitioning which is dynamic and now if we consider to upgrade to SDK V2.4 changing the memory partition to static , can we define the current image address as static in V2.4 i.e pointing to previous image address ? this shall resolve the issue believed to be encountered during OTA .[/quote]

In the build folder there is a file called partitions.yml, which specifies how the flash is partitioned.

This file can be copied to your (new) project directory (i.e. next to the CMakeLists.txt and prj.conf files), and renamed to "pm_static.yml", and the Partition Manager will automatically use the same flash partitions.

Note that this will configure all the partitions statically, while you only need the bootloader-related partitions to be statically configured for the FOTA to work. There are some cases (e.g. when going from SPM to TF-M) where you don't want all the partitions to be statically defined, as some of them might change.

[quote user="GD_Electronics"]2) In regard moving from SPM -> TFM , will the device brick if we plan to downgrade from TFM(V2.4) to SPM(V2.2) in near future ?[/quote]

MCUBoot considers SPM and TF-M part of the application, so changing between the two should not cause any problems for MCUBoot.

RE: Support on nrf9160 SDK V2.2 to V2.4 OTA upgrade

GD_Electronics — Mon, 31 Jul 2023 10:51:41 GMT

Thank you for your feedback. i've couple of queries as mentioned below

1) The current application based on V2.2 has default partitioning which is dynamic and now if we consider to upgrade to SDK V2.4 changing the memory partition to static , can we define the current image address as static in V2.4 i.e pointing to previous image address ? this shall resolve the issue believed to be encountered during OTA .

2) In regard moving from SPM -> TFM , will the device brick if we plan to downgrade from TFM(V2.4) to SPM(V2.2) in near future ?

Thank you .

Regards,

Anil

RE: Support on nrf9160 SDK V2.2 to V2.4 OTA upgrade

Didrik Rokhaug — Wed, 19 Jul 2023 14:26:02 GMT

Hi,

[quote user=""]They refer to the change to the memory model implemented in 2.4.0 which they believe will not be compatible with applications built using V2.2.0 or lower.[/quote]

Are you talking about the flash partition layout, or something else?

The partition layout is by default configured dynamically on each build, which will typically mean that when you change SDK version for the application, the application will get a different flash partition layout than the bootloader on the devices have. This problem can be fixed by using a static partition configuration: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrf/scripts/partition_manager/partition_manager.html#static-configuration

The easiest way to do this is to copy <build directory>/partitions.yml to your project directory (next to CMakeLists.txt and prj.conf), and rename it to pm_static.yml.

A small sidenote here that I'll come back to later: Only the partitions used by the bootloader need to be statically defined. These are the mcuboot, mcuboot_pad, mcuboot_primary and mcuboot_secondary partitions (assuming you only have mcuboot, and not multiple bootloaders).

[quote user="GD_Electronics"]We also have a concern about how peripherals are used. TFM needs UART1, used to communicate with the appliance.[/quote]

TF-M only uses UART1 for logging. If you do not need logs from TF-M, you can set CONFIG_TFM_LOG_LEVEL_SILENCE to free up the UART.

Alternatively, if you want TF-M logs on bootup and when handling a fatal error, but not when the application is running, you can use CONFIG_TFM_SECURE_UART_SHARE_INSTANCE.

[quote user="GD_Electronics"]Additionally, we think it might be risky to do an OTA from an SPM to TFM application, as we are unsure what might happen if a power failure or reset occurs at an inopportune time. Normally if this occurs the device will just revert to a working image. However, we don't know how the SPM to TFM update is handled internally in the chip, other than there is a region in memory reserved for these. If this does prove to a risk, with no fallback mechanism, only option left is to go for a one-time update.[/quote]

Seen from the bootloader, both the SPM and TF-M is just part of the application. The bootloader doesn't know about either. So there shouldn't really be any difference on that front. When it comes to flash partition layout, the important parts are the mcuboot_primary and secondary slots. How the application and SPM/TF-M splits these slots is not important (for the bootloader).

This means that in your pm_static.yml file, you only need to specify the bootloader related partitions, plus any other partitions you want to be static (e.g. if the application has a partition it uses for persistent storage).

[quote user="GD_Electronics"]The primary problem we ran into with the upgrade was that authentication with the server was failing. As far as we can tell we will need to use the "TFM profile LARGE", as the "minimal" profile does not support 512-bit hashing, and it looks like the "LARGE" profile will require flash layout changes. But this still needs further investigation.[/quote]

Configuring TF-M is not optimal at the moment, but you can use TFM_PROFILE_TYPE_NOT_SET (which is basically a custom profile), and then look in <build directory>/zephyr/.config for PSA_WANT options that you don't need, which you can then disable (in the prj.conf file) to reduce the size of TF-M.

Best regards,

Didrik

RE: Support on nrf9160 SDK V2.2 to V2.4 OTA upgrade

GD_Electronics — Wed, 19 Jul 2023 09:53:26 GMT

Adding more details below which might help in further investigation..

Based on our preliminary Analysis it was found and suspected the issue could be because of dynamic partition management, but this was not our only concern when moving to versions of the nRF SDK newer than 2.2.0. Based on our initial testing a more pressing issue is the need to switch from using the SPM (secure partition manager), which we currently use, to the TFM (Trusted Firmware Module).

The primary problem we ran into with the upgrade was that authentication with the server was failing. As far as we can tell we will need to use the "TFM profile LARGE", as the "minimal" profile does not support 512-bit hashing, and it looks like the "LARGE" profile will require flash layout changes. But this still needs further investigation.

We also have a concern about how peripherals are used. TFM needs UART1, used to communicate with the appliance. We did remap all peripherals to be compatible with TFM, which seemed to work OK. However, when attempting to downgrade a device OTA (going from post 2.2.0 to 2.2.0 or earlier) the device was bricked, which we think is because of this remapping. Again, this also needs further investigation.

Additionally, we think it might be risky to do an OTA from an SPM to TFM application, as we are unsure what might happen if a power failure or reset occurs at an inopportune time. Normally if this occurs the device will just revert to a working image. However, we don't know how the SPM to TFM update is handled internally in the chip, other than there is a region in memory reserved for these. If this does prove to a risk, with no fallback mechanism, only option left is to go for a one-time update.

Kindly let us know your thoughts on this.

Thank you

Regards,

Anil