On Thu, 12 Jul 2018 at 16:50, Rob Herring <robherri...@gmail.com> wrote: > > On Thu, Jul 12, 2018 at 9:37 AM Graeme Gregory > <graeme.greg...@linaro.org> wrote: > > > > On Thu, 12 Jul 2018 at 16:30, Udit Kumar <udit.ku...@nxp.com> wrote: > > > > > > Hi Mark > > > > > > > -----Original Message----- > > > > From: Mark Brown [mailto:broo...@kernel.org] > > > > Sent: Thursday, July 12, 2018 8:20 PM > > > > To: Udit Kumar <udit.ku...@nxp.com> > > > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Architecture Mailman > > > > List > > > > <boot-architecture@lists.linaro.org>; nd <n...@arm.com>; > > > > arm.ebbr-discuss > > > > <arm.ebbr-disc...@arm.com> > > > > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() > > > > not working > > > > at runtime > > > > > > > > On Thu, Jul 12, 2018 at 02:19:49PM +0000, Udit Kumar wrote: > > > > > > > > > > > Do any existing implementations change variables from non-volatile > > > > > > > to volatile? > > > > > > > > > > The UEFI spec is explicit about which variables are volatile and > > > > > > which are not. > > > > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > > > > seem like a useful approach to me. > > > > > > > > > I believe at boot-time, UEFI specs will be followed for volatile and > > > > > non-volatile > > > > variables. > > > > > Having this in statement EBBR, will help those platform, which cannot > > > > > expose > > > > non-volatile variables at runtime. > > > > > > > > If nothing currently does it the chances that anything will actually > > > > cope well > > > > seem minimal. Like Daniel said it seems more likely to break things - > > > > if the > > > > variables are defined as being non-volatile then the OS is unlikely to > > > > be checking > > > > at runtime if that's the case or not unless it's explicitly written to > > > > work with > > > > EBBR. If an error is generated because a non-volatile variable can't > > > > be set then > > > > that should at least fall into whatever error handling code is there to > > > > cover > > > > normal rutime failures which has some chance of doing something > > > > sensible. > > > > > > Right, > > > There will be some breaks or say diversion from UEFI specs. > > > If we need to follow UEFI specs 'Table 10. Global Variables' on such > > > platform > > > where we cannot write to NV storage at runtime, then in either case > > > 1/ passing OS as no-efi-runtime or > > > 2/ Returning errors/not saving to NV storage > > > is violation of UEFI spec. > > > > > > Which divergence is acceptable ? > > > > > Neither, fix the specs with proper updates to support your use-case. > > > > Or fix your platform to obey the specs you have chosen. > > How do you add firmware storage to existing platforms? > Why can't UEFI spec be updated to handle such reduced functionality platforms if this is important?
Its not like appropriate people are unknown to Linaro. Graeme _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
