Multiple issues with mcuboot + serial recovery

[bdodge09]

In the process of adapting mcuboot serial recovery mechanism to enable upgrade of a coprocessor from a main CPU (both 52840s or 5340s) I ran in to a number of issues that should be addressed.

1) BIG Issue: Building a single-slot application with mcuboot (CONFIG_SINGLE_APPLICATION_SLOT=y in mcuboot.conf)  for the 5340dk doesn't build properly.  See error:

FAILED: zephyr/net_core_app_signed.hex /Users/bdodge/Mead/zigbeecpu/build_5340/zephyr/net_core_app_signed.hex
cd /Users/bdodge/Mead/zigbeecpu/build_5340/modules/mcuboot && /opt/homebrew/opt/[email protected]/bin/python3.9 /Users/bdodge/ncs/bootloader/mcuboot/scripts/imgtool.py sign --key /Users/bdodge/Mead/zigbeecpu/child_image/mcuboot/levelboot.pem --header-size 0x200 --align 4 --version 1.0.1+2 --pad-header --slot-size  /Users/bdodge/Mead/zigbeecpu/build_5340/multiprotocol_rpmsg/zephyr/signed_by_b0_app.hex /Users/bdodge/Mead/zigbeecpu/build_5340/zephyr/net_core_app_signed.hex
Usage: imgtool.py sign [OPTIONS] INFILE OUTFILE
Try 'imgtool.py sign -h' for help.

Error: Invalid value for '-S' / '--slot-size': /Users/bdodge/Mead/zigbeecpu/build_5340/multiprotocol_rpmsg/zephyr/signed_by_b0_app.hex is not a valid integer. Please use code literals prefixed with 0b/0B, 0o/0O, or 0x/0X as necessary.
[273/285] Generating ../../zephyr/net_core_app_update.bin

2) MEDIUM Issue: There is no support for non-console UARTs in mcuboot serial recovery.  serial_adapter.c uses only chosen "zephyr-console" to get the UART device for upload.  It should be something like alias recovery-uart or mcuboot-recovery-uart and if that's not OK in dts then use zephyr-console.  Isn't this the whole point of using device trees?  Also, the error disallowing serial boot and console together is wrong if the uart isn't zephyr-console.

3) MINOR Issue: The mcuboot build doesn't use the device tree from the app build when built as a child image.  This is a bit surprising.  I can't image someone wanting to build mcuboot and their application for their platform using the default device tree just for the boot-loader  portion.  Wouldn't it make more sense to use the application's device tree by default?  You can work around this by forcing the proper device tree for the mcuboot build stage but still it seems wrong to have to do that.

4) MINOR Issue: The mcuboot serial protocol (base64 encoded data CBOR encoded fimrware + headers + SMP encoding with added cmd->rsp makes data transfer about 1000 times slower than it could be.  The SMP wrapper says it specifies a 127 byte maximum packet.  That leaves only 32 bytes of firmware per message (to stay aligned to flash buffers)  The mcuboot code however can take up to 512 bytes which works, so either the comments about SMP should be updated or the code changed.  A configurable buffer size might be nice here.  boot-loader has almost all of RAM to use during a recovery right?

[Sigurd Hellesvik]

Hi Brian,

1) BIG Issue: Building a single-slot application with mcuboot (CONFIG_SINGLE_APPLICATION_SLOT=y in mcuboot.conf)  for the 5340dk doesn't build properly.  See error:

I am able to reproduce this.
I will check with our developers if we have support for single slot serial recovery of the nRF5340.

2) MEDIUM Issue: There is no support for non-console UARTs in mcuboot serial recovery.  serial_adapter.c uses only chosen "zephyr-console" to get the UART device for upload.  It should be something like alias recovery-uart or mcuboot-recovery-uart and if that's not OK in dts then use zephyr-console.  Isn't this the whole point of using device trees?  Also, the error disallowing serial boot and console together is wrong if the uart isn't zephyr-console.

I have not seen this one before, so I will have to look into it.

