Hi Patryk, On Thu, 2 Jul 2026 at 10:43, Patryk <[email protected]> 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
