DFU serial boot with an external QSPI flash (v1.7.0)

[ronbo999]

Hi.

I'm currently evaluating all the DFU options available for nRF5340 using v1.7.0. One of those options is the mcuboot serial boot option.

During my mcuboot serial boot evaluation, I've encountered the following issues:

1) Serial boot upload is hard-coded to only work with the primary slot. Maybe we could have a configurable option to select primary or secondary slot as the destination so that I don't have to modify the bootloader/mcuboot/boot/boot_serial/src/serial_boot.c file.

I had to modify the following code in bs_upload() to use slot 1 for DFU.

#if !defined(MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD)
rc = flash_area_open(flash_area_id_from_multi_image_slot(img_num, 0), &fap);
#else
rc = flash_area_open(flash_area_id_from_direct_image(img_num), &fap);
#endif

2) Serial boot upload doesn't work with an external QSPI NOR flash as the destination secondary slot for the upload. In the bs_upload(), the flash_area_write() is called with a source address that's not 4 byte aligned causing the flash_area_write() to fail.

The buffer misalignment happens in the following code when img_data is assigned a pointer.

    /*
     * Expected data format.
     * {
     *   "image":<image number in a multi-image set (OPTIONAL)>
     *   "data":<image data>
     *   "len":<image len>
     *   "off":<current offset of image data>
     * }
     */

    struct Upload upload;
    uint32_t decoded_len;
    bool result = cbor_decode_Upload((const uint8_t *)buf, len, &upload, &decoded_len);

    if (!result || (len != decoded_len)) {
        goto out_invalid_data;
    }

    for (int i = 0; i < upload._Upload_members_count; i++) {
        struct Member_ *member = &upload._Upload_members[i];
        switch(member->_Member_choice) {
            case _Member_image:
                img_num = member->_Member_image;
                break;
            case _Member_data:
                img_data = member->_Member_data.value;
                slen = member->_Member_data.len;
                img_blen = slen;
                break;
            case _Member_len:
                data_len = member->_Member_len;
                break;
            case _Member_off:
                off = member->_Member_off;
                break;
            case _Member_sha:
            default:
                /* Nothing to do. */
                break;
        }
    }

To get the image upload to work for external QSPI flash, I had to copy the uploaded buffer to a temporary buffer that's 4-byte aligned.

 

3) The serial boot "image test" command is not supported. There's no way for me to mark the two images (app core & network core) that I upload  in the secondary slots as good. I had to implement the "image test" command so that I can test boot the new images by calling the boot_request_upgrade_multi(). It would also be good if the "flags" and "hash" values are sent back in response to the "image list" command.

Can those issues I mentioned above get fixed? I would rather not keep those changes locally and re-apply them every time there's a new NCS release.

Attached is the example project that I used to test serial_boot with the nRF5340-DK board.7418.peripheral_uart.zip

To duplicate the issue, do the following:

1) In the ncs/v1.7.0/bootloader/mcuboot/boot/boot_serial/src/serial_boot.c file, make the following one line change in the bs_upload(). 

#if !defined(MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD)
rc = flash_area_open(flash_area_id_from_multi_image_slot(img_num, 1), &fap);               <---- change 0 to 1
#else
rc = flash_area_open(flash_area_id_from_direct_image(img_num), &fap);
#endif

2) Unzip the peripheral_uart.zip file. Build the project for the nRF5340-DK board and flash the image.

i.e.

west build -b nrf5340dk_nrf5340_cpuapp

west flash --erase

3) Put the board in DFU serial boot mode by holding button 1 while you press the reset button.

4) Use mcumgr to upload the app_update.bin file.

$ mcumgr --conntype serial --connstring=COM8,baud=115200 image upload app_update.bin
0 B / 125.29 KiB 0.00%

You will notice that the percentage value is stuck at 0%.

[Vidar Berg]

Hello,

Thanks for including the sample project. I will try it here and get back to you with an update tomorrow.

Best regards,

Vidar

Update:
Sorry for the delay. I have added the bugs and limitations you reported here to our internal bug tracker now so the team can take a look at it.

Update 2: Here is the feedback I got from the team: "The customer is using the serial recovery mechanism for performing the update. This feature is written specifically for overwriting the primary partition only, this to keep its functionality, and hence memory footprint to a minimum. If you want to perform serial DFU that should be done through the MCUmgr protocol, as shown in the SMP server samples, when this protocol is used the features requested by the customer are already in place see https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html#direct-image-upload-and-image-mapping-to-mcuboot-slot"

[variant]

The Update #2 above is not taking into account that this ticket is not for an OTA update.  As stated at the top of the ticket, "During my mcuboot serial boot evaluation, I've encountered the following issues:"

[Vidar Berg]

MCUmgr supports serial DFU as well.