Akashi-san, On Wed, Mar 11, 2020 at 03:56:53PM +0900, AKASHI Takahiro wrote: > Regarding capsule update, > > On Tue, Mar 10, 2020 at 09:45:28PM +0100, Francois Ozog wrote: > > >
[...] > > > Directory \EFI\UpdateCapsule - A file placed on this directory on the > > > boot device is considered a capsule. This is much easier to implement. > > > > > > Essentially you could also use BootNext to run any binary for updating. > > > > > > I suggest to go for the directory method of capsule updating. > > > > > That’s the goal for the moment. Yet a whole bunch new to be clarified. We > > are working on a document to be commented. > > As some of you may know, I'm going to submit a RFC patch series for UEFI > capsule support on U-Boot in a week or so (maybe). With this patch, > we will support "Capsule-on-Disk" only (but without authentication > implemented). > > One of my concerns here is about "variable update via a capsule" as > an alternative of "SetVariable at runtime," where values to be set > for variables will be exported as a capsule file and all the updates > will take place after rebooting. This is very useful on systems > where SetVariable is not available at runtime for some reasons. > Some idea has been proposed by Peter[1], but the discussion has been > stalled for a long time. > > [1] > https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html So the way i understand it we got two paths we can follow: 1. Use a configuration table for those variables 2. Shadow the variables on a kernel accessible memory in order to have access to them How is this going to affect the existing tools (i.e efivar --list) for reading variables? Regards /Ilias _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
