On Mon, Nov 16, 2020 at 09:37:23AM +0900, AKASHI Takahiro wrote:
Heinrich,
On Fri, Nov 13, 2020 at 08:18:58AM +0100, Heinrich Schuchardt wrote:
On 11/13/20 5:14 AM, AKASHI Takahiro wrote:
Summary
'UpdateCapsule' is one of runtime services defined in UEFI specification and its aim is to allow a caller (OS) to pass information to the firmware, i.e. U-Boot. This is mostly used to update firmware binary on devices by instructions from OS.
While 'UpdateCapsule' is a runtime services function, it is, at least initially, supported only before exiting boot services alike other runtime functions, [Get/]SetVariable. This is because modifying storage which may be shared with OS must be carefully designed and there is no general assumption that we can do it.
Therefore, we practically support only "capsule on disk"; any capsule can be handed over to UEFI subsystem as a file on a specific file system.
In this patch series, all the related definitions and structures are given as UEFI specification describes, and basic framework for capsule support is provided. Currently supported is
- firmware update (Firmware Management Protocol or simply FMP)
Most of functionality of firmware update is provided by FMP driver and it can be, by nature, system/platform-specific. So you can and should implement your own FMP driver(s) based on your system requirements. Under the current implementation, we provide two basic but generic drivers with two formats:
- FIT image format (as used in TFTP update and dfu)
- raw image format
It's totally up to users which one, or both, should be used on users' system depending on user requirements.
Quick usage
- You can create a capsule file with the following host command:
$ mkeficapsule [--fit <fit image> | --raw <raw image>] <output file>
- Put the file under:
/EFI/UpdateCapsule of UEFI system partition
- Specify firmware storage to be updated in "dfu_alt_info" variable (Please follow README.dfu for details.)
==> env set dfu_alt_info '...'
- After setting up UEFI's OsIndications variable, reboot U-Boot:
OsIndications <= EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED
Patch structure
Patch#1-#4,#12: preparatory patches Patch#5-#11,#13: main part of implementation Patch#14-#15: utilities Patch#16-#17: pytests Patch#18: for sandbox test
[1] https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/capsule
Prerequisite patches
None
Test
- passed all the pytests which are included in this patch series on sandbox build locally.
- skipped (or 'S', but it's not a failure, 'F') in Travis CI because "virt-make-fs" cannot be executed.
Dear Takahiro,
please, rebase your series on origin/master. A prior version of the first patches is already applied.
You can simply pick up and apply non-merged patches without problems except a function prototype change of efi_create_indexed_name() you made, which is not trivial to me.
But anyway, I will post a clean patch set soon.
Testing on Gitlab CI, Travis CI, Amazon CI must be addressed for merging the remaining patches.
Where can we find the results? I don't think there is no official information on those CI's.
If you submit a pull request against https://github.com/u-boot/u-boot Azure will run automatically and show the results. We don't have anything similar setup for GitLab, but since it uses the same Docker images as Azure, so long as the syntax is right (and there are linters if you're unsure of a change), it would be expected to work too.