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 Michael,

Thank you for the update.  I think this explains. I had enabled the overwrite only mode in my version (sysbuild.conf --> SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y)  which makes it so that the image trailer is not erased here: https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1519. I've proposed this fix to the developers for the overwrite only mode: 

diff --git a/boot/bootutil/src/loader.c b/boot/bootutil/src/loader.c
index f35ec786..fd01ef5b 100644
--- a/boot/bootutil/src/loader.c
+++ b/boot/bootutil/src/loader.c
@@ -1615,6 +1615,10 @@ boot_validated_swap_type(struct boot_loader_state *state,
                  */
                 rc = swap_erase_trailer_sectors(state,
                         secondary_fa);
+#elif defined(MCUBOOT_OVERWRITE_ONLY)
+                BOOT_LOG_INF("Erasing secondary slot");
+                rc = boot_erase_region(secondary_fa, 0, secondary_fa->fa_size);
+                assert(rc == 0);      
 #endif
                 swap_type = BOOT_SWAP_TYPE_NONE;
             }

 

Best regards,

Vidar

[puz_md]

Hi Vidar,

sorry for the confusion, but ist seems I also had the overwrite only configuration activated all along. I probably added it when evaluating your sample configuration. So we're using the same configuration and I did not test SWAP with the new SDK yet.

Your fix works on my side, too. There is only one "beauty bug": After the net core image, the whole second slot is erased now, and after the app core update, only the first and the last sector is erased. Works both, but would be nice if the behavior was the same.

Unfortunately, the fix didn't make it into SDK v2.9.1 which was released today. There is also another fix still missing that was discussed with AmandaH about 1-2 weeks ago in another ticket and is still missing from the SDK. This fix is necessary for correct application of the net core's static partitioning file: Remove set(static_configuration) from C:\ncs\v2.9.0\nrf\cmake\sysbuild\partition_manager.cmake, line 126.

Please talk to your developer team if they can bring both fixes in a v2.9.x release (so that I don't have to migrate again to SDK v3.0.0 which probably has major changes).

Further, it would be good to have these two bugs in the "Known Issues" section of the SDK documentation (sections 'Bootloader' and 'Build System'). Maybe it can help other developers, too.

Best regards,
Michael

[Vidar Berg]

Hi Michael,

Are you using the bootloader you had from v2.5.3 in production? In that case, I would have considered to continue using the same bootloader hex to ensure you have the same bootloader on all your devices. 

puz_md said:

Your fix works on my side, too. There is only one "beauty bug": After the net core image, the whole second slot is erased now, and after the app core update, only the first and the last sector is erased. Works both, but would be nice if the behavior was the same.

I was considering whether to erase just the header and trailer but decided to erase the whole slot for simplicity. You can use the code here as reference if you want to erase just the header+trailer.

I've created a ticket for this case in our internal bug tracker so the developers can follow up on the issues we've discussed.

Best regards,

Vidar