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

[Heinrich Schuchardt]

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.

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.

Best regards

Heinrich