Encrypted DFU NCS 2.5.0

RE: Encrypted DFU NCS 2.5.0

Sigurd Hellesvik — Tue, 27 Feb 2024 17:01:31 GMT

[quote user="Robert de Brum"]As I understand your response, it is safe to DFU the network core because BLE will still work - the protocol for communication between cores for BLE activity does not change.[/quote]

Yep.

[quote user="Robert de Brum"]In a ticket here, it is recommended that I do not use sysbuild yet as it is rather new still. Do you see this being a better route in the future to accomplish what I am trying? The child_image is working for me now as long as I can eventually DFU both cores.[/quote]

Sysbuild will be a more clean way to do custom child images.
However, as they say "if it works dont fix it". If it was me, I would stick to "multi-image builds" until NCS deprecates this system, or you need some feature only they provide.

[quote user="Robert de Brum"]It seems to me that the safest and most expedient option will be to DFU 2 separate images. As I continue to learn an understand this, I should be generating an application core first and running that DFU first. When this is in place, I can DFU a network image that will be placed in the correct slot at which point I will have the complete firmware. Does this sound correct in theory?[/quote]

Yep. I think you should be able to do that with a "normal" SMP Server example, and just upload net_core_app_update.bin to it and tag it as "confirm". Then the system should detect that this is a network core image, and swap it to the network core instead of the application core.
At least it did that last time I tried.

RE: Encrypted DFU NCS 2.5.0

Robert de Brum — Tue, 27 Feb 2024 09:04:47 GMT

Thanks for the detailed response I appreciate it.

[quote userid="106736" url="~/f/nordic-q-a/107500/encrypted-dfu-ncs-2-5-0/470641"]

The main reason for simultaneous DFU is to be able to update the interface between the net and app cores. If you update the network core first, and it can not talk with the app core any more, you can no longer receive the new app core image. Did that make sense?

[/quote]

The network core I plan to flash is based on the hci_rpmsg. I am not sure if it is mentioned here but it will maintain all of the same code as the hci_rpmsg sample, with the addition of some logic that will synchronize timers on both cores. As I understand your response, it is safe to DFU the network core because BLE will still work - the protocol for communication between cores for BLE activity does not change.

[quote userid="106736" url="~/f/nordic-q-a/107500/encrypted-dfu-ncs-2-5-0/470641"]

However, that sample is removed in v2.5.0. Instead, v2.5.0 has a multi-core sample using sysbuild.

[/quote]

In a ticket here, it is recommended that I do not use sysbuild yet as it is rather new still. Do you see this being a better route in the future to accomplish what I am trying? The child_image is working for me now as long as I can eventually DFU both cores.

It seems to me that the safest and most expedient option will be to DFU 2 separate images. As I continue to learn an understand this, I should be generating an application core first and running that DFU first. When this is in place, I can DFU a network image that will be placed in the correct slot at which point I will have the complete firmware. Does this sound correct in theory?

RE: Encrypted DFU NCS 2.5.0

Sigurd Hellesvik — Mon, 26 Feb 2024 09:03:13 GMT

Hi again Robert,

With the clarity of Monday morning I see that I answered your previous comments a bit too hastily. Likely I just saw your following quote on friday and thought "that is debugging, not questions":

[quote user="Robert de Brum"]I need to DFU both application and network core on my custom board with an nrf5340 and I am unable to.[/quote]

If you have specific errors that you want help looking into, the best approach is still to create a new ticket for that and we'll help you look into it.

However, you also asked general questions about DFU here, which do fit the theme of this ticket very much. And I will answer them now. Sorry for the inconvenience.

[quote user="Robert de Brum"] it is suggested to perform updates simultaneously so that the images get placed in the right order.[/quote]

[quote user="Robert de Brum"]Can you confirm if there is still a patch I need for multi-image DFU for SDK version 2.5.0?[/quote]

The patch is specifically if you run a custom network core image with the multi-image builds multi-core sample. If you want to use that method, you will still need a patch as far as I know. I discussed the topic in RE: nRF53 Custom b0n Build some time ago; I think the fix should be in there somewhere.
However, that sample is removed in v2.5.0. Instead, v2.5.0 has a multi-core sample using sysbuild.

[quote user="Robert de Brum"] Can you also comment on any known shortcomings of Multi-image DFU?[/quote]

The one that comes to mind is that if you do simultaneous DFU, you can not use the revert functionality of MCUboot. From Simultaneous multi-image DFU:
" The simultaneous update of multiple images does not support network core image reversion, so you need to disable application image reversion."

Other than that, you could argue that "increased complexity" is a shortcoming.

[quote user="Robert de Brum"]Any help on this is great. The situation that I am in is that I have devices in the field running code on version v2.3.0 with custom cpu_net code and no multi-image DFU. I want to know that I can DFU them in a particular order such that application and network image get updated.[/quote]

The only reason to do simultaneous multi-image DFU for the nRF5340 is that you want the ability to update the communication interface between the cores.

