Multiple issues with mcuboot + serial recovery

RE: Multiple issues with mcuboot + serial recovery

Hieu — Mon, 14 Aug 2023 13:23:25 GMT

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.

RE: Multiple issues with mcuboot + serial recovery

gfgf2400a — Mon, 14 Aug 2023 12:44:28 GMT

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.

RE: Multiple issues with mcuboot + serial recovery

Hieu — Mon, 14 Aug 2023 12:23:14 GMT

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

RE: Multiple issues with mcuboot + serial recovery

gfgf2400a — Tue, 08 Aug 2023 15:50:49 GMT

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

RE: Multiple issues with mcuboot + serial recovery

Sigurd Hellesvik — Mon, 16 Jan 2023 07:43:16 GMT

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

Regards,
Sigurd Hellesvik

RE: Multiple issues with mcuboot + serial recovery

bdodge09 — Fri, 13 Jan 2023 15:33:55 GMT

github.com/.../1576

RE: Multiple issues with mcuboot + serial recovery

Sigurd Hellesvik — Fri, 13 Jan 2023 08:30:12 GMT

Hi,

You are making good points.

[quote user="bdodge09"]Perhaps I can make a PR for this to sdk-mcuboot?[/quote]

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

RE: Multiple issues with mcuboot + serial recovery

bdodge09 — Thu, 12 Jan 2023 15:46:27 GMT

Our real products won't have nice things like jlink, etc. We wouldn't want to expose a console in any case for security. For just dev-kit use I wouldn't have problems using zephyr-console in this case. In a real product that contains multiple nrf chips (and other chips) we want to use one uart for fwup and another for another purpose. The SDK should *not* limit us on which uart we want to use for which function especially since the issue it trivially solved with a few lines of code in the SDK. Perhaps I can make a PR for this to sdk-mcuboot?

RE: Multiple issues with mcuboot + serial recovery

Sigurd Hellesvik — Thu, 12 Jan 2023 11:54:39 GMT

[quote user="bdodge09"]And we also have potential h/w designs that use both uarts for non-console uses.[/quote]

In that case you can use something else that "zephyr,console" for those non-console uses, right?

[quote user="Sigurd Hellesvik"]Is it that you want to use another UART instance to print from the bootloader at the same time as doing serial recovery?[/quote]

By the way, would RTT solve this issue for you?
Then you can let the Serial Recovery use zephyr,console while logging over RTT

Regards,
Sigurd Hellesvik

RE: Multiple issues with mcuboot + serial recovery

bdodge09 — Thu, 12 Jan 2023 11:38:45 GMT

Yes. And we also have potential h/w designs that use both uarts for non-console uses.

RE: Multiple issues with mcuboot + serial recovery

Sigurd Hellesvik — Thu, 12 Jan 2023 08:42:37 GMT

[quote user=""]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.[/quote]

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

RE: Multiple issues with mcuboot + serial recovery

Sigurd Hellesvik — Tue, 10 Jan 2023 13:42:30 GMT

Hi Brian,

[quote user=""]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:[/quote]

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

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

[quote user=""]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.[/quote]

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.

[quote user=""]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?[/quote]

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