| Message ID | 20230301091523.18384-1-masahisa.kojima@linaro.org |
|---|---|
| Headers | show |
| Series | FMP versioning support | expand |
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. In addition, please don't forget in the next patch set: - update the man page of mkeficapsule command - add test cases (in pytest) -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 >
Hi Akashi-san, On Sat, 4 Mar 2023 at 10:28, Takahiro Akashi <takahiro.akashi@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. > > 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 > >
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@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. -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 > > >
On Mon, 6 Mar 2023 at 15:32, Takahiro Akashi <takahiro.akashi@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@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 > > > >