Secure bootloader chain + two-stage upgradable bootloader MCUBOOT

[Siddharth Kachhia]

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?

[Hung Bui]

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

[Siddharth Kachhia]

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

[Siddharth Kachhia]

Hi ,

I have looked into the Machine Learning sample and I am able to build multi-image build with the following child images : 

• MCUboot bootloader

• Bluetooth HCI RPMsg

  Till, this I have no issue but not find any details for how to do DFU for network core. 

[Sigurd Hellesvik]

Hi

Here are how I do DFU for the Machine learning sample:

west build -p -b nrf5340dk_nrf5340_cpuapp
west flash --erase

Then I make edits to src/main and zephyr/samples/bluetooth/hci_rpmsg/src/main.c

Reset the nRF5340DK when holding Button1 to enter Serial Recovery Mode.

west build -p -b nrf5340dk_nrf5340_cpuapp
mcumgr conn add acm1 type="serial" connstring="dev=/dev/ttyACM1,baud=115200,mtu=512"
mcumgr -c acm1 image list
mcumgr -c acm1 image upload -n 3 build/zephyr/net_core_app_update.bin
#wait 2 minutes to allow Network Core to copy image.
mcumgr -c acm1 image upload build/zephyr/app_update.bin
nrfjprog --reset

After this, I can see the new prints I added to the files in the terminal.

Is this what you were looking for?

Regards,
Sigurd Hellesvik

[Siddharth Kachhia]

Hi ,

Yes. This looks working but it is not having support of secure bootloader chain. I would like to add Secure bootloader chain to upgrade MCUBoot in a single application.

In summary, we would like to have a single firmware which can supports,

• Updating of network core (Using net_core_app_update.bin) 
• Updating application core (Using app_update.bin)
• Updating 2nd stage MCUboot bootloader (Using signed_by_mcuboot_and_b0_s1_image_update.bin)

I hope my requirements are clear now.

Please guide/suggest me as our product development is blocked due to this. I hope you understand criticality.

[Siddharth Kachhia]

Hi Sigurd,

Have you got chance to look into this?

Please update on this.

Thanks

[Sigurd Hellesvik]

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

[Siddharth Kachhia]

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.

[Sigurd Hellesvik]

Hi

Can you specify how it is wrong?

Regards,
Sigurd Hellesvik

[Siddharth Kachhia]

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.

mcumgr -c acm image upload -n 3 build/zephyr/net_core_app_update.bin

[Simon]

Hello Siddharth, I will take a look at this today.

Best regards,

Simon

[ErDarshan]

Thanks Simon.

Let us know if you require anything else. We are also debugging from our side as we are blocked due to this issue.