On Wed, Dec 03, 2025 at 06:13:29PM +0100, Kory Maincent wrote: > On Wed, 3 Dec 2025 09:10:48 -0600 > Tom Rini <[email protected]> wrote: > > > On Wed, Dec 03, 2025 at 03:59:24PM +0100, Kory Maincent wrote: > > > On Wed, 3 Dec 2025 15:04:10 +0100 > > > 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. > > > > > > 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.
I mean in general, there are a lot of things in the u-boot source tree that may or may not really make sense to have, in tree. We also can't, right now, easily support or handle having multiple distinct projects under the u-boot umbrella. I'm wondering if we should figure out how to support a few source repositories under our umbrella, in a way that would make life easier for other projects too. -- Tom
signature.asc
Description: PGP signature
