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
signature.asc
Description: PGP signature
