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? > Don't write a spec to bend another spec that way leads to chaos. Well, EBBR is such a spec. The chaos is already there and EBBR attempts to apply some amount of order to the chaos. Rob _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
