On 3/19/20 11:33 AM, Ilias Apalodimas wrote: > On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote: >> On 3/19/20 10:33 AM, Ilias Apalodimas wrote: >>> 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 >> >> It is unclear to me why it would be advantageous to follow any of these >> ideas compared to using GetVariable and SetVariable and letting the >> firmware runtime manage the memory area. > > This describes some of the reasoning behind the idea. > https://lists.linaro.org/pipermail/boot-architecture/2018-September/000841.html > The short version is that we should be able to provide GetVariable() even if > SetVariable() is not implemented.
Thanks for the link. Unfortunately it does not answer my question. Why do we need a configuration table and cannot use GetVariable() and SetVariable() for abstracting the memory store? For telling the kernel that the firmware cannot persist non-volatile variables on its own you could use a variable or a bit in the RuntimeServicesSupported variable. Best regards Heinrich _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
