Bug in Secure Boot / b0n related partition configuration for nRF5340 under sysbuild in SDK v2.9.0?

[puz_md]

Hi, I'm having problems with migrating my project to SDK v2.9.0. I'm using mcuboot and I want to use b0n on the net core and update support for the net core application via mcuboot (running on the application core). Everything was running fine on the SDK v2.5.3 with multi-image build, and I managed to port the project to sysbuild on SDK v2.9.0 with mcuboot, but when I try to enable the net core update, the build process fails.

I tried to re-create the configuration with the peripheral_lbs sample (SDK v2.9.0). After checking out the sample project, I added sysbuild.conf to the project folder:

#SB_CONFIG_NETCORE_APP_UPDATE=y
#SB_CONFIG_SECURE_BOOT_NETCORE=y
#SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="C:/<mypath>/mykey.pem"

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_MCUBOOT_MODE_SINGLE_APP=n
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="C:/<mypath>/mykey.pem"
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

SB_CONFIG_NETCORE_HCI_IPC=y

So far, everything compiled without any problem. But when I try to enable the upper three lines (for b0n and net core update support, the build process fails: I receive the following error message seven times before the build process is aborted:

In file included from C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h:12,
                 from C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/src/bootutil_priv.h:33,
                 from C:/ncs/v2.9.0/bootloader/mcuboot/boot/bootutil/src/tlv.c:24:
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h: In function '__flash_area_ids_for_slot':
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:20:37: error: 'PM_MCUBOOT_PRIMARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
   20 | #define FLASH_AREA_IMAGE_1_SLOTS    PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:38:29: note: in expansion of macro 'FLASH_AREA_IMAGE_1_SLOTS'
   38 |                             FLASH_AREA_IMAGE_1_SLOTS
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:55:9: note: in expansion of macro 'ALL_AVAILABLE_SLOTS'
   55 |         ALL_AVAILABLE_SLOTS
      |         ^~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:20:37: note: each undeclared identifier is reported only once for each function it appears in
   20 | #define FLASH_AREA_IMAGE_1_SLOTS    PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:38:29: note: in expansion of macro 'FLASH_AREA_IMAGE_1_SLOTS'
   38 |                             FLASH_AREA_IMAGE_1_SLOTS
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:55:9: note: in expansion of macro 'ALL_AVAILABLE_SLOTS'
   55 |         ALL_AVAILABLE_SLOTS
      |         ^~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:20:62: error: 'PM_MCUBOOT_SECONDARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_SECONDARY_ID'?
   20 | #define FLASH_AREA_IMAGE_1_SLOTS    PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
      |                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:38:29: note: in expansion of macro 'FLASH_AREA_IMAGE_1_SLOTS'
   38 |                             FLASH_AREA_IMAGE_1_SLOTS
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:55:9: note: in expansion of macro 'ALL_AVAILABLE_SLOTS'
   55 |         ALL_AVAILABLE_SLOTS
      |         ^~~~~~~~~~~~~~~~~~~

It appears like the build system suddenly is using different partition names when I enable b0n?

Under SDK v2.5.3, the app core partitions were just named mcuboot_primary (mcuboot_primary_app) and mcuboot_secondary. Both net core update and app core update were loaded in mcuboot_secondary for flashing. Now, under SDK v2.9.0 and sysbuild, there seems to be a different naming convention (see PM_MCUBOOT_PRIMARY_1_ID error messages).

Some feedback would be appreciated. Is this a bug in the build/configuration system? Or is there a new convention for partition naming that changes when b0n is enabled?

Best regards,
Michael

PS: Update: I tried disabling SB_CONFIG_NETCORE_APP_UPDATE, but leave secure boot for the net core active. In this case, I get the following error messages:

In file included from C:/ncs/v2.9.0/nrf/include/dfu/pcd.h:28,
                 from C:/ncs/v2.9.0/bootloader/mcuboot/boot/zephyr/main.c:95:
C:/ncs/v2.9.0/nrf/include/dfu/pcd_common.h: In function 'pcd_write_cmd_lock_debug':
C:/ncs/v2.9.0/nrf/include/dfu/pcd_common.h:39:25: error: 'PM__PCD_SRAM_ADDRESS' undeclared (first use in this function); did you mean 'PM_SRAM_ADDRESS'?
   39 | #define PCD_CMD_ADDRESS PM__PCD_SRAM_ADDRESS
      |                         ^~~~~~~~~~~~~~~~~~~~

Beside 'pcd_write_cmd_lock_debug', the same error occurs for functions 'pcd_read_cmd_done' and 'pcd_read_cmd_lock_debug'.

[Vidar Berg]

Hi,

Are you using a static partition file from your existing project? '_primary_1' is the emulated flash partition in RAM used to transfer the FW update to the network core. 

Project I used to generate the memory report above (only verified that it builds without errors)

peripheral_lbs_dfu_test_nrf5340_v290.zip

Best regards,

Vidar

[puz_md]

Hi Vidar,

thanks for checking. Unfortunately, your sample uses external flash and if I disable this in the configuration, I get the same error message about mcuboot_primary_1  again:

#SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

Could you please look a little bit deeper into this? Normally, all partitions should be generated by the build system, which I can use as a basis for my static partitioning later. At least this is what the Nordic Academy course said. If the build system's partitioning mechanism does not work by itself without external flash, this is a software bug in my opinion...

Also, I noticed that the build system also creates mcuboot_secondary_1 in DT_CHOSEN(nordic_pm_ext_flash). Under SDK v2.5.3, I could use the same slot (mcuboot_secondary) for app core and net core updates. How can I get this running in SDK v2.9.0? ALso, in SDK v2.5.3, I didn't have a ram_flash partition or region.

I do not have external flash on my board, and I cannot reserve another 256K of internal flash for the net core's update image. Up until now, I used application specific code to transfer new firmware images directly into mcuboot_secondary and flag them for confirmed update via mcuboot (executed upon the next system restart). Mcuboot seemed to detect by itself whether this was an app core or a net core image (maybe based on metadata included in the signatures). We need to keep this convention in our update process.

[Vidar Berg]

Hi,

In that case, please have a look at this PR: https://github.com/nrfconnect/sdk-mcuboot/pull/397. I just assumed you had the secondary slots in external flash. You should also be using the generated partition file from your v2.5.3 project as a static partition file in your new project to ensure the memory layout remains the same. 

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.html#static_partition_requirement_for_dfu 

[puz_md]

Hi, I tried using my pm_static from the old project, and I can update the application core if I disable the net core update and secure boot on the net core (see first code in my initial post). But it does not compile anymore if I try to enable the net core update, both with and without pm_static.yml. That's why I tried enabling mcuboot including net core updates from scratch, based on a sample project. Which did not work, too.

I had a look at the github fix. Will this even fix my problem? It talks about mcuboot_secondary_1 and not about mcuboot_primary_1 ... will there be an updated version SDK (version 2.9.1) with the fixes in the near future?

The second link doesn't have any new information either...

Best regards,
Michael

[Vidar Berg]

Hi Michael,

I realize now after testing a bit that the linked PR does not address the issue with your configuration (non-simultaneous DFU and no external flash). I also expected mcuboot_primary_1 to already be present in your static partition file. Here is an updated version of the project which should better match your setup:

7142.peripheral_lbs_dfu_test_nrf5340_v290_non_sim.zip

Best regards,

Vidar

[puz_md]

Hi Vidar,

I think I got it working. Thanks a lot!

Concerning my configuration problems, I worked through the following steps to fix them:
(1) Create a pm_static.yml for the app core without the net core update configuration (otherwise it won't compile with SDK v2.9.0)
(2) Add the mcuboot_primary_1 partition
(3) Add the ram_flash partition
(4) Duplicate the mcuboot_secondary partition and rename the copy to mcuboot_secondary_1 with size and (end_address) adjusted to 0x40000
(5) Add "CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=n" to sysbuild\mcuboot.conf (seems to work without it, too)

In respect to these steps, I have some more questions concerning the further proceeding at Nordic Semiconductor and the nRF Connect SDK:

According to my understanding (and the partitioning training in Nordic Academy), the steps (2) through (4) should not be needed to be performed by the developer. The SDK should create partitions ready for use. Will this issue be fixed in future SDK versions?

Also, the extra (overlapping) partition definitions and the flash_ram partition were not needed in SDK v2.5.3. Will this configuration pattern also be used in future SDK versions, or is this just a workaround for the current problems?

Do I need the "CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=n"? It seems my project also works without it...

And do I need the Konfig and Kconfig.sysbuild? I've never used these files in my configuration. Currently, I'm using "SB_CONFIG_NETCORE_HCI_IPC=y" in sysbuild.conf. Does this something similar to the ipc_radio configuration in Kconfig.sysbuild?

Best regards,
Michael