nrf5340 custom board non-simultaneous updates without external flash with sysbuild on ncs2.7.0+

[AlejandroM]

Hello!

I was wondering if there is any advice from trying to get Non-simultaneous firmware updates using sysbuild with the following constraints:

• Must update both App Core and Netcore
• Non-Simultaneous preferably
• Without External flash
• Custom board
• Custom Netcore (DTM/In-house Manufacturing)
• Using sysbuild (because we were advised to move to 2.8.0 and sysbuild is now a must)
• Using SMP

During our development we got this working on ncs 2.6.X, and we can do all the above without sysbuild, we wrote our own SMP transport and we can do the updates, and we've seen that there is still ongoing DFU development for sysbuild in ncs2.7.0+ and we are wondering if there are any updates on this? 
Most of the samples we've seen cover the simultaneous and with external flash, but not the non-simultaneous without external flash, we could potentially do simultaneous, but the external flash is not something we can add at this point.

To clarify we want this to be able to go from our DTM/Manufacturing image to the Customer/production image (both with different App/Net Core images) using our SMP Transport.


Moreover, we can do sysbuild updates for AppCore, but for our custom DTM/Manufacturing we can't get it to enable NetCore updates, once we enable SB_CONFIG_NETCORE_APP_UPDATE we get:

with this configuration
0020.sysbuild.conf

And this Kconfig.sysbuild (had to add txt so I was able to upload it here):

Fullscreen Kconfig.sysbuild.txt Download

menu "Network core configuration"
    depends on SUPPORT_NETCORE

config SUPPORT_NETCORE_DIRECT_TEST_MODE
    bool
    default y

choice NETCORE
    prompt "Netcore image"
    depends on SUPPORT_NETCORE && !EXTERNAL_CONFIGURED_NETCORE

config NETCORE_DIRECT_TEST_MODE
    bool "direct test mode"
    help
      Use manufacturing dtm image as the network core image.

endchoice

# if !NETCORE_NONE

config NETCORE_IMAGE_NAME
    default "direct_test_mode" if NETCORE_DIRECT_TEST_MODE

config NETCORE_IMAGE_PATH
    default "../../../" if NETCORE_DIRECT_TEST_MODE

# endif # !NETCORE_NONE

endmenu

source "${ZEPHYR_BASE}/share/sysbuild/Kconfig"

Any advise, ideas would be appreciated!

[AlejandroM]

Hi Andreas ( AHaug ):

AHaug said:

Aha, yes please do that. The short reason for why you would want static partitioning is so you can migrate to newer versions further up with the same partitioning map. Dynamic partitioning may change between versions, meaning that you may get issues with addresses due to for instance changes in how large a partition is between the two different versions.

This is great tip, didn't know that! (dynamic vs static partitioning). I ended up going static, and that worked out! :D I appreciate the help!

AHaug said:

You must also make sure that you sign your new application with keys which that your old bootloader recognizes so that the new image will be approved.

Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?

AHaug said:

In short, migrating through an update is quite more complex than simply migrating, but it is possible as long as you have enough headspace on the previous memory map (given that you will add features), and/or have static partitioning as well as you're using the same keys.

Great to know! Thanks a lot again Andreas!

Cheers,

[AHaug]

AlejandroM said:

This is great tip, didn't know that! (dynamic vs static partitioning). I ended up going static, and that worked out! :D I appreciate the help!

Great! Glad to hear that!

Another FYI that you might not be aware of: If you need to change the static partitioning map later, you will need to update MCUboot i.e add a complete bootloader chain. This is also something that you can't do retroactively due to the device is already running an older version of MCUboot that only knows about it's old partitioning map, and retroactivly adding a bootloader chain with NSIB will both demand a change in start address for MCUboot and for your application. MCUboot will now become a second stage updatable bootloader and NSIB will become the first stage bootloader

AlejandroM said:

Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?

That might be the case. I'm not 100% sure if the default key that we use in NCS (which we of course want users to change to their own custom keys in their products) has changed between the releases, but it might be the case.

AlejandroM said:

Great to know! Thanks a lot again Andreas!

Happy to help! 

Let me know when you feel we've resolved the topic of this case and we'll mark it of as verified answer! :) Until then we'll keep the case open if you have any follow ups related to this topic

Kind regards,
Andreas

[AlejandroM]

Hello AHaug 

Update:
After migrating to 2.7 I was able to get it all working fine by defining a `pm_static.yml` partition layout file with only `mcuboot_primary`, `mcuboot_secondary` and `mcuboot_primary_1` ( no `mcuboot_secondary_1`). However, on 2.9 the existence of `mcuboot_secondary_1` seems mandatory and that makes mcumgr think that it needs to be there for many simple commands:


And well minding the new slot configuration, for the most part works, uploading to the old slot ( slot 3 ) makes the system crash:



Question is:

Is there a way to define `mcuboot_secondary_1` partition so that we don't get this ?

reminder: We don't have external flash in our system as most of the samples use that partition

[AHaug]

Hi again,

Hmm, yes it does indeed look like this is a mandatory partition to temporary store the netcore update image within. I'm not sure how this translates to non-simultaneous DFU though, but for simultaneous DFU it is atleast required. It seems to be the case that it is required for both types as mcuboot_secondary_1 is used to temporarily store the netcore image for image revertion in the solution we provide.

I think the best option here is for you to customize the bootloader so that you get a solution where you can upload the netcore update image to mcuboot_secondary application slot, and then transport it to netcore when it detects that it is doing a netcore update.

Non-simultaneous DFU of the 5340 is technically possible, but we favour the simultaneous DFU procedure both due to robustness and that the solution is simpler. 

AlejandroM said:

d we are not considering FOTA updates, as the ble module is part of another system (not standalone)

Another item of discussion is this. If you're not considering FOTA updates, then you might not need any secondary partitions at all. Are the requirements such that you need image reversion, or is serial recovery an option instead? 

Kind regards,
Andras

[AlejandroM]

Hi AHaug !

AHaug said:

I think the best option here is for you to customize the bootloader so that you get a solution where you can upload the netcore update image to mcuboot_secondary application slot, and then transport it to netcore when it detects that it is doing a netcore update.

You mean customize the code for mcuboot ( and/or potentially b0n ) ?
I was basing myself on this scenario from the courses:


But yeah looking it more closely I do not see the `mcuboot_primary_1` nor `mcuboot_secondary_1` there, I guess I can try to remove those and see If I can still do the non-simultaneous update.

AHaug said:

Non-simultaneous DFU of the 5340 is technically possible, but we favour the simultaneous DFU procedure both due to robustness and that the solution is simpler. 

That makes sense now, but since our application is still bigger than the ram space we have ( 300 KiB App + 230 KiB Net ), not sure we would be able to fit both for simultaneous, unless the compression feature can help with that ( SB_CONFIG_MCUBOOT_COMPRESSED_IMAGE_SUPPORT`), can it?

AHaug said:

Another item of discussion is this. If you're not considering FOTA updates, then you might not need any secondary partitions at all. Are the requirements such that you need image reversion, or is serial recovery an option instead? 

We wanted originally to have serial recovery available, but we have not tested it outside the old samples ( 2.6.x ), could we potentially have serial recovery and non-simultaneous updates with this double partitioning layout (primary and primary_1 )?

Thanks,