2025-12-16 3:11 AM - edited 2025-12-16 3:42 AM
Hi, I'm trying to understand the firmware / software stack update and I'm quite confused with one thing.
I'm quite familiar with the PSA firmware update, metadata, TF-A integration and so on, I've got an access to meta-st-ota.
From what I understand, once you find the active boot index in TF-A, the TF-A writes a boot index into backup registers so that it can be propagated to the next stages.
But how do you use this index in the next stage (u-boot) actually? I see that indeed it is used in fwu_plat_get_bootidx function which is only available only when CONFIG_FWU_MULTI_BANK is enabled, but it's not used in e.g. rauc boot method.
So that why I'm confused. I would rather expect sth like this:
- assume active index is set to 0 in metadata
- BL2 loads metadata
- BL2 lodas boot idx = 0
- BL2 sets boot_idx just before it loads BL33
- BL2 loads firmware from fip-a
- u-boot checks fwu_plat_get_bootidx
- u-boot based on boot_idx selects boot-a and root-a (if. boot_idx = 1, u-boot selects boot-b and root-b)
Now it seems that the information propagated by TF-A is not used at all except for the configuration with CONFIG_FWU_MULTI_BANK_UPDATE enabled which - correct me if I'm wrong - it's not used in meta-st-ota.
In this setup we actually have multiple possible configurations:
- FW bank: A, SW bank: A
- FW bank: A, SW bank: B
- FW bank: B, SW bank: A
- FW bank: B, SW bank: B
Is it expected?
Also it seems wierd that some user-space scripts update TF-A metadata accordingly to rauc.slot which does not relay on this metadata at all.
To be honest I'm not deeply familiar on how RAUC works, but suppose that besides updating active bank in metadata, rauc istelf changes the boot order. What if the operation gets interrupted in the middle? Suppose that the system updated the metadata but did not manage to update boot order due to e.g. reset? Don't we have system in inconsistent state then? Isn't it a problem with 2 source of true for selecting banks?