[PATCH v8 00/18] efi_loader: add capsule update support

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

On Mon, Nov 16, 2020 at 11:10:12AM -0500, Tom Rini wrote:
> 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
> > > > ===========
> > > > 1. You can create a capsule file with the following host command:
> > > >
> > > >   $ mkeficapsule [--fit <fit image> | --raw <raw image>] <output file>
> > > >
> > > > 2. Put the file under:
> > > >
> > > >   /EFI/UpdateCapsule of UEFI system partition
> > > >
> > > > 3. Specify firmware storage to be updated in "dfu_alt_info" variable
> > > >    (Please follow README.dfu for details.)
> > > >
> > > >   ==> env set dfu_alt_info '...'
> > > >
> > > > 4. 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

We can get a free account for Azure, but yet it requires us to give
our credit card information to Azure. I don't want to accept it.
So I believe requiring Azure test results is just inappropriate.

-Takahiro Akashi


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