• State Not Answered
  • Replies 12 replies
  • Subscribers 66 subscribers
  • Views 2275 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301036
Options

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?

Parents
  • 0

    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

  • 0 in reply to 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

  • 0 in reply to Sigurd Hellesvik

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

  • 0 in reply to bdodge09
    bdodge09 said:
    And we also have potential h/w designs that use both uarts for non-console uses.

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

    Sigurd Hellesvik said:
    Is it that you want to use another UART instance to print from the bootloader at the same time as doing serial recovery?

    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

Reply
  • 0 in reply to bdodge09
    bdodge09 said:
    And we also have potential h/w designs that use both uarts for non-console uses.

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

    Sigurd Hellesvik said:
    Is it that you want to use another UART instance to print from the bootloader at the same time as doing serial recovery?

    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

Children
Related