Secure bootloader chain + two-stage upgradable bootloader MCUBOOT

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.

Hi Siddharth,

Could you explain what the result of your test ? 

You mentioned that "its not updating MCUBOOT!!" so what happened ? 

The MCUBoot can be used as first stage bootloader. But could you explain what your plan by having MCUBoot in both stages  ? 

Hi Hung,

I have added print line on this path : $NRF_CONNECT_SDK/bootloader/mcuboot/boot/zephyr/main.c.

So, after this changes I have pristine build the code in vs code and then after I have upload the signed_by_mcuboot_and_b0_s1_image_update.bin file then after confirm with hash key.

• you can see the below pic of mcumgr for upload cmd

• Below is confirm cmd pic, you can see after this cmd flag change is also changed to pending permanent.

• After this I have to reboot the board with reset switch and here is log of 1st reset, you can see

"swap type : perm" and that time it takes some time to doing swapping the image

• Reboot the Developement Kit again with reset switch, below is log of that. I had chenge FW: v2.0.0(when I Build signed_by_mcuboot_and_b0_s1_image_update.bin for new upgrading image) witch is not updated so means MCUBOOT is not updated. correct?

• Below is Image list cmd pic. you can see that active confirmed hash is same, so means that it is booting with same image.. not a new image

The MCUBoot can be used as first stage bootloader. But could you explain what your plan by having MCUBoot in both stages  ? 

mainly my purpose is to upgrade the bootloader

Hi Siddharth,

I will continue helping you in this case.

When you use MCUBoot to update the application, the application is is kept in the expected slot.
However, when updating MCUBoot, it is a two-step process:
1. Upload mcuboot image into slot.
2. Swap image from slot with previous mcuboot image.

I think this is to allow rolling back to the previous image if the update fails.

So you will not be able to list MCUBoot versions using mcumgr as you can for the application.

You will however get the hash from the previous image in said slot.

However, changes you made to MCUBoot (such as updating the print) should be active.

To test this, I add the following to $NRF_CONNECT_SDK/bootloader/mcuboot/boot/zephyr/main.c:

464     BOOT_LOG_INF("Starting bootloader");
465     BOOT_LOG_INF("Bootloader version: %d\n",CONFIG_FW_INFO_FIRMWARE_VERSION);

This way, it will automatically print my config from child_image/mcuboot/prj.conf

To be extra certain, I also added a log for AAAAA.
In this case, my log on serial output looks as following:

And since both the fw number and the print is updated, we can see that MCUBoot is updated.

Does this answer yout questions?

Regards,
Sigurd Hellesvik