Updatable bootlaoder (over BLE SMP)

[george232]

Hi,

I have added a support for application DFU over BLE SMP to our project (with mcumgr). It work with no problem. Now what I want to achieve is an updatable MCUBoot with the same transport layer. We already have a NSIB and proper static memory map configuration (configured with Partition Manager's pm_static.yml - we have mcuboot_secondary slot set in the external flash and B0 slots in internal flash). I have looked through code and it seems to me like the zephyr_img_mgmt implementation natively supports only application image updates with mcuboot backend. Is there any out of the box solution for updating the mcuboot itself? Is mcumgr flexible enough to upload the image to the partition/address other than mcuboot_secondary - in particular to the S1 slot of the B0 bootloader configured in the internal flash memory?

I have tried the solution proposed here but with the BLE SMP transport instead of UART:Update mcuboot with SMP
But it doesn't seem to work as the uploaded image lands in the mcuboot's external flash partition (verified with debbuger that the flash device being opened is the mx25r64).

I'd presume that the binary to be uploaded with mcumgr must have encoded all information needed to upload it to the proper memory address (judged by CBOR decoding implemented here: https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c#L508). Does the `signed_by_mcuboot_and_b0_s1_image_update` file meet this criteria? If so, I guess it should be feasible to adapt the mcumgr to handle my case. I'd really appreciate any kind of guide or list of steps required to achieve that.

Also, I saw the CONFIG_MCUMGR_GRP_IMG_DIRECT_UPLOAD, which sounds like something which might help, but I cannot really understand what it does from the KConfig description. I'd warmly welcome any explanation here.

Thanks in advance,

G

[Hung Bui]

Hi Jerzy, 
Sigurd is away so I will try to answer in the mean time. 

I'm not so sure why it stuck at pending, but I think it's you would need to avoid.

 My understanding is that after you have copied the image to either s0 or s1 slot the immutable bootloader will not swap them to the correct slot and simply run the 2nd stage bootloader (the mcuboot ) from the slot. I'm not aware of the feature on B0 that it can swap image. The discussion you have with Sigurd was about MCUBoot choosing which partition it should copy the image , not about B0 right ? 
So if you have copied/DFUed the image signed_by_mcuboot_and_b0_s0_image_update.bin to the wrong slot (in this case slot1) B0 will try to run the MCUBoot from the wrong slot.

It's most likely that MCBoot will not be able to run from the wrong slot as it's compiled for slot 0. 

[george232]

Hi Hung,

the problem is not about swapping image by B0, which anyway is not supported I guess. We we agreed with Sigurd, the workflow is as follows:

- upload the image with the new mcuboot version to the mcuboot_secondary slot via SMP transport

- reboot the device, the mcuboot swaps the image from mcuboot_secondary to the NSIB slot - weather it's S0 or S1 is encoded in the binary image (signed_by_mcuboot_and_b0_s0_image_update.bin targets S0 and signed_by_mcuboot_and_b0_s1_image_update.bin targets S1)

- reboot the device one more time - this time, nothing is swapped, the B0 simply runs the mcuboot image from S0 or S1 by selecting the image with higher CONFIG_FW_INFO_FIRMWARE_VERSION

At which point do you think, the image is copied to the wrong slot and how would the B0 attempt to run the image from the wrong slot? As explained, the B0 simply runs the image with the higher version, right?

I think the reason why we need to use S0/S1 alternately is quite obvious -> we cannot use mcuboot to swap the image from mcuboot_secondary to the same slot the current mcuboot is being run from (the running image cannot swap itself) -> please confirm.

So the conclusion is that we have to use signed_by_mcuboot_and_b0_s0_image_update.bin signed_by_mcuboot_and_b0_s1_image_update.bin alternately. That's reasonable, fine. But from what I observe it looks like we can brick the DFU when we mistakenly upload the S1 (or S0) image twice in a row and tag this image as pending. In this scenario we cannot upload subsequent images anymore because the image in the mcuboot_secondary is "pending" (as I said there is a logic in the img_manager which implements such a behavior). So the question is, how to fix it? Can we somehow force the mcumgr to un-tag the image (set it to non-active) to unblock further mcuboot image uploads?

Regards,

G

[Hung Bui]

Hi Jerzy,

george232 said:

we cannot use mcuboot to swap the image from mcuboot_secondary to the same slot the current mcuboot is being run from (the running image cannot swap itself) -> please confirm.

Correct. MCUBoot can't replace itself. 

george232 said:

Can we somehow force the mcumgr to un-tag the image (set it to non-active) to unblock further mcuboot image uploads?

I'm checking internally to see if there is any solution for this. Seems like extremely care need to be taken when updating MCUBoot, especially when checking which slot the active MCUBoot is running on.