3) MINOR Issue: The mcuboot build doesn't use the device tree from the app build when built as a child image.  This is a bit surprising.  I can't image someone wanting to build mcuboot and their application for their platform using the default device tree just for the boot-loader  portion.  Wouldn't it make more sense to use the application's device tree by default?  You can work around this by forcing the proper device tree for the mcuboot build stage but still it seems wrong to have to do that.

You must set devicetree for child images as well. See ZigBee light switch sample for the folder structure for this.

It is a bit weird since:

• Overlay: child_image/mcuboot.conf
• Overwrite: child_image/mcuboot/prj.conf
• Overlay: child_image/mcuboot/boards/<board_name>.overlay
• Dont know which: child_image/mcuboot/boards/<board_name>.conf

The "base" prj.conf is mcuboot/boot/zephyr/prj.conf. Overlays add to this, while overwrites will replace all of it as far as I know.

4) MINOR Issue: The mcuboot serial protocol (base64 encoded data CBOR encoded fimrware + headers + SMP encoding with added cmd->rsp makes data transfer about 1000 times slower than it could be.  The SMP wrapper says it specifies a 127 byte maximum packet.  That leaves only 32 bytes of firmware per message (to stay aligned to flash buffers)  The mcuboot code however can take up to 512 bytes which works, so either the comments about SMP should be updated or the code changed.  A configurable buffer size might be nice here.  boot-loader has almost all of RAM to use during a recovery right?

Have a look at  How to increase packet size in DFU on IOS

and MCUBOOT slow with nRF52840 / Zephyr / USB CDC_ACM protocol

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

2) MEDIUM Issue: There is no support for non-console UARTs in mcuboot serial recovery.  serial_adapter.c uses only chosen "zephyr-console" to get the UART device for upload.  It should be something like alias recovery-uart or mcuboot-recovery-uart and if that's not OK in dts then use zephyr-console.  Isn't this the whole point of using device trees?  Also, the error disallowing serial boot and console together is wrong if the uart isn't zephyr-console.

While I do think that you have a point here, I want to understand the issue a bit more.

What are you trying to do?
Is it that you want to use another UART instance to print from the bootloader at the same time as doing serial recovery?

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Hi,

You are making good points.

bdodge09 said:

Perhaps I can make a PR for this to sdk-mcuboot?

A PR would be very welcome indeed!

But not to sdk-mcuboot.
sdk-mcuboot is just our fork of upstream mcuboot.

Since this is an improvement to only mcuboot, could you make a PR to https://github.com/mcu-tools/mcuboot instead?
If you would rather make an issue on it, you can do so to the same upstream repo.
Then if you link to the result here, I will point our developers to it, which might speed up the process.

Thanks a lot for showing interest in improving our tools, it is appreciated!

Regards,
Sigurd Hellesvik

[bdodge09]

github.com/.../1576

[Sigurd Hellesvik]

I have sent this to our developers, so they are now aware of the PR.

Regards,
Sigurd Hellesvik

[gfgf2400a]

Hi,

I am seeing the same issue with my nRF5340 of:

1) BIG Issue: Building a single-slot application with mcuboot (CONFIG_SINGLE_APPLICATION_SLOT=y in mcuboot.conf)  for the 5340dk doesn't build properly

Where do we stand in this issue?

Thanks,

Dennis

[Hieu]

Hi Dennis,

Unfortunately, CONFIG_SINGLE_APPLICATION_SLOT still does not work with the nRF5340. It is in the work, but I cannot comment on when it will be supported.

Our apology for the inconvenience.

Regards,

Hieu

[gfgf2400a]

Thanks for the update, Hieu. I would thought this firmware upgrade over serial is the first feature that any embedded MCU product should support before entering production.

[Hieu]

As you have thought, firmware upgrade over serial is already available for the nRF5340. 

The serial recovery for application core is enabled with CONFIG_MCUBOOT_SERIAL, and CONFIG_NRF53_RECOVERY_NETWORK_CORE for network core. It's only CONFIG_SINGLE_APPLICATION_SLOT that is not working at the moment. There seem to be some build system issue. As noted, fixing it and ironing out all the wrinkles is in progress.