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?
