Multi image configuration with mcuboot doubt

[pau_vilanova]

Hi! I'm working with nRF52833 in a laird dev kit and I'm having problems understanding the multi-image build configuration on nrf Connect SDK with zephyr.

Our project concept is the following:

Having mcuboot on top, and 2 more bootable images.

The first image is the one with the hability to write to the slot 1 of both images.

The second image is the client application.

And I'm having problems on undestranding the project configuration and how child image works.

I'm having doubts in 2 different aspects, which are about project configuration and image management.

In order to understand the first one I'm working with the hello world sample with mcuboot enabled and trying to add an additional image to the project. Doing this I have the following doubts:

- Whats the correct syntax in the dts in order to specify my concept?

    As stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-zephyr.html#building-and-using-mcuboot-with-zephyr  the first updateable image will go as image_0_primary_partition and image_0_secondary_partition and the second as image_1_primary_partition and image_1_secondary_partition. But when I go to the board dts I find the following corresponding to the hello world first image:

That label confuses me.

- Do I need to modify the flash-map stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#flash-map for multi-image? If so, where is it located in my project?

-Is hello world + mcuboot a multi image build? If so, is mcuboot build in the project as a child? Why I don't find in cmakelists.txt mcuboot child enable and definition as stated in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html#defining-and-enabling-a-child-image ?

And about the second aspect, image management:

-The smp server example writes the image received in the slot 1 of the current image, is it possible to make it modify the slot 1 of other images? If not, what's the correct approach to my flash structure proposal?

Is there any example or documentation that clarifies what I'm trying to do?

Thanks!

[Simon]

I looked into this, and it seems like you don't need to do any modifications to the mcumgr libraries.

If you issue an image upload command, img_mgmt_upload() will run and set .image to 0 and next img_mgmt_impl_upload_inspect()-->img_mgmt_get_unused_slot_area_id() will run and since image was set to 0, it will run zephyr_img_mgmt_flash_area_id(1), which run FLASH_AREA_ID(image_1), which will make it use mcuboot_secondary (DFU APP slot 1).

To make it use mcuboot_secondary_1 (Client APP slot 1, which I defined in the pm_static.yml file), you need to make it select image_3, and for that you'll have to run zephyr_img_mgmt_flash_area_id(3) and for that to happen, you need to set image to 1 in img_mgmt_upload().

One way of going about this, is to use the -n flag, to set the image to 1 when running the mcumgr image upload command, see mcumgr-->image management: 

Then I think cbor_read_object() will override the old image value and set it to 1, and the new image will be stored in mcuboot_secondary_1.

I have not gotten time to test this, but I'll try it out in the next days.

[Simon]

 5226.multi_img_dfu_833_v2.zip

I did some testing, and I was able to perfomr multi image DFU using the sample above and an nRF52840DK (don't have an nRF52833 DK at the moment). I enabled serial dfu support following Modify the Hello World sample and performed a DFU following Testing. The only difference I did was to append "-n 1" when running the upload command:

mcumgr --conntype serial --connstring "COM5,baud=115200" image upload -n 1 -e app_update.bin

I then confirmed using the Programmer app that the new uploaded images was successfully put into mcuboot_secondary_1 (Clien APP slot 1). 

The next step now is to be able to swap the image in mcuboot_secondary_1 into 

mcuboot_primary_1 using mcuboot.

[Simon]

Hello, have you gotten any progress? I've not been able to get it fully working yet, but I'll share my temporary progress.

I still have some problems withmcuboot not being able to validate mcuboot_primary_1 (getting  W: Failed reading image headers; Image=1
E: Unable to find bootable image). I tried to add a custom sample and add it as as a child image (placed into mcuboot_primary) to the mutli_image_dfu sample, but it is not able to validate it.

Here is the multi_img_dfu sample (only tested on nRF52840 DK):

multi_img_dfu_v3.zip

Here is a diff of the nrf, after modifying it to support a custom child image:

https://github.com/nrfconnect/sdk-nrf/compare/nrfconnect:cfedfdf...simon-iversen:fcfc6ef

Best regards,

Simon

[pau_vilanova]

Hi Simon,

Sorry for the lateness, my work had been shifted, and I couldn't spend time on that.

What I discovered so far:

Mcuboot is meant to boot always a fix location, so I realized that having mcuboot to boot image 1 or 2 is not viable. A DFU in different slots could be possible but again, it requires modifying mcuboot source code in order to modify the fixed image offset.

I discovered that mcuboot has dfu capabilities too, so instead of having another image to do the dfu process apart from the client image, I'm trying to make the mcuboot update directly to the client image. In doing so, the dfu functionality is not inside the client application, and that was what I was looking for.

But in this process I have some doubts.

I have the following mcuboot configuration:

That enables me to upload a client image successfully:

But, mcuboot is not writing the image to slot 1 like the smp server example, instead is writing it directly to slot 0 and overwriting the application.

In doing so, I cannot test it, and mcuboot is not swapping, just writing new image and booting it. Am I doing something wrong?

Is mcumgr the commands that I need to use to upload new images in mcuboot serial configuration?

mcuboot serial only contemplates usb and uart, is it possible to make it work with ble?

Is mcuboot really working with mcumgr when I enable mcuboot_serial?

The only "documentation" that I found is in its Kconfig file https://github.com/nrfconnect/sdk-mcuboot/blob/v1.7.99-ncs-branch/boot/zephyr/Kconfig

[pau_vilanova]

Could the problems you're facing be related to the -n option of mcumgr?

the documentation says that -n option is only supported when working inside mcuboot with dfu serial.

https://docs.zephyrproject.org/latest/guides/device_mgmt/mcumgr.html