Hi all, I'm planning to add A/B firmware-update slot selection on a TI K3 DRA821 platform (will be testing on a J7200 EVM, nothing really implemented yet, I'm still evaluating the approach and messing around with the code) and would appreciate some guidance.
For context, let me just briefly recall the boot flow of this platform. On K3 the chain is: ROM, then R5 SPL (the first SPL, bundled with TIFS in tiboot3.bin), then ATF/BL31, then optional OP-TEE, then A72 SPL, then U-Boot proper. The R5 SPL is loaded by ROM from the eMMC boot0/boot1 hardware partitions, which makes it a natural immutable anchor. Unlike the PSA/TF-A model where BL2 picks the active bank, here the earliest stage that can make a slot decision is R5 SPL. I'd like that stage to select the slot (and roll back to the previous one on a failed boot, tracked by a boot counter in an RTC/syscon/backup register/whatever applicable, not in env). My questions: 1) Why is FWU_MULTI_BANK_UPDATE (the fwu_mdata metadata handling) U-Boot-proper only, with no SPL support? Is that a deliberate design decision (e.g. size, dependency on the EFI/capsule machinery), or just that no one has needed it in SPL yet? For my flow the slot decision has to happen in R5 SPL, long before U-Boot proper runs. 2) Is storing the A/B metadata (active/previous slot + per-slot state) in the U-Boot environment a reasonable approach, or is it discouraged? My reasoning: the env already has CRC, redundant env gives two power-fail-safe copies, and SPL can already read env today (it's used for Falcon mode), so the read path exists in both SPL and U-Boot proper. The downside I see is that there's only one environment, so my fwu.* metadata would share it with bootcmd etc., and a userspace saveenv or a bad script could clobber boot-selection state. Is that coupling considered acceptable in practice, or do people keep FWU metadata in a separate store for exactly this reason? Beyond that and the default-env fallback when both copies fail CRC, are there pitfalls I'm underestimating? 3) VBE. I'm aware this overlaps with what VBE aims to solve, I've looked at it, but, for now it's kinda off the table (too much integration effort for this project), but it may be an option later. Happy to hear if that changes the recommendation. Best regards Patryk