As long as you do not change this, you should be fine with not doing simultaneous multi-image DFU.

[quote user="Robert de Brum"]I am also finding that to DFU both cores simultaneously I need to use external flash - on the DK it is using the mx264f?[/quote]

It is technically possible to do this using only internal flash. However, since you need to DFU for both cores at the same time, you need an extra secondary slot to keep the network core image in, taking up even more flash space.
So you might face some flash space problems.

Setting external flash would automatically fix some stuff needed for simultaneous multi image DFU. There is a couple of PRs to fix this, but they are not merged yet.
https://github.com/nrfconnect/sdk-nrf/pull/10060
https://github.com/nrfconnect/sdk-mcuboot/pull/235

[quote user="Robert de Brum"]urthermore, for simultaneous DFU, I am not seeing the net_core_update.bin files generated at all. I have tried the unofficial DFU samples with no success on our custom board, nor the DK. How can I ensure that the network core update binaries are generated, and that the firmware will accept them OTA?[/quote]

You should have those files generated.
But this is on "I have build errors" and not "systemic questions", we could take that in a new ticket if you need debug help.

RE: Encrypted DFU NCS 2.5.0

Sigurd Hellesvik — Thu, 22 Feb 2024 09:19:33 GMT

Hi Robert,

Your new queries are a bit aside from the original topic in this ticket.

To help us keep DevZone tidy, could you create a new ticket for these, and link to this ticket in the new one?
If you still need to use encryption with the multi-core DFU, make sure to mention that specifically

RE: Encrypted DFU NCS 2.5.0

Robert de Brum — Wed, 21 Feb 2024 19:59:03 GMT

I am also finding that to DFU both cores simultaneously I need to use external flash - on the DK it is using the mx264f? This is not possible for us because our custom hardware does not use that flash chip. Furthermore, for simultaneous DFU, I am not seeing the net_core_update.bin files generated at all. I have tried the unofficial DFU samples with no success on our custom board, nor the DK. How can I ensure that the network core update binaries are generated, and that the firmware will accept them OTA?

RE: Encrypted DFU NCS 2.5.0

Robert de Brum — Wed, 21 Feb 2024 16:42:50 GMT

Hello again,

I need to DFU both application and network core on my custom board with an nrf5340 and I am unable to. It does not need to be a simultaneous but I read on this ticket that it is suggested to perform updates simultaneously so that the images get placed in the right order.

Can you confirm if there is still a patch I need for multi-image DFU for SDK version 2.5.0? Can you also comment on any known shortcomings of Multi-image DFU? I know one already that you mentioned will affect me - having a custom cpu_net application messes with the build order so it will not generate a net_core_update.bin. I have gone around this by injecting my code into the hci_rpmsg sample and enabling CONFIG_NCS_INCLUDE_RPMSG_CHILD_IMAGE.

Any help on this is great. The situation that I am in is that I have devices in the field running code on version v2.3.0 with custom cpu_net code and no multi-image DFU. I want to know that I can DFU them in a particular order such that application and network image get updated.

RE: Encrypted DFU NCS 2.5.0

Sigurd Hellesvik — Fri, 19 Jan 2024 08:31:09 GMT

Yes and no.

If we are thinking of the same limitation, the old custom network core sample had some build order issues when mcuboot was built at the same time.
There are several workarounds to that I think. First, there was a workaround patch you could apply to fix it I think. Or you could edit the hci_rpmsg(or other) sample in the NCS directly to add your custom features. Not the cleanest of workarounds, but still they work.

However, in newer versions of the nRF Connect SDK, we have a new multicore sample for adding custom network core images, using "Sysbuild" instead of the old "Multi-image build" method.
I have not tried to do this with MCUboot yet, but I have not heard about any issues either, so that is a good sign.
I should mention that Sysbuild does not yet have automatically generated files for DFU such as app_update.bin, so you would have to manually sign images with imgtool.py.

RE: Encrypted DFU NCS 2.5.0

Robert de Brum — Thu, 18 Jan 2024 17:46:31 GMT

I appreciate this answer, though I feared this would be so. I will have to use the sample you provided and see if I can leverage that in my projects.

On a separate note but similar, I also have a need for multi-image FOTA. There is a running sample for this for the nrf5340 that I remember, but I remember that the limitations of this was that the multi-image DFU is not supportive of projects with custom network core code.

Are there any updates on this?

RE: Encrypted DFU NCS 2.5.0

Sigurd Hellesvik — Thu, 18 Jan 2024 08:43:53 GMT

[quote user=""]I am now running ncs v2.5.0 and I am curious if encrypted DFU is released yet or not.[/quote]

Not officially supported yet, no.

[quote user=""]If not, have there been any successful custom examples[/quote]

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/keys_and_signatures/mcuboot_smp_encryption

[quote user=""]are there plans to officially support?[/quote]

I generally can not comment on timeline questions. Contact sales for that. That has the added benefit that sales gets a better overview over demand for features.

Regards,
Sigurd Hellesvik