On Mon, 6 Mar 2023 at 15:32, Takahiro Akashi <takahiro.aka...@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.aka...@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 > > > >
