Hi Patryk, On Wed, 3 Dec 2025 at 16:04, Patryk <[email protected]> wrote: > > Hi Ilias, > > > > > Add a new fwumdata tool to allows users to read, display, and modify FWU > > > > (Firmware Update) metadata from Linux userspace. It provides > > > > functionality > > > > similar to fw_printenv/fw_setenv but for FWU metadata. Users can view > > > > metadata, change active/previous bank indices, modify bank states, and > > > > set > > > > image acceptance flags. Configuration is done via fwumdata.config file. > > > > > > > > Made a few change to mkfwumdata tool along the way. > > > > > > Still wondering about the choice of putting this fwumdata tool in U-Boot > > > instead of TF-A. TF-A is the boot part that manages the update process and > > > rollback through the FWU metadata, > > > therefore, this is where it should belong. > > > Why, in the first place, mkfwumdata was accepted into U-boot instead of > > > TF-A? > > > > The actual update happens via capsule updates only, which runs in > > BL33. TF-A needs to be aware in case it's involved in the boot process > > and fails to boot. In that case BL2 is responsible for booting via the > > other bank. > > But generally speaking it's U-Boot that processes and usually updates that > > file > > If I may add something - actually for me this is not that obvious, > e.g. on our platform we update the metadata directly from Linux, not > from the u-boot capsule. As far as I'm aware, the ST, in their > OpenstLinux does the same. > I'm also not sure why it would be the bad > idea to do this from Linux. Ofc the BL2 handles bank selection as well > as rollback in case of boot failure on a newly selected bank. >
The whole point of the spec, is to be able to have A/B support via EFI interfaces. There's also an indication in the ESRT table, that an update is pending for approval. But if the data lives in a file in the non-secure world you can technically update it from linux. Thanks /Ilias > Best regards > Patryk
