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

[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