[PATCH 0/6] Add support for fwumdata

[Tom Rini]

On Thu, Dec 04, 2025 at 01:55:36PM +0200, Ilias Apalodimas wrote:
> On Wed, 3 Dec 2025 at 17:10, 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.
> 
> Indeed. However U-Boot was the first project to adopt and implement
> that spec. So the tool was naturally added here

Lets start by adding it here then, thanks.

-- 
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/20251204/17d39bbe/attachment.sig>