DRA821 Firmware Update: A/B boot and dynamic SPL payload selection

[Patryk]

Hi
I've been exploring the possibility of firmware update on the DRA821
platform and have a few questions regarding the solution that came to
my mind.
I target both SD and eMMC storage but SD is rather for development
purposes although extensively used so it should work as similar as
possible to prod solution. I need to update as much as possible with
possible rollback in case of boot failures.

For those not familiar with this SoC the boot flow is roughly (let's
skip details) something like this:
- bootROM loads tiboot3 (that contains spl) on R5 core
- spl loads tispl.bin (that contains BL31, BL32, A72 SPL) on A72 core
- A72 SPL loads u-boot.img with u-boot proper
- u-boot proper loads kernel

So my initial idea is to
- store tiboot3.bin on boot0/boot1 eMMC boot hw partition
- store tispl.bin, uboot.img, fitImage (with kernel) on boot-a /
boot-b UDA partitions
- put all the logic of slot selection in R5 SPL

So R5 SPL once loaded by bootROM, would use some sort of metadata
(let's assume some env variables for now, btw any better idea?), to
decide what slot to boot, then based on this information would load
tispl.bin. In the next phase A72 SPL would basically do the same for
the u-boot.img, and finally u-boot proper would load appropriate
fitImage. In general the selected slot index would be propagated to
each stage so each stage knows what slot to boot.

R5 SPL would also handle possible rollback by using some sort of boot
counter (e.g. stored in backup registers of SoC).

tiboot3.bin would also be updatable but I would update it only for
some special reasons - in this case I would just switch boot0 ->
boot1, or boot1 -> boot0. This case would require special care because
if an update failed, there would be no automatic rollback and users
would be forced to use backup boot mode.

In theory and from my perspective it looks good, however I've stumbled
upon some problems.
First - there is no possibility to use a board specific function to
select the boot partition. Currently SPL iterates over a list of
partitions and selects first bootable - more about this in
spl_mmc.c/spl_mmc_do_fs_boot() - would it be sensible to add here a
board specific weak function that would select the appropriate
partition to boot? If so - would it be welcome also in the mainline or
rather not?  CONFIG_SYS_MMCSD_FS_BOOT_PARTITION is obviously not the
case because the partition has to be selected dynamically.

Second - some SoCs do not support GPT partitioning schemes, and when
more partitions are required for various reasons there is no simple
way to provide separate partitions for boot slots (e.g. boot-a,
boot-b, root-a, root-b, data). In this case one could potentially use
single boot partition and use e.g. boot/tispl-a.bin / tispl-b.bin for
"slot" selection, but this is the same story as in case of partition
selection - the name of payload is hardcoded in config - would it make
sense to also support dynamic payload selection?

I would be grateful for any suggestion, especially if the solution I
outlined above does not completely make sense.
Just for the record - I come from another SoC where the first external
bootloader was implemented in TF-A (BL2) which has a well-defined boot
slot selection through PSA firmware update - that's why I try to
figure out something similar on DRA821 SoC.

Best regards.
Patryk