J721E A/B boot with tiboot3 in eMMC boot0 and remaining firmware in UDA

[Patryk]

Hi,
I am looking for advice on how to implement an A/B update scheme for a
custom J721E board.
The BeagleBone AI-64 eMMC layout looks close to what I want:
eMMC boot0:
  - tiboot3.bin
eMMC UDA /BOOT:
  - sysfw.itb  tispl.bin
  - u-boot.img

For my board I would like to extend this to A/B, roughly:
eMMC boot0:
  - tiboot3.bin
eMMC UDA boot_a:
  - sysfw.itb
  - tispl.bin
  - u-boot.img
  - FITImage
eMMC UDA boot_b:
  - sysfw.itb
  - tispl.bin
  - u-boot.img
  - FITImage
eMMC UDA:
  - rootfs_a
  - rootfs_b
  - metadata?

On LS1028A I used a fixed, non-A/B BL2 as the early boot anchor. That
BL2 contained the A/B selection, metadata handling and rollback logic,
while the updatable A/B slots contained the later firmware and OS
components. Basically the boot process follows the PSA Firmware
Update.

On this SoC I would treat tiboot3.bin as a critical anchor component.
It could still be updated when really needed, possibly using the eMMC
boot0/boot1 hardware partition selection, but I would prefer not to
use the eMMC boot partition switching mechanism for all boot
components.

The missing piece is early slot selection. As far as I understand, R5
SPL must select boot_a or boot_b before loading sysfw.itb, and A72 SPL
must then load u-boot.img from the same selected slot so in needs a
place to get this information from (e.g. FWU Metadata like on LS1028A)

I also noticed however that FWU metadata does not seem intended for
SPL use in the current tree. For example, lib/fwu_updates/ is guarded
by ifndef CONFIG_XPL_BUILD, and the FWU metadata drivers also seem to
be built only outside SPL/TPL. So I am not sure whether reading FWU
metadata directly from SPL is the expected direction.

My questions are:

1. Is there an existing recommended U-Boot mechanism for this on K3/J721E?
2. Would it be reasonable to add a board-specific SPL hook to select
the MMC filesystem boot partition dynamically? If so then based on
what excatly? (Related to Q3).
3. Should the slot state be custom board metadata, FWU metadata, or
something else?
4. What would be the preferred way to propagate the selected slot from
R5 SPL to A72 SPL / U-Boot proper? Backup registers / I2C RTC RAM
byte?

The goal is to keep tiboot3.bin as a small critical anchor in eMMC
boot0/boot1, while making sysfw.itb, tispl.bin, u-boot.img,
kernel/FIT, and rootfs part of a normal A/B update scheme in UDA.

Any guidance on the preferred architecture or existing hooks would be
appreciated.

Best regards
Patryk