From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 29 Oct 2020 10:43:01 -0400 Subject: [PATCH v7 00/17] efi_loader: add capsule update support In-Reply-To: <20201029044757.183262-1-takahiro.akashi@linaro.org> References: <20201029044757.183262-1-takahiro.akashi@linaro.org> Message-ID: <20201029144301.GZ5340@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Oct 29, 2020 at 01:47:40PM +0900, 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 | --raw ] > > 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 > > [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. > > Please note that the capsule pytest itself won't be run in the CI > partly because some specific configuration for sandbox build is > required and partly because there is a problem with virt-make-fs. > See test_efi_capsule_firmware.py. Maybe we need to talk about this differently then. Today, the tests start on CI and then fail to run. That's a problem that needs to be fixed, they must "skip" properly. I would really like to see these tests run with every CI loop. That means doing a "try virt-make-fs, if that fails, try sudo, if that fails, skip". That also means updating some other tests that have logic for virt-make-fs, but it then causes CI to fail rather than try sudo. What I see as the worst case is that we have tests for this feature that are only ever run when someone runs them intentionally, and CI skips them all the time. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: