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 > > > > >
