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?