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

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

AHaug — Thu, 16 Jan 2025 13:30:21 GMT

[quote user="Ladivin"]So if I understand it correctly, the SB_CONFIG_NETCORE_NONE=y is mandatory in this case? [/quote]

Correct

[quote user="Ladivin"]In other words, the only way to enable the revert option in a multi-image scenario for single nrf5340 is to update just two images (app + external) while also having an empty network core (meaning no BLE) at the same time?[/quote]

Yes, this resonates with my understanding of how direct-xip at least, and you will have to add the revert mechanism on top of the no_netcore_direct_xip configuration (explained here: https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/design.html).

Do also pay attention to the drawback mentioned there" Handling the primary and secondary slots as equals has its drawbacks. Since the images are not moved between the slots, the on-the-fly image encryption/decryption can’t be supported (it only applies to storing the image in an external flash on the device, the transport of encrypted image data is still feasible)." in case encryption and decryption is a concern for you.

Do note I'm fairly confident my understanding is correct, but I've not tested and developed anything with this specific configuration. I've only discussed it with my colleagues, read the documentation and investigated the samples you've also been working with

Kind regards,
Andreas

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

Ladivin — Thu, 16 Jan 2025 08:32:51 GMT

Hi Andreas,

Again, many thanks for your response.

So if I understand it correctly, the SB_CONFIG_NETCORE_NONE=y is mandatory in this case? In other words, the only way to enable the revert option in a multi-image scenario for single nrf5340 is to update just two images (app + external) while also having an empty network core (meaning no BLE) at the same time?

Best regards,

Ladivin

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

AHaug — Wed, 15 Jan 2025 14:48:24 GMT

Hi again Ladivin,

No worries, always good to discuss complex questions a bit closer to understand them better.

That's a good question. SB_CONFIG_NETCORE_NONE=y sets the netcore empty, as you say, meaning that you don't have anything on the network core. But if you want to an update of only 2 images (app and external flash) via BLE this indicates that you have something on the netcore i.e the hci_ipc companion component (previously known as child image), meaning that you conflict with SB_CONFIG_NETCORE_NONE=y.

My understanding of this config is that it's only for non-BLE configurations of the nRF5340, meaning that you won't be able to perform FOTA over BLE since the network core is empty. It might be useful if you have a multi-MCU board where another BLE compatible device receives the XIP_no_netcore__directxip image, sends it over serial to the nRF5340 which has an empty netcore over serial and then MCUboot on the 5340_no_netcore performs the update using that image.

Kind regards,
Andreas

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

Ladivin — Wed, 15 Jan 2025 08:53:05 GMT

Hi Andreas,

I apologize for revisiting our previous discussion, but I have one more question.

I understand our conclusion about the lack of revert options for the 3-image update on the nRF5340, and I won't dispute it.

I want to confirm something: since SDK version 2.8.0, the "nRF5340: SMP Server with external XIP" sample allows for "direct XIP" mode, which does enable revert options. In the configuration (like "sysbuild_no_network_core_directxip.conf"), the network core is empty. This indicates that a network core update isn't possible, but does it also mean the network core must be empty?

I'm asking, because I would like to know if it's possible to update only 2 images (the application and external flash) via BLE and still have the revert option.

Thank you very much in advance. This is a bit difficult to explain, so if more details are needed, just let me know 🙂

Best,

Ladivin

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

AHaug — Thu, 05 Dec 2024 08:33:01 GMT

[quote user="Ladivin"]so the final conclusion is that if one wants multi-image update, there's no way revert, correct?[/quote]

From my understanding, this is not supported for the nRF5340. This might be different for the nRF54L15 (which uses "regular" MCUboot DFU) and nRF54L20 (which uses SUIT).

Kind regards,
Andreas

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

Ladivin — Wed, 04 Dec 2024 16:02:02 GMT

Hello,

so the final conclusion is that if one wants multi-image update, there's no way revert, correct?

Many thanks for your help!

Best Regards,

Ladivin

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

AHaug — Wed, 04 Dec 2024 13:47:36 GMT

Hi,

I had discussion with the bootloader devs and the conclusion is that the combination you're asking for is not supported. It cannot be supported because of a dependency of MCUboot which is closer described here: https://github.com/mcu-tools/mcuboot/issues/1950

Kind regards,
Andreas

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

Ladivin — Wed, 04 Dec 2024 08:26:48 GMT

Hi Andreas,

again, many thanks for the explanation. I understand. If you had a chance to verify the combination we were discussing it would be great.

Best Regards,

Ladivin

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

AHaug — Fri, 22 Nov 2024 14:54:05 GMT

Happy to help

[quote user="Ladivin"]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? [/quote]

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

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

Ladivin — Fri, 22 Nov 2024 13:04:01 GMT

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

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

AHaug — Thu, 21 Nov 2024 14:38:38 GMT

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

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

Ladivin — Thu, 21 Nov 2024 09:28:31 GMT

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

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

AHaug — Wed, 20 Nov 2024 15:06:23 GMT

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

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

Ladivin — Tue, 19 Nov 2024 13:26:58 GMT

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

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

AHaug — Tue, 19 Nov 2024 13:10:42 GMT

Hi Ladivin,

Yes, based on the release notes it's true that this overlay (and support) has been added https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/releases/release-notes-2.8.0.html#samples

[quote user="Ladivin"]

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

[/quote]

Also correct. From the note you mention, reversion of netcore image is not supported in simultaneous update of multiple images:

"CONFIG_BOOT_UPGRADE_ONLY - The simultaneous update of multiple images does not support network core image reversion, so you need to disable application image reversion."

[quote user="Ladivin"]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? [/quote]

Could you expand on what you mean by "other modes"?

Kind regards;
Andreas

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

Ladivin — Mon, 18 Nov 2024 12:05:07 GMT

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

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

AHaug — Fri, 15 Nov 2024 14:13:11 GMT

Hi,

[quote user=""]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[/quote]

Yes, this is correct

Kind regards,
Andreas