nRF52832 b0+mcuboot+app

[Alex D]

Hi,

Trying to structure image in the following way:

b0

mcuboot 1

mcuboot 2

app

With the following setup:

App prj.conf:

```

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_SECURE_BOOT=y

CONFIG_SB_SIGNING_KEY_FILE="nsib_priv.pem"

```

./child_image/mcuboot.conf:

```

CONFIG_SIZE_OPTIMIZATIONS=y

CONFIG_SINGLE_APPLICATION_SLOT=y

CONFIG_MCUBOOT_SERIAL=y

CONFIG_UART_CONSOLE=n

CONFIG_MCUBOOT_INDICATION_LED=y

``

building return error:

```

warning: UPDATEABLE_IMAGE_NUMBER (defined at
/home/ab/ncs/v2.6.0/bootloader/mcuboot/boot/zephyr/Kconfig:596,
/home/ab/ncs/v2.6.0/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig:89, subsys/dfu/Kconfig:88) was
assigned the value '2' but got the value '1'. See
docs.zephyrproject.org/.../kconfig.html and/or look up
UPDATEABLE_IMAGE_NUMBER in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

warning: user value 2 on the int symbol UPDATEABLE_IMAGE_NUMBER (defined at /home/ab/ncs/v2.6.0/bootloader/mcuboot/boot/zephyr/Kconfig:596, /home/ab/ncs/v2.6.0/nrf/samples/common/mcumgr_bt_ota_dfu/Kconfig:89, subsys/dfu/Kconfig:88) ignored due to being outside the active range ([1, 1]) -- falling back on defaults

error: Aborting due to Kconfig warnings

