| Message ID | 20200317021247.5849-1-takahiro.akashi@linaro.org |
|---|---|
| Headers | show |
| Series | efi_loader: add capsule update support | expand |
On 3/17/20 3:12 AM, AKASHI Takahiro wrote: > Summary > ======= > 'UpdateCapsule' is one of runtime services defined in UEFI specification > and its aim is to allow a caller to pass information to the firmware. > This is mostly used to update firmware binary on devices by instructions > from OS. > > In this patch series, all the related definitions and structures are given > as UEFI specification describes and basic framework for capsule support is > implemented. Currently supported types of capsule are > * firmware update (Firmware Management Protocol or simply FMP) > * variable update > > UpdateCapsule is a runtime services function, but is, at least initially, > provided only before exiting boot services alike other runtime functions. > This is because modifying storage which may be shared with OS must be > carefully designed and there is no general assumption to do that as in > the case of [Get/]SetVariable. > Instead, any capsule can be handed over to the firmware as a file on > a specific file system. In other words, we only support "capsules on disk" > for now. > > Regarding firmware update, most of functionality is provided by FMP > driver and it will be by nature system/platform-specific. So you can and > should implement FMP drivers based on your system requirements. > In this patch series, only a simple FMP driver based on FIT image for > a single region is supported. (So it is "for reference only") > See more details in "efi_loader: capsule: add simple firmware management > protocol." > > Regarding variable update, the implementation here is based on a draft > proposal[1] by Peter in Boot-arch ML. The specification should be discussed > and finalized first. So the code doesn't fully implement Peter's idea. > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html I do not like the idea of exposing variables as a configuration table as operating system users may start doing strange things like accessing variables via the configuration table. Why not keep the pointer to the internal storage of variable hidden in your runtime code and expose the runtime services defined in the UEFI spec? Please, elaborate on the benefit of your approach. Best regards Heirnich > > Patch structure > =============== > Patch#1-#4: preparatory patches > Patch#5-#11: main part of implementation > Patch#12-#14: utilities and tests > > Test > ==== > * passed all the pytests which are included in this patch series > on sandbox build. > * passed Travis CI. > > Currently, my pytest requires the following prerequisite patch to > run without errors: > [2] https://lists.denx.de/pipermail/u-boot/2020-March/401726.html > [3] https://lists.denx.de/pipermail/u-boot/2020-March/401727.html > > In addition, you have to enable CONFIG_ENV_IS_IN_SPI_FLASH and > CONFIG_SPI_FLASH_SANDBOX to successfully run the test. > > Issues > ====== > * Timing of executing capsules-on-disk > Currently, processing a capsule is triggered only as part of > UEFI subsystem initialization. This means that, for example, > firmware update, may not take place at system booting time and > will potentially be delayed until a first call of any UEFI functions. > > TODO's > ====== > (May or may not be addressed in future versions of this series.) > * capsule authentication > * capsule dependency (dependency expression instruction set) > * loading drivers in a capsule > * handling RESET flag in a capsule and QeuryCapsuleCaps > * full semantics of ESRT (EFI System Resource Table) > * enabling capsule API at runtime > * json capsule > * recovery from update failure > > > Changes > ======= > Initial release as RFC (March 17, 2020) > > AKASHI Takahiro (14): > efi_loader: define OsIndicationsSupported flags > efi_loader: define System Resource Table macros > efi_loader: export a couple of protocol related functions > efi_loader: correct a definition of struct efi_capsule_header > efi_loader: define UpdateCapsule api > efi_loader: capsule: add capsule_on_disk support > efi_loader: capsule: add memory range capsule definitions > efi_loader: capsule: support firmware update > efi_loader: add simple firmware management protocol for FIT image > efi_loader: capsule: support variable update > efi_loader: variable: export variables table for runtime access > cmd: add "efidebug capsule" command > tools: add mkeficapsule command for UEFI capsule update test > test/py: add efi capsule test > > cmd/efidebug.c | 234 +++++ > include/efi_api.h | 214 ++++- > include/efi_loader.h | 53 ++ > lib/efi_loader/Kconfig | 65 ++ > lib/efi_loader/Makefile | 2 + > lib/efi_loader/efi_boottime.c | 29 +- > lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++ > lib/efi_loader/efi_firmware.c | 191 ++++ > lib/efi_loader/efi_runtime.c | 104 ++- > lib/efi_loader/efi_setup.c | 41 +- > lib/efi_loader/efi_variable.c | 109 +++ > test/py/tests/test_efi_capsule/conftest.py | 109 +++ > test/py/tests/test_efi_capsule/defs.py | 21 + > .../test_efi_capsule/test_capsule_firmware.py | 102 +++ > .../test_efi_capsule/test_capsule_variable.py | 141 +++ > test/py/tests/test_efi_capsule/uboot_env.its | 25 + > tools/Makefile | 3 + > tools/mkeficapsule.c | 501 ++++++++++ > 18 files changed, 2744 insertions(+), 60 deletions(-) > create mode 100644 lib/efi_loader/efi_capsule.c > create mode 100644 lib/efi_loader/efi_firmware.c > create mode 100644 test/py/tests/test_efi_capsule/conftest.py > create mode 100644 test/py/tests/test_efi_capsule/defs.py > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py > create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its > create mode 100644 tools/mkeficapsule.c >
Heinrich, Thank you for your quick review. On Tue, Mar 17, 2020 at 08:49:12AM +0100, Heinrich Schuchardt wrote: > On 3/17/20 3:12 AM, AKASHI Takahiro wrote: > > Summary > > ======= > > 'UpdateCapsule' is one of runtime services defined in UEFI specification > > and its aim is to allow a caller to pass information to the firmware. > > This is mostly used to update firmware binary on devices by instructions > > from OS. > > > > In this patch series, all the related definitions and structures are given > > as UEFI specification describes and basic framework for capsule support is > > implemented. Currently supported types of capsule are > > * firmware update (Firmware Management Protocol or simply FMP) > > * variable update > > > > UpdateCapsule is a runtime services function, but is, at least initially, > > provided only before exiting boot services alike other runtime functions. > > This is because modifying storage which may be shared with OS must be > > carefully designed and there is no general assumption to do that as in > > the case of [Get/]SetVariable. > > Instead, any capsule can be handed over to the firmware as a file on > > a specific file system. In other words, we only support "capsules on disk" > > for now. > > > > Regarding firmware update, most of functionality is provided by FMP > > driver and it will be by nature system/platform-specific. So you can and > > should implement FMP drivers based on your system requirements. > > In this patch series, only a simple FMP driver based on FIT image for > > a single region is supported. (So it is "for reference only") > > See more details in "efi_loader: capsule: add simple firmware management > > protocol." > > > > Regarding variable update, the implementation here is based on a draft > > proposal[1] by Peter in Boot-arch ML. The specification should be discussed > > and finalized first. So the code doesn't fully implement Peter's idea. > > > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > I do not like the idea of exposing variables as a configuration table as > operating system users may start doing strange things like accessing > variables via the configuration table. Why not keep the pointer to the > internal storage of variable hidden in your runtime code and expose the > runtime services defined in the UEFI spec? > > Please, elaborate on the benefit of your approach. I have already commented on your reply to my patch#11. Rather, my aim of this patch is to discuss the following points: > > Issues > > ====== > > * Timing of executing capsules-on-disk > > Currently, processing a capsule is triggered only as part of > > UEFI subsystem initialization. This means that, for example, > > firmware update, may not take place at system booting time and > > will potentially be delayed until a first call of any UEFI functions. and > > TODO's > > ====== > > (May or may not be addressed in future versions of this series.) > > * capsule authentication > > * capsule dependency (dependency expression instruction set) > > * loading drivers in a capsule > > * handling RESET flag in a capsule and QeuryCapsuleCaps > > * full semantics of ESRT (EFI System Resource Table) > > * enabling capsule API at runtime > > * json capsule > > * recovery from update failure What functionality should be initially included in my first implementation for capsule support. FYI, Sughosh is going to work on * capsule authentication * recovery from update failure (or at least, A/B partition) in the coming months. Thanks, -Takahiro Akashi > > > > > > Changes > > ======= > > Initial release as RFC (March 17, 2020) > > > > AKASHI Takahiro (14): > > efi_loader: define OsIndicationsSupported flags > > efi_loader: define System Resource Table macros > > efi_loader: export a couple of protocol related functions > > efi_loader: correct a definition of struct efi_capsule_header > > efi_loader: define UpdateCapsule api > > efi_loader: capsule: add capsule_on_disk support > > efi_loader: capsule: add memory range capsule definitions > > efi_loader: capsule: support firmware update > > efi_loader: add simple firmware management protocol for FIT image > > efi_loader: capsule: support variable update > > efi_loader: variable: export variables table for runtime access > > cmd: add "efidebug capsule" command > > tools: add mkeficapsule command for UEFI capsule update test > > test/py: add efi capsule test > > > > cmd/efidebug.c | 234 +++++ > > include/efi_api.h | 214 ++++- > > include/efi_loader.h | 53 ++ > > lib/efi_loader/Kconfig | 65 ++ > > lib/efi_loader/Makefile | 2 + > > lib/efi_loader/efi_boottime.c | 29 +- > > lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++ > > lib/efi_loader/efi_firmware.c | 191 ++++ > > lib/efi_loader/efi_runtime.c | 104 ++- > > lib/efi_loader/efi_setup.c | 41 +- > > lib/efi_loader/efi_variable.c | 109 +++ > > test/py/tests/test_efi_capsule/conftest.py | 109 +++ > > test/py/tests/test_efi_capsule/defs.py | 21 + > > .../test_efi_capsule/test_capsule_firmware.py | 102 +++ > > .../test_efi_capsule/test_capsule_variable.py | 141 +++ > > test/py/tests/test_efi_capsule/uboot_env.its | 25 + > > tools/Makefile | 3 + > > tools/mkeficapsule.c | 501 ++++++++++ > > 18 files changed, 2744 insertions(+), 60 deletions(-) > > create mode 100644 lib/efi_loader/efi_capsule.c > > create mode 100644 lib/efi_loader/efi_firmware.c > > create mode 100644 test/py/tests/test_efi_capsule/conftest.py > > create mode 100644 test/py/tests/test_efi_capsule/defs.py > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py > > create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its > > create mode 100644 tools/mkeficapsule.c > > >
On Tue, 17 Mar 2020 at 07:42, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote: > Summary > ======= > 'UpdateCapsule' is one of runtime services defined in UEFI specification > and its aim is to allow a caller to pass information to the firmware. > This is mostly used to update firmware binary on devices by instructions > from OS. > > In this patch series, all the related definitions and structures are given > as UEFI specification describes and basic framework for capsule support is > implemented. Currently supported types of capsule are > * firmware update (Firmware Management Protocol or simply FMP) > * variable update > > UpdateCapsule is a runtime services function, but is, at least initially, > provided only before exiting boot services alike other runtime functions. > This is because modifying storage which may be shared with OS must be > carefully designed and there is no general assumption to do that as in > the case of [Get/]SetVariable. > Instead, any capsule can be handed over to the firmware as a file on > a specific file system. In other words, we only support "capsules on disk" > for now. > > Regarding firmware update, most of functionality is provided by FMP > driver and it will be by nature system/platform-specific. So you can and > should implement FMP drivers based on your system requirements. > In this patch series, only a simple FMP driver based on FIT image for > a single region is supported. (So it is "for reference only") > See more details in "efi_loader: capsule: add simple firmware management > protocol." > > Regarding variable update, the implementation here is based on a draft > proposal[1] by Peter in Boot-arch ML. The specification should be discussed > and finalized first. So the code doesn't fully implement Peter's idea. > > [1] > https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > Patch structure > =============== > Patch#1-#4: preparatory patches > Patch#5-#11: main part of implementation > Patch#12-#14: utilities and tests > > With the changes that I suggested in a couple of patches, I am able to test the capsule-on-disk update of the u-boot firmware image on the qemu arm64 platform. I have also tested the capsule update functionality via the 'efidebug capsule update -v <capsule address>' command. Thanks! -sughosh
Heinrich, On Wed, Mar 18, 2020 at 11:04:05AM +0900, AKASHI Takahiro wrote: > Heinrich, > > Thank you for your quick review. > > On Tue, Mar 17, 2020 at 08:49:12AM +0100, Heinrich Schuchardt wrote: > > On 3/17/20 3:12 AM, AKASHI Takahiro wrote: > > > Summary > > > ======= > > > 'UpdateCapsule' is one of runtime services defined in UEFI specification > > > and its aim is to allow a caller to pass information to the firmware. > > > This is mostly used to update firmware binary on devices by instructions > > > from OS. > > > > > > In this patch series, all the related definitions and structures are given > > > as UEFI specification describes and basic framework for capsule support is > > > implemented. Currently supported types of capsule are > > > * firmware update (Firmware Management Protocol or simply FMP) > > > * variable update > > > > > > UpdateCapsule is a runtime services function, but is, at least initially, > > > provided only before exiting boot services alike other runtime functions. > > > This is because modifying storage which may be shared with OS must be > > > carefully designed and there is no general assumption to do that as in > > > the case of [Get/]SetVariable. > > > Instead, any capsule can be handed over to the firmware as a file on > > > a specific file system. In other words, we only support "capsules on disk" > > > for now. > > > > > > Regarding firmware update, most of functionality is provided by FMP > > > driver and it will be by nature system/platform-specific. So you can and > > > should implement FMP drivers based on your system requirements. > > > In this patch series, only a simple FMP driver based on FIT image for > > > a single region is supported. (So it is "for reference only") > > > See more details in "efi_loader: capsule: add simple firmware management > > > protocol." > > > > > > Regarding variable update, the implementation here is based on a draft > > > proposal[1] by Peter in Boot-arch ML. The specification should be discussed > > > and finalized first. So the code doesn't fully implement Peter's idea. > > > > > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > > > I do not like the idea of exposing variables as a configuration table as > > operating system users may start doing strange things like accessing > > variables via the configuration table. Why not keep the pointer to the > > internal storage of variable hidden in your runtime code and expose the > > runtime services defined in the UEFI spec? > > > > Please, elaborate on the benefit of your approach. > > I have already commented on your reply to my patch#11. > > Rather, my aim of this patch is to discuss the following points: Do you have any comments on them? > > > Issues > > > ====== > > > * Timing of executing capsules-on-disk > > > Currently, processing a capsule is triggered only as part of > > > UEFI subsystem initialization. This means that, for example, > > > firmware update, may not take place at system booting time and > > > will potentially be delayed until a first call of any UEFI functions. We, Linaro, internally discussed this issue and agreed that the current capsule handling should be split from UEFI initialization code, efi_init_obj_list(), and that both of them should be called respectively as early as possible in U-Boot initialization time, probably in board_init_r(). We may restrict this behavior only if CAPSULE is enabled. > > and > > > > TODO's > > > ====== > > > (May or may not be addressed in future versions of this series.) > > > * capsule authentication > > > * capsule dependency (dependency expression instruction set) > > > * loading drivers in a capsule > > > * handling RESET flag in a capsule and QeuryCapsuleCaps > > > * full semantics of ESRT (EFI System Resource Table) > > > * enabling capsule API at runtime > > > * json capsule > > > * recovery from update failure > > What functionality should be initially included in my first implementation > for capsule support. Do you have any primary requirements so that you will be happy to accept my patch series? -Takahiro Akashi > FYI, Sughosh is going to work on > * capsule authentication > * recovery from update failure (or at least, A/B partition) > in the coming months. > > Thanks, > -Takahiro Akashi > > > > > > > > > > > > Changes > > > ======= > > > Initial release as RFC (March 17, 2020) > > > > > > AKASHI Takahiro (14): > > > efi_loader: define OsIndicationsSupported flags > > > efi_loader: define System Resource Table macros > > > efi_loader: export a couple of protocol related functions > > > efi_loader: correct a definition of struct efi_capsule_header > > > efi_loader: define UpdateCapsule api > > > efi_loader: capsule: add capsule_on_disk support > > > efi_loader: capsule: add memory range capsule definitions > > > efi_loader: capsule: support firmware update > > > efi_loader: add simple firmware management protocol for FIT image > > > efi_loader: capsule: support variable update > > > efi_loader: variable: export variables table for runtime access > > > cmd: add "efidebug capsule" command > > > tools: add mkeficapsule command for UEFI capsule update test > > > test/py: add efi capsule test > > > > > > cmd/efidebug.c | 234 +++++ > > > include/efi_api.h | 214 ++++- > > > include/efi_loader.h | 53 ++ > > > lib/efi_loader/Kconfig | 65 ++ > > > lib/efi_loader/Makefile | 2 + > > > lib/efi_loader/efi_boottime.c | 29 +- > > > lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++ > > > lib/efi_loader/efi_firmware.c | 191 ++++ > > > lib/efi_loader/efi_runtime.c | 104 ++- > > > lib/efi_loader/efi_setup.c | 41 +- > > > lib/efi_loader/efi_variable.c | 109 +++ > > > test/py/tests/test_efi_capsule/conftest.py | 109 +++ > > > test/py/tests/test_efi_capsule/defs.py | 21 + > > > .../test_efi_capsule/test_capsule_firmware.py | 102 +++ > > > .../test_efi_capsule/test_capsule_variable.py | 141 +++ > > > test/py/tests/test_efi_capsule/uboot_env.its | 25 + > > > tools/Makefile | 3 + > > > tools/mkeficapsule.c | 501 ++++++++++ > > > 18 files changed, 2744 insertions(+), 60 deletions(-) > > > create mode 100644 lib/efi_loader/efi_capsule.c > > > create mode 100644 lib/efi_loader/efi_firmware.c > > > create mode 100644 test/py/tests/test_efi_capsule/conftest.py > > > create mode 100644 test/py/tests/test_efi_capsule/defs.py > > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py > > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py > > > create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its > > > create mode 100644 tools/mkeficapsule.c > > > > >
Heinrich, On Tue, Mar 31, 2020 at 01:36:19PM +0900, AKASHI Takahiro wrote: > Heinrich, > > On Wed, Mar 18, 2020 at 11:04:05AM +0900, AKASHI Takahiro wrote: > > Heinrich, > > > > Thank you for your quick review. > > > > On Tue, Mar 17, 2020 at 08:49:12AM +0100, Heinrich Schuchardt wrote: > > > On 3/17/20 3:12 AM, AKASHI Takahiro wrote: > > > > Summary > > > > ======= > > > > 'UpdateCapsule' is one of runtime services defined in UEFI specification > > > > and its aim is to allow a caller to pass information to the firmware. > > > > This is mostly used to update firmware binary on devices by instructions > > > > from OS. > > > > > > > > In this patch series, all the related definitions and structures are given > > > > as UEFI specification describes and basic framework for capsule support is > > > > implemented. Currently supported types of capsule are > > > > * firmware update (Firmware Management Protocol or simply FMP) > > > > * variable update > > > > > > > > UpdateCapsule is a runtime services function, but is, at least initially, > > > > provided only before exiting boot services alike other runtime functions. > > > > This is because modifying storage which may be shared with OS must be > > > > carefully designed and there is no general assumption to do that as in > > > > the case of [Get/]SetVariable. > > > > Instead, any capsule can be handed over to the firmware as a file on > > > > a specific file system. In other words, we only support "capsules on disk" > > > > for now. > > > > > > > > Regarding firmware update, most of functionality is provided by FMP > > > > driver and it will be by nature system/platform-specific. So you can and > > > > should implement FMP drivers based on your system requirements. > > > > In this patch series, only a simple FMP driver based on FIT image for > > > > a single region is supported. (So it is "for reference only") > > > > See more details in "efi_loader: capsule: add simple firmware management > > > > protocol." > > > > > > > > Regarding variable update, the implementation here is based on a draft > > > > proposal[1] by Peter in Boot-arch ML. The specification should be discussed > > > > and finalized first. So the code doesn't fully implement Peter's idea. > > > > > > > > [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html > > > > > > I do not like the idea of exposing variables as a configuration table as > > > operating system users may start doing strange things like accessing > > > variables via the configuration table. Why not keep the pointer to the > > > internal storage of variable hidden in your runtime code and expose the > > > runtime services defined in the UEFI spec? > > > > > > Please, elaborate on the benefit of your approach. > > > > I have already commented on your reply to my patch#11. > > > > Rather, my aim of this patch is to discuss the following points: > > Do you have any comments on them? No comment? Do you mind my posting v1 without addressing any TODO list below? (I'm going to add some enhancement to address "timing of executing capsule" issue in v1.) Thanks, -Takahiro Akashi > > > > Issues > > > > ====== > > > > * Timing of executing capsules-on-disk > > > > Currently, processing a capsule is triggered only as part of > > > > UEFI subsystem initialization. This means that, for example, > > > > firmware update, may not take place at system booting time and > > > > will potentially be delayed until a first call of any UEFI functions. > > We, Linaro, internally discussed this issue and agreed that the current > capsule handling should be split from UEFI initialization code, > efi_init_obj_list(), and that both of them should be called respectively > as early as possible in U-Boot initialization time, probably in board_init_r(). > > We may restrict this behavior only if CAPSULE is enabled. > > > > > and > > > > > > TODO's > > > > ====== > > > > (May or may not be addressed in future versions of this series.) > > > > * capsule authentication > > > > * capsule dependency (dependency expression instruction set) > > > > * loading drivers in a capsule > > > > * handling RESET flag in a capsule and QeuryCapsuleCaps > > > > * full semantics of ESRT (EFI System Resource Table) > > > > * enabling capsule API at runtime > > > > * json capsule > > > > * recovery from update failure > > > > What functionality should be initially included in my first implementation > > for capsule support. > > Do you have any primary requirements so that you will be happy to > accept my patch series? > > -Takahiro Akashi > > > > FYI, Sughosh is going to work on > > * capsule authentication > > * recovery from update failure (or at least, A/B partition) > > in the coming months. > > > > Thanks, > > -Takahiro Akashi > > > > > > > > > > > > > > > > > > Changes > > > > ======= > > > > Initial release as RFC (March 17, 2020) > > > > > > > > AKASHI Takahiro (14): > > > > efi_loader: define OsIndicationsSupported flags > > > > efi_loader: define System Resource Table macros > > > > efi_loader: export a couple of protocol related functions > > > > efi_loader: correct a definition of struct efi_capsule_header > > > > efi_loader: define UpdateCapsule api > > > > efi_loader: capsule: add capsule_on_disk support > > > > efi_loader: capsule: add memory range capsule definitions > > > > efi_loader: capsule: support firmware update > > > > efi_loader: add simple firmware management protocol for FIT image > > > > efi_loader: capsule: support variable update > > > > efi_loader: variable: export variables table for runtime access > > > > cmd: add "efidebug capsule" command > > > > tools: add mkeficapsule command for UEFI capsule update test > > > > test/py: add efi capsule test > > > > > > > > cmd/efidebug.c | 234 +++++ > > > > include/efi_api.h | 214 ++++- > > > > include/efi_loader.h | 53 ++ > > > > lib/efi_loader/Kconfig | 65 ++ > > > > lib/efi_loader/Makefile | 2 + > > > > lib/efi_loader/efi_boottime.c | 29 +- > > > > lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++ > > > > lib/efi_loader/efi_firmware.c | 191 ++++ > > > > lib/efi_loader/efi_runtime.c | 104 ++- > > > > lib/efi_loader/efi_setup.c | 41 +- > > > > lib/efi_loader/efi_variable.c | 109 +++ > > > > test/py/tests/test_efi_capsule/conftest.py | 109 +++ > > > > test/py/tests/test_efi_capsule/defs.py | 21 + > > > > .../test_efi_capsule/test_capsule_firmware.py | 102 +++ > > > > .../test_efi_capsule/test_capsule_variable.py | 141 +++ > > > > test/py/tests/test_efi_capsule/uboot_env.its | 25 + > > > > tools/Makefile | 3 + > > > > tools/mkeficapsule.c | 501 ++++++++++ > > > > 18 files changed, 2744 insertions(+), 60 deletions(-) > > > > create mode 100644 lib/efi_loader/efi_capsule.c > > > > create mode 100644 lib/efi_loader/efi_firmware.c > > > > create mode 100644 test/py/tests/test_efi_capsule/conftest.py > > > > create mode 100644 test/py/tests/test_efi_capsule/defs.py > > > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py > > > > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py > > > > create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its > > > > create mode 100644 tools/mkeficapsule.c > > > > > > >