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
