Attachments (2) Download All
Nordic Case Info
  • Case ID: 341351
Options

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:

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:

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:

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

Parents
  • 0

    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

  • 0 in reply to Vidar Berg

    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:

    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.

  • 0 in reply to puz_md

    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 

Reply Children
  • 0 in reply to Vidar Berg

    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

  • 0 in reply to puz_md

    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

  • 0 in reply to Vidar Berg

    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

  • 0 in reply to puz_md

    Hi Michael,

    Glad to hear that it is working on your end as well. Just remember to test this with your bootloader hex from v2.5.3 if you have devices out in the field with this version of the bootloader.

    puz_md said:
    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?

    The problem is that dynamic partitioning is not supported with your configuration. This was partially addressed by the PR I linked to earlier. I will report this internally.

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

    Did you verify that the netcore image got updated even if you had additional address verification enabled? 

    puz_md said:
    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?

    Kconfig.sysbuild changes the default value to 'y'  instead of explicitly enabling the HCI IPC image in sysbuild.conf. This allows the project to be built for other single core  devices (nRF52/nRF54) without triggering any errors because the symbol can't be selected. You are selecting HCI IPC instead of the IPC radio firmware when you select SB_CONFIG_NETCORE_HCI_IPC.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Hi Vidar,

    Vidar Berg said:
    Glad to hear that it is working on your end as well. Just remember to test this with your bootloader hex from v2.5.3 if you have devices out in the field with this version of the bootloader.

    I tested it already and it worked.

    The problem was that I did not program the new mcuboot binary and test the following issue:

    Vidar Berg said:
    puz_md said:
    Do I need the "CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=n"? It seems my project also works without it...

    Did you verify that the netcore image got updated even if you had additional address verification enabled? 

    You're right, it doesn't work without turning address verification off! I forgot to program the new mcuboot for testing.

    Unfortunately, I ran into another problem now with the new mcuboot: It programs the app core software just fine. But the net core software is not removed/invalidated from the slot after updating the net core (which seems to work by the way): During each power cycle, the system stays for many seconds in mcuboot and probably tries to update the net core again. After the update try, I can connect via Auterm again and the slot readout reports has the following bits set:

    The app core is updated just fine and Auterm doesn't report an image in the slot anymore (and the bootloader does not consume extra time during each startup after the first update attempt). Any idea what could be wrong with the net core processing this time?

    By the way, only if I erase the flash pages of the secondary slot, in Auterm "Slot 1" disappears and I can upload another update again.

    Best regards,
    Michael

Terms of service