[PATCH 0/6] Add support for fwumdata

[Kory Maincent]

On Wed, 3 Dec 2025 09:10:48 -0600
Tom Rini <trini at konsulko.com> wrote:

> On Wed, Dec 03, 2025 at 03:59:24PM +0100, Kory Maincent wrote:
> > On Wed, 3 Dec 2025 15:04:10 +0100
> > Patryk <pbiel7 at gmail.com> 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.  
> > 
> > I agreed with Patryk. U-boot is only an update agent (as explained by the
> > standard) of FWU metadata as Barebox or Linux could be. FWU metadata is an
> > ARM standard which is related to the update of the images that boot after
> > the ARM firmware. It is not related to any project. As TF-A is the
> > mainstream project for ARM firmware having mkfwumdata and fwumdata in it
> > seems more suitable. I am not familiar with these EFI capsule update, does
> > it not rely on TF-A to select the boot image according to the FWU metadata
> > state?
> > 
> > Anyway, now it is too late and mkfwumdata has already landed in U-boot for 2
> > years. Not sure what we should do here. Put all in U-boot and let the other
> > projects (barebox) copy the code if they need it? Or move all to TF-A while
> > keeping a deprecated copy of mkfwumdata in U-boot to not break things?  
> 
> Perhaps in the medium term we can split that tooling out from the main
> project source tree itself, to make it easier for OSes to use this tool
> (and other tools we have). There's nothing U-Boot specific about this,
> if I'm following the thread right.

This isn't clear to me.
Are you saying that we should plan in removing mkfwumdata in the medium term?
And in the short time, sending the two tools to TF-A to get them accepted.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com