dfu: boot: mcuboot: fix boot_is_img_confirmed

[maass-hamburg]

add boot_request_upgrade_by_id() to request a
update to the provided partition.

Fix image confirmed for Direct XIP.

[nordicjm]

This function should be used, a new function taking a partition ID should not be introduced

[maass-hamburg]

this one unfortunately does something different, that is for pairs.
it will only use the secondary slots.

image_index = 0 will request on slot1_partition
image_index = 1 will request on slot3_partition
image_index = 2 will request on slot5_partition

and I can't request an update on slot0, which I need.

[maass-hamburg]

look in bootloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h and /home/[email protected]/zephyr-apps/sw__otem_mcu/bootloader/mcuboot/boot/bootutil/src/bootutil_public.c

[nordicjm]

MCUboot operates in pairs so I don't understand the problem? Or are you saying you are using directXIP mode and it's marking the wrong slot? If so, then the function I pointed to should be updated to support XIP mode but adding a new function just taking a partition ID is not acceptable

[nordicjm]

See functions in https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c

[maass-hamburg]

It is marking the wrong slot. Its not just for directXIP, but also for ram load mode (even throw mcuboot currently don't hake use of the trailer, but could be extended the same way that DIRECT_XIP got extended to DIRECT_XIP_REVERT and use the same functionality)

[de-nordic]

Several reasons we should not follow this path:
0) There is already a function that allows you to select next boot slot without knowledge of partitioning layout, just by pointing to image and setting desired effect boot_request_upgrade_multi, the function orders update of running slot with contents of the alternative slot or in case of DirectXIP it should mark the next slot to boot, without swap.

1. Need to fix bootutil entanglement with Zephyr; there is significant problem with mixing Flash Map API from Zephyr and Fixed Partition Ids with the definitions in MCUboot/bootutil; we need to figure out a way to remove the entanglement and make bootutil, when used by application to work with definitions provided by Zephyr;
2. Rather than pointing slot we want to boot we should allow bootutil to just allow app to set whether specific image shoudl continue booting from current slot or change the slot (test/confirm) to the alternative slot assigned to image; this should not involve and knowledge on partitioning or partition identification;
3. Flash Are ID are going away in a near fature: instantiation of flash area objects at point of usage #81244, if that PR gets in, it will be followed by Issue proposal of changes to Zephyr where every path ditches usage of ID, then adaptation in MCUboot and finally flash_area_open/flash_area_close are going to be deprecated.