DFU choice of upload slot

[leonwip]

Commit 87b1bb8 in Zephyr changed the behavior of MCUboot by selecting the upload slot based on what partition zephyr,code-partition points to in the DTS. However, app/sysbuild/mcuboot/app.overlay sets zephyr,code-partition to boot_partition, not to either slot0_partition or slot1_partition. As a result, we always take the else branch and upload to slot0_partition, which often is the wrong choice.

I can also see that boot_partition is the valid zephyr,code-partition for MCUboot itself. Therefore I’m not entirely sure whether this should be addressed in CANnectivity, in Zephyr, or in my board support.

[henrikbrixandersen]

I think you may have things confused a bit. Let me try to explain the usage of these chosen nodes:

• The zephyr,code-partition chosen node specifies the flash partition that the Zephyr image's text section should be linked into.
• For the MCUboot bootloader, this is the boot_partition - not only in the CANnectivity MCUboot configuration, but also in the Zephyr fork (https://github.com/zephyrproject-rtos/mcuboot/blob/main/boot/zephyr/app.overlay) and in upstream MCUboot (https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/app.overlay).
• For an application being loaded by the MCUboot bootloader, the zephyr,code-partition should either be slot0_partition or slot1_partition depending on the way the MCUboot bootloader is used/configured.
• Zephyr commit zephyrproject-rtos/zephyr@87b1bb8 (introduced via dfu: img_util: Upload to slot0 if not running from slot0 zephyrproject-rtos/zephyr#92676) fixes the issue reported in USB DFU class restricts downloads to slot-1 even when recovery via slot-0 is required zephyrproject-rtos/zephyr#91042 where the application is not running from slot0_partition, but instead running from slot1_partition.

Are you seeing any issues related to this change in CANnectivity?

[leonwip]

Thank you for the clarification. Yes, I am seeing that CANnectivity DFU stops working after zephyrproject-rtos/zephyr#92676, and what I observed is that when sysbuilding MCUboot within CANnectivity, CONFIG_FLASH_LOAD_OFFSET gets generated to be the offset of the boot_partition and not one of the slots, so the IS_RUNNING_APP_PARTITION check doesn't work. If I remove app/sysbuild/mcuboot/app.overlay, CONFIG_FLASH_LOAD_OFFSET becomes the offset of the application’s zephyr,code-partition, and MCUboot flashes the other partition before swap move.

[henrikbrixandersen]

Which type of USB DFU backend are you using? USB DFU via MCUboot itself (regular CANnectivity prj.conf)? Or USB DFU via CANnectivity (CANnectivity prj_usbd_next.conf)?

[henrikbrixandersen]

I can reproduce issues after said commit. It's not limited to CANnectivity, but reproducible on e.g. hello_world as well. I have opened zephyrproject-rtos/zephyr#101676 to get some my eyes on it.

[leonwip]

Thank you :)

[henrikbrixandersen]

@leonwip By the way, you can try out the newer USB DFU support using the Zephyr USB device_next stack in CANnectivity (given that your boards SoC supports device_next):

west build -b <board> --sysbuild cannectivity/app/ -- -DSB_CONF_FILE=sysbuild-dfu.conf -DFILE_SUFFIX=usbd_next

This will use the application as DFU backend per default, meaning MCUboot will just be used for swapping the images upon rebooting.

[leonwip]

Cool! That worked flawlessly with my board!