Secure bootloader chain + two-stage upgradable bootloader MCUBOOT

I am working with nRF connect SDK with nRF5340DK. I am compiling code using nRF connect (ncs-1.8.0) for VS code with nrf5340dk_nrf5340_cpuapp board.

prj.conf as below,

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUMGR=y
CONFIG_SECURE_BOOT=y
Using this I can enabling two-stage bootloader, here are the log,
 
*** Booting Zephyr OS build v2.7.0-ncs1 ***

Attempting to boot slot 0.

Attempting to boot from address 0x8200.

Verifying signature against key 0.

Hash: 0x12...93

Firmware signature verified.

Firmware version 1

Booting (0x8200).

*** Booting Zephyr OS build v2.7.0-ncs1 ***

I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot
*** Booting Zephyr OS build v2.7.0-ncs1 ***
I can firmware upgrade over-the-air (FOTA) for application using app_update.bin file.
Question:
1) How can I upgrade the second stage bootloader(MCUBoot bootloader)?
2) Which bin file to upload for upgrade the second stage bootloader?
Parents
  • Hi Siddharth, 

    I would suggest to have a look at this case to have an idea of how it should be handled: https://devzone.nordicsemi.com/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/274813#274813

    Then you can have a look at this case , our coworker has created a working example: 

    https://devzone.nordicsemi.com/f/nordic-q-a/85539/update-mcuboot-with-smp/358748

  • Hi Hung,

    I have tried your coworker example : https://devzone.nordicsemi.com/f/nordic-q-a/85539/update-mcuboot-with-smp/358748

    but its not updating MCUBOOT!!

     For, testing I had follow below steps,

    I make a change to MCUBoot, for example add a log in $NRF_CONNECT_SDK/bootloader/mcuboot/boot/zephyr/main.c.

    Build again, and upload the new image using mcumgr:

    mcumgr conn add acm0 type="serial" connstring="dev=/dev/ttyACM0,baud=115200,mtu=512"
    mcumgr -c acm0 image list
    mcumgr -c acm0 image upload build/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin
    mcumgr -c acm0 image list
    

    Copy the hash of the newly uploaded image, and use it to confirm it, making the new image run at next reboot, such as:

    mcumgr -c acm0 image confirm 2348de4f84cb19c1c2721662ad1275da5c21eca749da9b32db20d2c9dffb47c0
    

    Then reboot the Developement Kit. This will load the new MCUBoot image its slot. Reboot the Developement Kit again to load using the new version of MCUBoot.

    If I miss any steps let me know please.

    I did not Disable the Mass Storage feature on the device. is this required to do that?

    Why required Disabling the Mass Storage feature on the device? 

    Also I have one questions,

    How we can use both stage bootloader as MCUBOOT? as shown in below ,I am talking about second options.

    Bootloader

    Can be first-stage

    Can be second-stage

    Key type support

    Public key revocation

    SMP updates

    Downgrade protection

    Versioning

    Update methods (supported by nRF Connect SDK)

    nRF Secure Immutable Bootloader

    Yes

    No

    See list

    Yes

    No

    Yes

    Monotonic (HW)

    Dual slot execute in place (XIP)

    MCUboot

    Yes

    Yes

    See imgtool

    No

    Yes

    Yes

    Semantic (SW)

    Image swap - single primary

  • Hi Sigurd,

    Have you got chance to look into this?

    Please update on this.

    Thanks

  • Hi

    The Sample on how to use NSIB(b0) to update MCUBoot feat. SMP Server will likely not work for the nRF5340, as the nRF5340 MCUBoot samples use the external flash to work.

    I took the Machine Learning sample and simplified it to an Serial Recovery for the nRF5340 sample.

    Now I am trying to merge these samples, to make Upgradable bootloader for the nRF5340.
    I am getting build errors, so it is not working yet.

    To get an upgradable bootIoader for the nRF5340 working, I suggest that you look at my first two working samples and try to find a way to include both functionalities in the same project.

    I will also try to do this, but if we both try, it will likely be solved faster.

    Regards,
    Sigurd Hellesvik

  • Hi Sigurd,

    While debugging the NCS SDK source code, I found that It has opening wrong flash area slot to update net core image in $(ncs)\v1.8.0\bootloader\mcuboot\boot\bootutil\src\loader.c file. so some modification required for that.

    Can you please look into that and confirm this.

  • Hi

    Can you specify how it is wrong?

    Regards,
    Sigurd Hellesvik

  • Hi

    As per my understanding, image partition will be as below which can be found at $(ncs)\v1.8.0\nrf\include\flash_map_pm.h file,

    So to upgrade network core and MCUBoot, we are uploading respective image into image_3 partition. To upgrade application core, we are uploading application core image into image_1 partition.

    From MCUBoot source code, we understand that boot_validated_swap_type (boot/bootutil/src/loader.c) function takes care about swapping/upgrading image.


    While looking into detail of the function, we found that when USE_PARTITION_MANAGER is enabled in (boot/zephyr/include/sysflash/sysflash.h), it will take FLASH_AREA_IMAGE_SECONDARY as image_1. Below is respective screen-shor,

    Due to this, we thought it is reading data from invalid slot. That might be our wrong observation but we thought it will be great to share our findings if that helps to you.

    Also, I believe while executing below command, it is uploading image into image_3 partition. Correct me if I am wrong.

Reply
  • Hi

    As per my understanding, image partition will be as below which can be found at $(ncs)\v1.8.0\nrf\include\flash_map_pm.h file,

    So to upgrade network core and MCUBoot, we are uploading respective image into image_3 partition. To upgrade application core, we are uploading application core image into image_1 partition.

    From MCUBoot source code, we understand that boot_validated_swap_type (boot/bootutil/src/loader.c) function takes care about swapping/upgrading image.


    While looking into detail of the function, we found that when USE_PARTITION_MANAGER is enabled in (boot/zephyr/include/sysflash/sysflash.h), it will take FLASH_AREA_IMAGE_SECONDARY as image_1. Below is respective screen-shor,

    Due to this, we thought it is reading data from invalid slot. That might be our wrong observation but we thought it will be great to share our findings if that helps to you.

    Also, I believe while executing below command, it is uploading image into image_3 partition. Correct me if I am wrong.

Children