[PATCH 0/6] Add support for fwumdata

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251203/2eb766d6/attachment.sig>