How to disable b0 and only keep MCUBoot? (Sysbuild and nested example configs make it hard.)

I'm having a hard time replicating the config needed to be DFU compatible with a build from an earlier SDK version.
Earlier version used only a non upgradeable MCUBoot with upgradeable app and net images built as multi-image.
New needs to build on SDK 3.x and still be compatible with this initial flash layout and MCUBoot.

Due to the nested and convoluted configuration structure and the earlier project being based on nRF5340DK board with overlays it appears to now always bring in b0.
If I disable b0 I also loose boot_write_img_confirmed() meaning I most likely lost DFU from MCUBoot.

There must be something I am missing, but I do find the configuration docs very hard to navigate.

Parents

0 AHaug 9 months ago

Hello,

I assume that you will be using BLE for the update image transport since the netcore is a relevant core in your project? If so, then the academy lesson 9, exercise 5 should cover a sample for what you need (at the bottom of this link you will see https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/ and https://academy.nordicsemi.com/simultaneous-updates-for-both-cores-of-the-nrf5340/ with the solution here: https://github.com/NordicDeveloperAcademy/ncs-inter/tree/main/l9/l9_e5_nrf5340_both_sol

The reason for why b0 is pulled in is because the need for a b0n for the netcore that only handles the update for the netcore and does not act as a first stage bootloader in a setup where you have an uppgradable MCUboot

Let me know if this narrows down the configuration docs, and please feel free to ask follow up questions

Kind regards,
Andreas
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Kyrre Aalerud 9 months ago in reply to AHaug

OTA has been used, but we also run a USB based fw updating during testbench runs.
In the future we will have to deprecate the support for updating old devices when we move to fully updateable bootloaders and net/app images but for now we need it to be compatible with a non updateable mcuboot and updateable net/app images.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 AHaug 9 months ago in reply to Kyrre Aalerud

Then the previous mentioned sample together with this https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-4-dfu-over-usb/ and https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-1-dfu-over-uart/ should cover what you need. Neither of these solutions uses NSIB. The BLE sample I initially mentioned only uses the network core b0 (b0n), which is required for updating the netcore

Kind regards,
Andreas
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Kyrre Aalerud 9 months ago in reply to AHaug

I have actually been inspecting the build logs and the partitions.yml to figure out why it (the not static parts) has changed so much and I was completely mistaken. Both builds list b0n and NSIB. However the new resulting files contain two smaller partitions in addition to app and first stage bootloader for application core and same for network core. partitions_CPUNET.yml only changed with hci_rpmsg being renamed to hci_ipc but in partitions.yml the introduction of s0, s0_image, s0_pad, s1, s1_image, s1_pad while keeping mcuboot_primary_app/flash_primary and mcuboot_secondary is confusing.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Kyrre Aalerud 9 months ago in reply to AHaug

I have actually been inspecting the build logs and the partitions.yml to figure out why it (the not static parts) has changed so much and I was completely mistaken. Both builds list b0n and NSIB. However the new resulting files contain two smaller partitions in addition to app and first stage bootloader for application core and same for network core. partitions_CPUNET.yml only changed with hci_rpmsg being renamed to hci_ipc but in partitions.yml the introduction of s0, s0_image, s0_pad, s1, s1_image, s1_pad while keeping mcuboot_primary_app/flash_primary and mcuboot_secondary is confusing.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 Kyrre Aalerud 9 months ago in reply to Kyrre Aalerud

I generated the maps with ninja to make it easier to see.
Unless I removed my static defs for the partitions I would get text overflow so it was including something new, and the maps show what I mean. I used an old release point for reference here so I would be sure the map was "the old one".

Fullscreen pm_report_3.0.2.txt Download

  external_flash (0x40000000 - 1048576kB):
+----------------------------------------------+
| 0x0: external_flash (0x40000000 - 1048576kB) |
+----------------------------------------------+

  flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
+---0x0: b0_container (0x8000 - 32kB)--------------+
| 0x0: b0 (0x8000 - 32kB)                          |
+---0x8000: s0 (0xc000 - 48kB)---------------------+
| 0x8000: s0_pad (0x200 - 512B)                    |
+---0x8200: s0_image (0xbe00 - 47kB)---------------+
| 0x8200: mcuboot (0xbe00 - 47kB)                  |
+---0x14000: s1 (0xc000 - 48kB)--------------------+
| 0x14000: s1_pad (0x200 - 512B)                   |
| 0x14200: s1_image (0xbe00 - 47kB)                |
+---0x20000: mcuboot_primary (0x68000 - 416kB)-----+
| 0x20000: mcuboot_pad (0x200 - 512B)              |
+---0x20200: app_image (0x67e00 - 415kB)-----------+
+---0x20200: mcuboot_primary_app (0x67e00 - 415kB)-+
| 0x20200: app (0x67e00 - 415kB)                   |
+--------------------------------------------------+
| 0x88000: mcuboot_secondary (0x68000 - 416kB)     |
| 0xf0000: EMPTY_0 (0x6000 - 24kB)                 |
| 0xf6000: user_storage (0x2000 - 8kB)             |
| 0xf8000: settings_storage (0x2000 - 8kB)         |
| 0xfa000: littlefs_storage (0x6000 - 24kB)        |
+--------------------------------------------------+

  otp (0x2fc - 764B):
+------------------------------------+
| 0xff8100: provision (0x280 - 640B) |
| 0xff8380: otp (0x7c - 124B)        |
+------------------------------------+

  sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB)           |
| 0x20002000: sram_primary (0x6e000 - 440kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8580 - 33kB)             |
| 0x1008580: provision (0x280 - 640B)        |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_ipc (0x37800 - 222kB)       |
+--------------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

Fullscreen pm_report_2.5.txt Download

  external_flash (0x40000000 - 1048576kB):
+----------------------------------------------+
| 0x0: external_flash (0x40000000 - 1048576kB) |
+----------------------------------------------+

  flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x74000 - 464kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x73e00 - 463kB)-+
| 0xc200: app (0x73e00 - 463kB)                   |
+-------------------------------------------------+
| 0x80000: mcuboot_secondary (0x74000 - 464kB)    |
| 0xf4000: EMPTY_0 (0x2000 - 8kB)                 |
| 0xf6000: user_storage (0x2000 - 8kB)            |
| 0xf8000: settings_storage (0x2000 - 8kB)        |
| 0xfa000: littlefs_storage (0x6000 - 24kB)       |
+-------------------------------------------------+

  otp (0x2fc - 764B):
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB)           |
| 0x20002000: sram_primary (0x6e000 - 440kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0x8800 - 34kB)-+
| 0x1000000: b0n (0x8580 - 33kB)             |
| 0x1008580: provision (0x280 - 640B)        |
+---0x1008800: app (0x37800 - 222kB)---------+
| 0x1008800: hci_rpmsg (0x37800 - 222kB)     |
+--------------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

0 Kyrre Aalerud 9 months ago in reply to Kyrre Aalerud

Am I right in that this is caused by the SB_CONFIG_SECURE_BOOT_APPCORE sysbuild.conf directive?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 AHaug 9 months ago in reply to Kyrre Aalerud

Kyrre Aalerud said:
Am I right in that this is caused by the SB_CONFIG_SECURE_BOOT_APPCORE sysbuild.conf directive?

Yes, SB_CONFIG_SECURE_BOOT_APPCORE enables NSIB. You should be able to use SB_CONFIG_SECURE_BOOT_NETCORE=y alone instead to enable b0n for the netcore and not b0, i.e NSIB

Kind regards,
Andreas
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel