[PATCH v2 0/4] FMP versioning support

Masahisa Kojima masahisa.kojima at linaro.org
Mon Mar 6 08:26:19 CET 2023


On Mon, 6 Mar 2023 at 15:32, Takahiro Akashi <takahiro.akashi at linaro.org> wrote:
>
> On Mon, Mar 06, 2023 at 03:08:55PM +0900, Masahisa Kojima wrote:
> > Hi Akashi-san,
> >
> > On Sat, 4 Mar 2023 at 10:28, Takahiro Akashi <takahiro.akashi at linaro.org> wrote:
> > >
> > > Kojima-san,
> > >
> > > On Wed, Mar 01, 2023 at 06:15:18PM +0900, Masahisa Kojima wrote:
> > > > Firmware version management is not implemented in the current
> > > > FMP implementation. This series aims to add the versioning support
> > > > in FMP.
> > >
> > > I think that you need to think of A/B update case, especially
> > > when a capsule update is *reverted* to an older version.
> >
> > A/B update(FWU) has their own version information in the Image Directory
> > defined in FWU spec[1], this is not implemented yet on U-Boot.
> > On second thought, I think A/B update(FWU) case should be excluded
> > from the version management introduced by this series.
>
> I don't think it's a good idea to have two different implementations
> for normal case and A/B update unless there is a good reason when
> we use the same FMP driver.

Yes, I think we need different FMP drivers for the normal case
and A/B update case if we implement the different version management.
It's just a thought that we can transfer the FWU specific code from
lib/efi_loader/efi_capsule.c to FMP driver for FWU.

Another idea is that we implement version management defined in FWU
spec and it is also used for a normal case, but I'm not sure it is feasible.

Thanks,
Masahisa Kojima

>
> -Takahiro Akashi
>
> > >
> > > In addition, please don't forget in the next patch set:
> > > - update the man page of mkeficapsule command
> > > - add test cases (in pytest)
> >
> > Yes, noted.
> >
> > [1] https://developer.arm.com/documentation/den0118/a/
> >
> > Thanks,
> > Masahisa Kojima
> >
> > >
> > > -Takahiro Akashi
> > >
> > > > EDK2 reference implementation utilizes the FMP Payload Header
> > > > inserted right before the capsule payload. With this series,
> > > > U-Boot also follows the EDK2 implementation.
> > > >
> > > > Currently, there is no way to know the current running firmware
> > > > version through the EFI interface. FMP->GetImageInfo() returns
> > > > always 0 for the version number. So a user can not know that
> > > > expected firmware is running after the capsule update.
> > > >
> > > > With this series applied, version number can be specified
> > > > in the capsule file generation with mkeficapsule tool, then
> > > > user can know the running firmware version through
> > > > FMP->GetImageInfo() and ESRT.
> > > >
> > > > Note that this series does not mandate the FMP Payload Header,
> > > > compatible with boards that are already using the existing
> > > > U-Boot FMP implementation.
> > > > If no FMP Payload Header is found in the capsule file, fw_version,
> > > > lowest supported version, last attempt version and last attempt
> > > > status is set to 0 and this is the same behavior as existing FMP
> > > > implementation.
> > > >
> > > > Changes in v2:
> > > > - add FMP Payload Header generation in mkeficapsule tool
> > > >
> > > > Masahisa Kojima (4):
> > > >   efi_loader: store firmware version into FmpState variable
> > > >   efi_loader: versioning support in GetImageInfo
> > > >   efi_loader: check lowest supported version in capsule update
> > > >   mkeficapsule: add FMP Payload Header
> > > >
> > > >  lib/efi_loader/efi_firmware.c | 271 ++++++++++++++++++++++++++++++----
> > > >  tools/mkeficapsule.c          |  81 +++++++++-
> > > >  2 files changed, 319 insertions(+), 33 deletions(-)
> > > >
> > > > --
> > > > 2.17.1
> > > >


More information about the U-Boot mailing list