nRF5340: SMP Server with external XIP sample with image revert possibility

[Ladivin]

Hi all,

by default, the "nRF5340: SMP Server with external XIP" sample does not support reverting images in case DFU was not successful. In other words, it does not swap slots, it just copies the new image over the old one. This is caused by the config CONFIG_BOOT_UPGRADE_ONLY being set to "y". 

I had no luck building the sample with CONFIG_BOOT_UPGRADE_ONLY=n. I had a look into C:\ncs\v2.6.1\nrf\modules\mcuboot\nrf5340_exip_image.conf and I can see that this config is set to "y" there. Also there is a note stating that this config is needed to make simultaneous multi image update possible. Does this mean that the only way to achieve multi image DFU for nrf5340 with part of code in QSPI flash is to have this config set to y? Or to make the question more generic - is there a way to have the posibility of reverting images after update in this multi image + QSPI XIP scenario? 

Thanks!

[AHaug]

Hi,

Does this mean that the only way to achieve multi image DFU for nrf5340 with part of code in QSPI flash is to have this config set to y

Yes, this is correct

Kind regards,
Andreas

 

[Ladivin]

Hi Andreas,

thank you for the quick answer! I have a follow up question.

I can see that this sample (nRF5340: SMP Server with external XIP) got some updates in the new version of the SDK (2.8.0). If I understand it correctly, if I wanted to update only two images (app + QSPI flash and NOT net core), I can use other modes, right? I can tell because the sysbuild_no_network_core_directxip.conf contains SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP=y. 

In other words, the requirement to have CONFIG_BOOT_UPGRADE_ONLY=y applies only if all of the three images are to be updatable? 

Thanks, 

Ladivin

[Ladivin]

Hi Andreas,

again many thanks for your response. 

Sorry for not being clear - by "other modes" I mean the choices that are defined in <NCS_PATH>\bootloader\mcuboot\boot\zephyr\Kconfig under choice BOOT_IMAGE_UPGRADE_MODE - e.g. the direct XIP mode that is newly available in the sample or swap using scratch etc. 

Thanks,

Ladivin 

[AHaug]

https://github.com/nrfconnect/sdk-mcuboot/blob/bcdf6e24493a0c3de7c5f3a126a6b4075b2ad088/boot/zephyr/Kconfig#L413-L423

Ah, I now understand what you mean. As far as I can see this should be possible, yes. But I've not verified by running and testing this myself, so I recommend you validate mixing the configurations/modes with updating the various cores/xip partition combinations thoroughly and if you find anything not working as you and I have discussed already let me know and we'll have a closer look if this is behaviour or should be a feature request

Kind regards,
Andreas

[Ladivin]

Thanks for your reply, I'll have a look into the various modes later one. 

Just a final question - so there's really no way of updating all three images with the revert posibility? Even if we e.g. do it one by one? I'm mean any way - even something really hacky? 

I'm sorry I'm asking pretty much the same thing from a different angle, but I need to be 100 % sure before I present this to my colleagues. 

Thanks,

Ladivin

[AHaug]

Hi,

No worries about the amount of questions. 

I did some more investigation and I have found the reason for why it is not possible for the netcore. In general we don't support reversion of the netcore image AFAIK, which is because of how DFU of the netcore is implemented. DFU of the netcore is handled through simulated RAM, and not in flash as with other parts of the image. This is a one-way transport, i.e after it is written to the netcore from SRAM, it can't be revertedl

From https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.html it is stated in a note that "The application core does not have direct access to the network core flash memory. The update image is passed indirectly using RAM. Because of this, the mcuboot_primary_1 must be stored in ram_flash region"

Let me know if this answers your question

Kind regards,
Andreas

[Ladivin]

Hi,

again, many thanks for your responses, and your patience :) I understand the limitation regarding the network core image. 

There is one more idea I have - would it be somehow possible to update all three images (app + net + qspi flash) and make app + qspi flash images reversible? Of course, net image would not be reversible, that's clear. 

Thanks,

Ladivin 

[AHaug]

Happy to help

Ladivin said:

There is one more idea I have - would it be somehow possible to update all three images (app + net + qspi flash) and make app + qspi flash images reversible?

Hmm, I will have to look closer into this, but my initial guess is that it might be possible. You might be aware of this, but I'm stating it anyways: One of the reasons for why we recommend simultaneous DFU of both the app and netcore at the same time is so that you don't break the interface (rpmsg / ipc or other) between them. 

Lets consider the case of nonsimultaneous of app and netcore (and put xip part on the sideline): If you do this you will first upload the app core image, reboot the device and swap to the new image. The next step is to upload the image to the netcore and repeat the same steps, but if you in the first step has broken the interface between the cores (for instance that the app core is no longer compatible with the previous interface), you can't use the netcore and BLE to upload the new image to the netcore. Let me know if you're still following or not and I'll clear up my explanation.

But as mentioned, I will look into this and verify if the combination you were asking about and get back to you after the weekend

Kind regards,
Andreas