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

[Simon Glass]

Hi Patryk,

On Thu, 2 Jul 2026 at 10:43, Patryk <pbiel7 at gmail.com> wrote:
>
> 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.

You could take a look at VBE[1], which implements A-B boot, storing
each slot as a FIT at a raw offset on the MMC (does not support
partitions at present).

So far I have only tried enabling it for rk3399, although I've never
quite been able to get the rockchip-specific changes into mainline. I
do have a Play board so could try implementing it on that, if it is
similar enough to your situation?

Regards,
Simon

[1] https://docs.u-boot-project.org/en/latest/develop/vbe.html