[PATCH v9 00/11] efi_loader: add capsule update support

[Tom Rini]

On Wed, Nov 25, 2020 at 03:07:08AM +0100, Heinrich Schuchardt wrote:
> On 11/25/20 12:32 AM, Tom Rini wrote:
> > On Tue, Nov 24, 2020 at 10:37:10PM +0100, Heinrich Schuchardt wrote:
> > > On 11/17/20 1:27 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-#6: main part of implementation
> > > > Patch#7-#8: utilities
> > > > Patch#9-#10: pytests
> > > > Patch#11: 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.
> > > > * In Travis CI, all tests skipped (or 'S', but it's not a failure, 'F')
> > > >     because "virt-make-fs" cannot be executed.
> > > > 
> > > > 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.
> > > >       => See patch#5 for my proposal
> > > > * A bunch of warnings like
> > > >       WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
> > > >       where possible
> > > >     I don't think that fixing those improves anything.
> > > > * Add a document in uefi.rst
> > > 
> > > What is your status for the test running on Gitlab CI?
> > > 
> > > I still see
> > > test/py/tests/test_efi_capsule/test_capsule_firmware.py sss [  0%]
> > > in
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/182120
> > 
> > That means that Azure, Travis and GitLab are just not going to run any
> > of the capsule tests.  If they can be run manually, that's apparently as
> > good as we're going to get to start with.
> > 
> > That's not the ideal situation, certainly.  But you haven't answered his
> > question about if you agree with, or not, what I say about some
> > try/catch method of using sudo or make-virt-fs, whatever the running
> > instance supports.  That's likely the blocker to further progress on CI
> > and these tests running.  Thanks.
> > 
> 
> What the series does is adding another wrapper around FIT images.
> 
> The series has build errors. So nothing to be merged now.

Again?  I thought v8 at least passed all CI.

> 
> We have been talking about CI tests for the series since September at
> least and I have not seen any progress.
> 
> This reminds me of the FAT tests that are skipped on CI.

Well, the outstanding question about making the tests run in CI has been
blocked on your feedback.  I believe that in order for any of these (or
the FAT ones) to run in CI, sudo has to work, and possibly something
else too.  I say we need fall-back to make-virt-fs rather than it being
an only option.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201124/36e3e8ea/attachment.sig>