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

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.

[ErDarshan]

Hi Simon,

Do you find anything?

[Simon]

Hey, I didn't get too much time yesterday, but enough to catch up and start on the implementation. I will keep you updated as I progress.

[ErDarshan]

Thanks for the update. Let us know if you require any help from ourside.

[Siddharth Kachhia]

Hi Simon,

Have you completed the implementation?

[Simon]

Sorry for the delay.

Currently I'm able to do the following 

• 1. Update mcuboot through the application
• 2. Update the application through the application

It is not possible to do the following

• 3. Update the network core through the application (application on app core) while nRF Secure Immutable Bootloader (NSIB) is enabled

Without enabling NSIB, it is possible to update the network core through the application, but NSIB is needed in order to update mcuboot.

I think 3 is related to this https://devzone.nordicsemi.com/f/nordic-q-a/84786/nrf5340-nrf-secure-immutable-bootloader-and-network-core-bootloader. I will ask Amanda and the developers tomorrow what the current state is

Best regards,

Simon

[Siddharth Kachhia]

Hi Simon,

Thanks for the update. waiting for your response. 

[Simon]

I think I found a fix for being able to update the network core while NSIB is enabled. Apply this patch to bootloader/mcuboot (associated with NCS v1.9.0):

diff --git a/boot/bootutil/src/loader.c b/boot/bootutil/src/loader.c
index d5c370c4..7b2d823b 100644
--- a/boot/bootutil/src/loader.c
+++ b/boot/bootutil/src/loader.c
@@ -926,6 +926,7 @@ boot_validated_swap_type(struct boot_loader_state *state,
         vtable = (uint32_t *)(vtable_addr);
         reset_addr = vtable[1];
 #ifdef PM_S1_ADDRESS
+        if(reset_addr < PM_CPUNET_B0N_ADDRESS){ 
         const struct flash_area *primary_fa;
         int rc = flash_area_open(flash_area_id_from_multi_image_slot(
                     BOOT_CURR_IMG(state),
@@ -942,6 +943,7 @@ boot_validated_swap_type(struct boot_loader_state *state,
             */
             return BOOT_SWAP_TYPE_NONE;
         }
+        }
 #endif /* PM_S1_ADDRESS */
     }
 #endif /* PM_S1_ADDRESS || CONFIG_SOC_NRF5340_CPUAPP */

I will do some more testing and provide you with the complete sample and the patch.

Best regards,

Simon