```

Please help to resolve the issue

[AHaug]

Hi,

I would recommend that you have a look at the bootloader and DFU/FOTA lesson in the new course on our academy pages: https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/. The first exercise there showcases how to do serial recovery. The author of the lesson has also this repository which might be of help w.r.t implementing a single image serial recovery solution for your application https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery

Do note that if you intend to implement a serial recovery solution you will miss out on some of fallback mechanics that comes with regular FOTA with a secondary application slot

Kind regards,
Andreas

[Alex D]

Hi,

Saw the lesson, it covers only simply one-stage scheme, not including b0 first-stage bootloader.

Author also has an example of how to update bootloader here:

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/updatable_bootloader

but this example implements dual-slot solution, I need dual-slot for bootloader and single-slot for application

Please help

[Alex D]

 AHaug Hi, any updates?

[AHaug]

Hi,

Alex D said:

 AHaug Hi, any updates?

Working day in Norway is weekdays between 8 and 16 Central European Standard Time, so outside of this window you will have to be patient for a reply

If possible, it would be nice if you could post logs and code using the insert -> Code function to increase readability

Alex D said:

Tried to build serial_recovery_nsib project with nrf52dk_nrf52832 configuration, getting this error:

As it is stated in the requirements of the unofficial sample I've created it is only supported for the nRF52840DK, and no other boards. If you wish to port the board you will have to go through the academy courses in detail as well as the partition manager documentation to learn how static partitioning works. Specially lesson 8 in the academy course I referred to yesterday should be a good resource 

1. https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/
   1. https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/multi-image-builds-and-the-partition-manager/
2. Partition manager https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html 
   1. Static partitioning https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html#adding-a-static-partition 

You can compile it for the 52DK, but I give you no guarantee that it works by following the same steps. To do this, you can simply remove the static partition that has been used there and it should compile using the dynamic partitioning instead. The default partition manager report should look like shown below. 

Next you can copy the partitioning that has been generated (located in \build\partitions.yml) and copy the contents into your on pm_static.yml and make the modifications to suit your applications needs. Follow the rules that is written in the partition manager documentation w.r.t locations of partitions, naming conventions and paddings. This is what I did when I created the static partitioning for the 52840DK

serial_recovery_nsib\build>ninja partition_manager_report
[1/1] cmd.exe /C "cd /D C:\Nordic\SDKs\ncs\my_projects\2.5..._projects/2.5.0/serial_recovery_nsib/build/partitions.yml"
flash_primary (0x80000 - 512kB):
+--------------------------------------------------+
+---0x0: b0_container (0x8000 - 32kB)--------------+
| 0x0: b0 (0x7000 - 28kB) |
| 0x7000: provision (0x1000 - 4kB) |
+---0x8000: s0 (0xc200 - 48kB)---------------------+
| 0x8000: s0_pad (0x200 - 512B) |
+---0x8200: s0_image (0xc000 - 48kB)---------------+
| 0x8200: mcuboot (0xc000 - 48kB) |
+--------------------------------------------------+
| 0x14200: EMPTY_0 (0xe00 - 3kB) |
+---0x15000: s1 (0xc200 - 48kB)--------------------+
| 0x15000: s1_pad (0x200 - 512B) |
| 0x15200: s1_image (0xc000 - 48kB) |
+--------------------------------------------------+
| 0x21200: EMPTY_1 (0xe00 - 3kB) |
+---0x22000: mcuboot_primary (0x2f000 - 188kB)-----+
| 0x22000: mcuboot_pad (0x200 - 512B) |
+---0x22200: app_image (0x2ee00 - 187kB)-----------+
+---0x22200: mcuboot_primary_app (0x2ee00 - 187kB)-+
| 0x22200: app (0x2ee00 - 187kB) |
+--------------------------------------------------+
| 0x51000: mcuboot_secondary (0x2f000 - 188kB) |
+--------------------------------------------------+

sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x20000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

I will repeat once more: If you wish to understand how this works, it will require that you read the documentation I've sent you and go through the courses properly

Kind regards,
Andreas

[Alex D]

Hi, sorry for the late reply - it were holidays.

Thank you, will try to find solution

[Alex D]

Hi again,

For the past two days been learning about partitions and how partition manager works, but still can not figure this issue out.

To be specific again: I need b0, two slots for secondary bootloaders and one more slot for application.

Look, believe it or not but its freaking hard to search through this endless list of various config options and the issue now is exactly to select the right ones, so could you please having experience with this system help me to select the right ones

[AHaug]

Hi,

I understand your frustration. The topic is quite comprehensive. I can see if I am able to provide you with a more detailed sample next week, but I can't give you any promises other than the resources provided.

Kind regards,
Andreas

[AHaug]

Hi again,

I found the time to do the work I described for you:

https://github.com/aHaugl/samples_for_NCS/tree/main/DFU/serial_recover_nsib/serial_recovery_nsib_52832

To repeat what I described previously and what I did:

1. I took the sample in https://github.com/aHaugl/samples_for_NCS/tree/main/DFU/serial_recover_nsib/serial_recovery_nsib_52840, which is the same I linked earlier 
2. Deleted the pm_static.yml 
3. Built for nrf52dk_nrf52832 with dynamic partitioning
4. Opened the generated partitions.yml located in the build folder and copied it to a pm_static.yml
5. Calculated how large mcuboot_primary needed to be to to fill the remaining gap after I've set the mcuboot_secondary partition size to be equal to the size of MCUboot:
   
   MCUboot secondary application slot ends at 0x80000 and which means that when matching the size of MCUboot (48kB) it will have to start at 0x74000.
   
   

   mcuboot_secondary:
     address: 0x74000
     end_address: 0x80000
     placement:
       after:
       - mcuboot_primary
       align:
         start: 0x1000
       align_next: 0x1000
     region: flash_primary
     share_size:
     - mcuboot_primary
     size: 0xc000

6. This means that Mcuboot_primary (and app image and app) has to end at 0x740000 and the size changes from 0x2ee00 to 0x51e00
7. Rebuild the firmware with static configuration and you will get something like this
   
   

     flash_primary (0x80000 - 512kB):
   +--------------------------------------------------+
   +---0x0: b0_container (0x8000 - 32kB)--------------+
   | 0x0: b0 (0x7000 - 28kB)                          |
   | 0x7000: provision (0x1000 - 4kB)                 |
   +---0x8000: s0 (0xc200 - 48kB)---------------------+
   | 0x8000: s0_pad (0x200 - 512B)                    |
   +---0x8200: s0_image (0xc000 - 48kB)---------------+
   | 0x8200: mcuboot (0xc000 - 48kB)                  |
   +--------------------------------------------------+
   | 0x14200: EMPTY_0 (0xe00 - 3kB)                   |
   +---0x15000: s1 (0xc200 - 48kB)--------------------+
   | 0x15000: s1_pad (0x200 - 512B)                   |
   | 0x15200: s1_image (0xc000 - 48kB)                |
   +--------------------------------------------------+
   | 0x21200: EMPTY_1 (0xe00 - 3kB)                   |
   +---0x22000: mcuboot_primary (0x51e00 - 327kB)-----+
   | 0x22000: mcuboot_pad (0x200 - 512B)              |
   +---0x22200: app_image (0x51e00 - 327kB)-----------+
   +---0x22200: mcuboot_primary_app (0x51e00 - 327kB)-+
   | 0x22200: app (0x51e00 - 327kB)                   |
   +--------------------------------------------------+
   | 0x74000: mcuboot_secondary (0xc000 - 48kB)       |
   +--------------------------------------------------+
   
     sram_primary (0x10000 - 64kB):
   +-------------------------------------------+
   | 0x20000000: sram_primary (0x10000 - 64kB) |
   +-------------------------------------------+

It might not be perfect, but it shows what I previously explained and illustrates how you can implement a dual slot secondary bootloader update + single slot application update solution in your firmware for a nRF52832dk

Let me know if this is enough to keep you going!

Kind regards,
Andreas