NCS 2.2 custom net child image

[Hiihtaja]

Hello !

I have used multicore sample as base and add to it own network image and b0n bootloader ( as child to network image).

And net_core_app_update.bin is not build.

Looks like it is known issue and might be fixed in ncs 2.2 release or some patch is available some where.

Similar problems : 

 NCS 2.0 custom child image + mcuboot build

 NCS 2.1.0 custom child image + mcuboot build 

 NRF5340 multicore image dfu package not have net core binary 

Could it be possible to have some workaround about it ?

In our case we have custom radio image and muiltiimage type of build is expected as natural environment where app and network corea image + 2 bootloaders are build in one shot.

Regards,

Eugene

[Hieu]

Hi Eugene,

The multicore sample has a build order problem.

Normally, the regular netcore is built first, and then during bootloader build, the update bin files are generated.

However, in the multicore sample, after bootloader is added, bootloader is built first, and thus results in problem where the update bin files for the network core are not generated.

Could you please try to apply this commit to your SDK and see if it fixes the issue?

dump · hakonfam/fw-nrfconnect-zephyr@970c432 (github.com)

Regards,

Hieu

[Hiihtaja]

Hi Hieu !

1.

Thank you !

I think this patch is work for me as well and whole set of images are generated.

In latest SDK, line numbers have different numbers.

Can chaining of child images done in other way for avoid this patch ? OR patch will be published soon ?

2,

But after that I have moved to other step to validate if binaries is correct and can be used for actual update.

I have modified conf & sources a bit for have USB serial connectivity with bootloader and different main.c files for build actual firmware updates. Direct Serial flash recover DFU method is configured for both APP and NET images.

With serial recovery app and core images should be updated directly without any intermediate slots in internal or external memory. May be some shared SRAM is used for transfer image from MCUBoot to b0n boot-loader.

Configuration lines are collected from different SDK and Devzone samples and maybe redundant/wrong sometimes.

I'm able to update app core by using line: 

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin

and image is updated directly and can boot again

But composite update:

$ mcumgr -c acm2 image upload -e build/zephyr/dfu_application.zip

destroy everything and no valid image any more

I: Starting bootloader

I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3

I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3

I: Boot source: none

W: Failed reading image headers; Image=0

E: Image in the primary slot is not valid!

E: Unable to find bootable image

Unfortunately , no traces from b0n bootloader, I'm not sure if I enable those in correct way.

Netcore update

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin

Looks like overwrite application core flash space.

So I need some correct test application for verify network/composite image update ( I will move to signed images as well). In our case app and core images expected to be huge and keep second copy in internal flash memory is not possible. Better to avoid usage external flash memory as well. Load and update will take long time.

Board will be connected to some host and we have enough space for keep app/network update binaries.

This is why direct serial recovery method is preferable method for DFU.

Regards,

Eugene

multicore_dfu.zip 

 

[Hiihtaja]

Hi Hieu !

No problem to wait.

But how I can track progress of update of netcore image after transfering ?

Or I need just  to wait and after that initiate HW reset ?

What kind of partition enumeration in case of CONFIG_SINGLE_APPLICATION_SLOT=y ?

1 and 2 ?

Regards,

Eugene

[Hieu]

Hi Eugene,

Hiihtaja said:

But how I can track progress of update of netcore image after transfering ?

Or I need just  to wait and after that initiate HW reset ?

Unfortunately, there is no tracking interface at the moment, you will have to wait and then trigger reset.

On the other hand, I was informed that in future version, they intend to shift the transfer to happen after reset, not before.

Hiihtaja said:

What kind of partition enumeration in case of CONFIG_SINGLE_APPLICATION_SLOT=y ?

1 and 2 ?

CONFIG_SINGLE_APPLICATION_SLOT doesn't work with multi-image build at the moment. Did you get it to work somehow?

Best regards,

Hieu

[Hiihtaja]

Hi Hieu !

I think it is more logically to execute entire FW update while MCUBoot is up and running.

We have Host what can upload images if need several time and even calculate CRC after update if need.

I think in case of serial recovery of network core, actual network flash can be updated by some portions on fly. When mcumgr exit, flash memory can be updated already and relevant status is returned.

 

CONFIG_SINGLE_APPLICATION_SLOT=y  is not work for me. I have created other request about it.

Regards,

Eugene

[Hieu]

Hi Eugene,

Hiihtaja said:

I think it is more logically to execute entire FW update while MCUBoot is up and running.

In the future direction I previously mentioned, the moving of the net core image would not happen during the MCUboot serial recovery session, but it would still happen during bootloader time of the next reset. Do you find this logical?

If you think differently, could you please share your reasons in more details, and I can certainly bring it to our developers' attention.

Hiihtaja said:

I think in case of serial recovery of network core, actual network flash can be updated by some portions on fly. When mcumgr exit, flash memory can be updated already and relevant status is returned.

The serial recovery session is run in application core, which does not have access to network core flash, and thus cannot write it directly. I would think that segmenting the image so that PCD trigger or segment at a time would work, but at the same time, that probably add synchronization to the complexity. It would also introduce the risk of only at the end finding out that the image is bad/malicious. Do you think so?

Hiihtaja said:

CONFIG_SINGLE_APPLICATION_SLOT=y  is not work for me. I have created other request about it.

I checked and it turns out that it is thanks to that request of yours that I indirectly learned CONFIG_SINGLE_APPLICATION_SLOT doesn't work for multi-image setups. I trust that my colleague Einar will keep you updated on when the configuration would be supported.

Best regards,

Hieu

[Hiihtaja]

Hi Hieu !

I think image can only boot if signature is valid. 

As result any binary what fit to current partition shouldn't cause any malicious behaviour. 

But of course doesn't have sense to flash any non verified image.

As usually first block of image ( 4KB for example ) is kept in SRAM but other part flashed to memory directly and signature is verified at the end. If it OK, first block is written to own place. If not - even other part can be erased.

Fast serial flashing have sense specially in case when Host can control firmware versions and possible to initiate update from Host at any moment.

Regards,

Eugene

[Hieu]

Hi Eugene,

If I understand correctly, you are suggesting a different method altogether, where the image is written directly to network core flash?

Unfortunately, network core flash cannot be accessed by the application core. Meanwhile, the serial recovery session is hosted on the application core.

Best regards,

Hieu

[Hiihtaja]

Hi Hieu !

Almost directly. You have IPC mechanism and and can receive block of data and write it.

Or this is not possible ?

Main target is to reduce update time, able to track progress and get status of update when mcumgr finish data upload.

Regards,

Eugene

[Hieu]

Hi Eugene,

I understand your idea now. Thank you for the suggestion, and I will relay it to our internal team.

I will let you know if they have any feedback.

Best regards,

Hieu