Next EBBR meeting is in a few minutes. Here are the agenda items I've
got for today:
- Issue review
- Set/GetVariable() behaviour when non-volatile doesn't work at runtime
- v0.6 release
- Review distribution list
- Any other business
As always, this Google doc will be used to capture notes. Please help
filling it in. You may need to request edit access if I haven't already
added you.
https://docs.google.com/document/d/1RdlFp5SIrvjcVOGoGEFVYDsqTqFBJHugbBMV5Mu…
---
Every Thursday at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST
(following UTC/BST daylight savings time shifts)
Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
Phone +44 2033215213,, 4664465#
Find a local number:
https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
Conference ID: 4664465
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello all,
i wanna know how much time will ATF take to initialize board and jump to
U-Boot or Bootloader ?
and is there any document to help me customize and optimize ATF stages to
boot in less time ?
Thanks,
--
*This e-mail message is intended for the internal use of the intended
recipient(s) only.
The information contained herein is
confidential/privileged. Its disclosure or reproduction is strictly
prohibited.
If you are not the intended recipient, please inform the sender
immediately, do not disclose it internally or to third parties and destroy
it.*
On Mon, 16 Jul 2018 at 18:11, Daniel Thompson <daniel.thompson(a)linaro.org>
wrote:
> Hi Folks
>
> Sorry if you have already seen this but for those that didn't, last Friday
> Grant pushed out version 0.6 of EBBR. Details below but the summary is
> that it is time for feedback.
>
> > This v0.6 release of EBBR is a pre-release document. The contents are
> > not final. The purpose of this release is to raise awareness of the EBBR
>
> > project, and to solicit feedback on the current draft. Please do read
> > and provide comments on the boot-architecture(a)lists.linaro.org mailing
> list.
>
>
We had a training session at HKG18 looking at best practices for
automating devices and there are aspects of any boot architecture which
will make or break automation. Has any one considered adding to the EBBR
based on the objectives of supporting automation of compliant devices?
http://connect.linaro.org/resource/hkg18/hkg18-tr10/
That session was based on this white paper:
https://collaborate.linaro.org/display/CTT/Automation+and+hardware+design -
but that URL is still restricted to people with a login on collaborate, so
I blogged the content here:
https://linux.codehelp.co.uk/automation-and-risk.html (It is a long read)
There is a lot of interest in automating testing of all parts of the boot
process on a range of boards. Linaro has a lot of experience of automating
a range of devices and ARM is building a similar data set using the same
tools.
Principle elements would be:
* Reliability -
* all identifiers are persistent across updates of the software, reboots
etc.
* Reliable reporting of errors.
* Outputting sensible, unique, strings when performing a CPU reset
* Uniqueness - all identifiers are unique and exposed to other parts of
the boot architecture, e.g. NIC needs to be visible to bootloaders like
Grub.
* Scalability - avoid need for customised hardware to automate the device
* Deployment - consider how to deploy new software to the device under
automation.
EBBR talks about UEFI Reset but doesn't require that a reset is
identifiable when it happens in automation - a simple string like the
U-Boot support for "Resetting CPU ..." is enough for the automation to
detect that the system we tried to deploy has not booted and what is about
to happen is that something else may get booted in it's place.
Runtime variable access plays into the need to ensure that the network PHY
is exposed to UEFI applications (like grubaarch64.efi)
Partitioning is a frequent problem when AOSP requires multiple partitions
and OE testing requires fewer. Devices need to support switching partition
tables without needing a full recovery deployment or the deployment of new
bits of firmware.
>
> Daniel.
>
> ---------- Forwarded message ---------
> From: Grant Likely <grant.likely(a)arm.com>
> Date: Fri, 13 Jul 2018 at 23:34
> Subject: [Arm.ebbr-discuss] EBBR v0.6 Release Announcement
> To: arm.ebbr-discuss <arm.ebbr-discuss(a)arm.com>,
> boot-architecture(a)lists.linaro.org <boot-architecture(a)lists.linaro.org>,
> Linux ARM <linux-arm-kernel(a)lists.infradead.org>, uboot <
> u-boot(a)lists.denx.de>, <devicetree-spec(a)vger.kernel.org>
>
>
> I'm pleased to announce the release of version 0.6 of the Embedded Base
> Boot Requirements (EBBR) specification.
>
> https://github.com/ARM-software/ebbr/releases/tag/v0.6
>
> EBBR is a new specification defining a standard boot environment
> suitable for full feature operating systems running on embedded
> platforms...
>
> Well, it will when it's finished.
>
> It is well know that firmware for embedded systems is a fragmented area
> with each platform behaving in subtly incompatible ways. It is also
> completely different from the firmware interface used on general purpose
> desktops and servers. For OSes, this makes supporting more than a
> handful of platforms a nearly impossible affair. EBBR aims to solve this
> problem by defining a standard boot interface that can easily be
> implemented using either U-Boot or Tianocore, and is based on the same
> UEFI specification used on general purpose computers.
>
> By adopting EBBR, platform vendors can reduce the amount of engineering
> effort required to support their products and make them easier to use.
> As EBBR is being developed in conjunction with the U-Boot, Tianocore,
> and Trusted Firmware projects, most of the functionality required is
> already implemented and ready to be used if one uses an up to date
> release of U-Boot or Tianocore.
>
> For OS vendors, this makes far easier to support embedded platforms
> because they don't need to tailor the boot process for each platform.
> The same boot infrastructure works on both desktop/servers and on EBBR
> compliant embedded platforms.
>
> And finally, for end users, working with an EBBR compliant platform
> means they can boot the OS of their choice without needing to learn low
> level details of the platform firmware.
>
> This v0.6 release of EBBR is a pre-release document. The contents are
> not final. The purpose of this release is to raise awareness of the EBBR
> project, and to solicit feedback on the current draft. Please do read
> and provide comments on the boot-architecture(a)lists.linaro.org mailing
> list.
>
> The plan is to release v1.0 before the end of the 2018.
>
> Thanks to the EBBR committee members who contributed to this release:
>
> Andreas Färber (SUSE)
> Alex Graf (SUSE)
> Ryan Harkin (Linaro)
> Rob Herring (Linaro)
> Udit Kumar (NXP)
> Leif Lindholm (Linaro)
> Bill Mills (TI)
> Peter Robinson (Red Hat)
> Tom Rini (Konsulko)
> Daniel Thompson (Linaro)
> Dong Wei (Arm)
>
> Sincerely,
> Grant Likely, EBBR committee co-chair
>
>
> Note on U-Boot implementations
> ------------------------------
> It is expected that EBBR compliant can be achieved by using a recent
> version of U-Boot with the appropriate configuration options. An
> implementers guide for U-Boot will be written before EBBR v1.0 is released.
>
> There is also work ongoing to get the UEFI Self Certification Test
> running on U-Boot. Once working, this will be a tool for vendors to test
> their platforms for EBBR compliance.
>
> FAQ
> ---
> 1. Does EBBR define a new interface?
>
> No. EBBR builds on the existing UEFI spec by requiring a specific
> subset that can be implemented today using U-Boot, and either Devicetree
> or ACPI.
>
> 2. Does EBBR require Devicetree? ACPI?
>
> EBBR allows platforms to provide either ACPI or Devicetree. Linux
> supports both system description languages equally well, and Devicetree
> is in common use on embedded platforms. As long as the platform supplies
> a system description that can boot a mainline operating system.
>
> EBBR does not attempt to define a common base standard for
> Devicetree platforms because of the wide variety of platforms needed to
> be supported. The one assumption EBBR does make is that the target
> operating system already has support for the SoC on the platform.
>
> 3. Is EBBR only for U-Boot and Linux embedded systems?
>
> No. While U-Boot+Linux platforms were certainly the primary audience
> when EBBR was first conceived, the spec is very purposefully written to
> be OS-independent. EBBR requires specific interfaces, but those
> interface can be implemented by any firmware project.
>
> We would absolutely like to have review, feedback and contributions
> from non-Linux, non-U-Boot users.
>
> 4. Can I contribute to the EBBR specification?
>
> Yes. The EBBR source document is on GitHub, and we use the
> boot-architecture(a)lists.linaro.org mailing list.
>
> https://github.com/ARM-Software/ebbr
>
>
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
I'm pleased to announce the release of version 0.6 of the Embedded Base
Boot Requirements (EBBR) specification.
https://github.com/ARM-software/ebbr/releases/tag/v0.6
EBBR is a new specification defining a standard boot environment
suitable for full feature operating systems running on embedded platforms...
Well, it will when it's finished.
It is well know that firmware for embedded systems is a fragmented area
with each platform behaving in subtly incompatible ways. It is also
completely different from the firmware interface used on general purpose
desktops and servers. For OSes, this makes supporting more than a
handful of platforms a nearly impossible affair. EBBR aims to solve this
problem by defining a standard boot interface that can easily be
implemented using either U-Boot or Tianocore, and is based on the same
UEFI specification used on general purpose computers.
By adopting EBBR, platform vendors can reduce the amount of engineering
effort required to support their products and make them easier to use.
As EBBR is being developed in conjunction with the U-Boot, Tianocore,
and Trusted Firmware projects, most of the functionality required is
already implemented and ready to be used if one uses an up to date
release of U-Boot or Tianocore.
For OS vendors, this makes far easier to support embedded platforms
because they don't need to tailor the boot process for each platform.
The same boot infrastructure works on both desktop/servers and on EBBR
compliant embedded platforms.
And finally, for end users, working with an EBBR compliant platform
means they can boot the OS of their choice without needing to learn low
level details of the platform firmware.
This v0.6 release of EBBR is a pre-release document. The contents are
not final. The purpose of this release is to raise awareness of the EBBR
project, and to solicit feedback on the current draft. Please do read
and provide comments on the boot-architecture(a)lists.linaro.org mailing list.
The plan is to release v1.0 before the end of the 2018.
Thanks to the EBBR committee members who contributed to this release:
Andreas Färber (SUSE)
Alex Graf (SUSE)
Ryan Harkin (Linaro)
Rob Herring (Linaro)
Udit Kumar (NXP)
Leif Lindholm (Linaro)
Bill Mills (TI)
Peter Robinson (Red Hat)
Tom Rini (Konsulko)
Daniel Thompson (Linaro)
Dong Wei (Arm)
Sincerely,
Grant Likely, EBBR committee co-chair
Note on U-Boot implementations
------------------------------
It is expected that EBBR compliant can be achieved by using a recent
version of U-Boot with the appropriate configuration options. An
implementers guide for U-Boot will be written before EBBR v1.0 is released.
There is also work ongoing to get the UEFI Self Certification Test
running on U-Boot. Once working, this will be a tool for vendors to test
their platforms for EBBR compliance.
FAQ
---
1. Does EBBR define a new interface?
No. EBBR builds on the existing UEFI spec by requiring a specific
subset that can be implemented today using U-Boot, and either Devicetree
or ACPI.
2. Does EBBR require Devicetree? ACPI?
EBBR allows platforms to provide either ACPI or Devicetree. Linux
supports both system description languages equally well, and Devicetree
is in common use on embedded platforms. As long as the platform supplies
a system description that can boot a mainline operating system.
EBBR does not attempt to define a common base standard for
Devicetree platforms because of the wide variety of platforms needed to
be supported. The one assumption EBBR does make is that the target
operating system already has support for the SoC on the platform.
3. Is EBBR only for U-Boot and Linux embedded systems?
No. While U-Boot+Linux platforms were certainly the primary audience
when EBBR was first conceived, the spec is very purposefully written to
be OS-independent. EBBR requires specific interfaces, but those
interface can be implemented by any firmware project.
We would absolutely like to have review, feedback and contributions
from non-Linux, non-U-Boot users.
4. Can I contribute to the EBBR specification?
Yes. The EBBR source document is on GitHub, and we use the
boot-architecture(a)lists.linaro.org mailing list.
https://github.com/ARM-Software/ebbr
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
I've already pushed these out to GitHub, but posting to the mailing list
for completeness.
Grant Likely (5):
trivial: fix broken internal reference
trivial: Put SPDX tag into all source files
trivial: Fix reference to required runtime services section
editorial: tighten up uefi runtime services language
editorial: Drop value statement between ACPI & DT
source/appendix-a-uefi-features.rst | 3 +++
source/chapter1-about.rst | 4 ++--
source/chapter2-uefi.rst | 12 ++++++++----
source/chapter3-secureworld.rst | 2 ++
source/chapter4-firmware-media.rst | 2 ++
source/references.rst | 2 ++
6 files changed, 19 insertions(+), 6 deletions(-)
--
2.13.0
We don't have agreement yet on what the behaviour should be if
non-volatile variables cannot be updated or created at runtime. Add a
paragraph discussing the factors involved and asking for feedback.
Cc: Dong Wei <dong.wei(a)arm.com>
Cc: Alexander Graf <agraf(a)suse.de>
Cc: Peter Robinson <pbrobinson(a)redhat.com>
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 72 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 7b6843e..10448fd 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -197,13 +197,69 @@ command:
Operating Systems calls to reset the system will go via Runtime Services
and not directly to PSCI.
-Set Variable
-------------
+Runtime Variable Access
+-----------------------
+
+.. todo:
+
+ There are many platforms where it is difficult to support SetVariable() for
+ non-volatile variables because the firmware cannot access storage after
+ ExitBootServices() is called.
+ e.g., If firmware accesses an eMMC device directly at runtime, it will
+ collide with transactions initiated by the OS.
+ Neither U-Boot nor Tianocore have a solution for accessing shared media for
+ variable updates. [#OPTEESupplicant]_
+
+ In these platforms SetVariable() calls with the EFI_VARIABLE_NON_VOLATILE
+ attribute set will work in boot services, but will fail in runtime services.
+ The [UEFI]_ specification doesn't address what to do in this situation.
+ We need feedback on options before writing this section of EBBR, or making a
+ proposal to modify UEFI.
+
+ We need a solution that communicates to the OS that non-volatile variable
+ updates are not supported at runtime, and that defines the behaviour when
+ SetVariable() is called with the EFI_VARIABLE_NON_VOLATILE attribute.
+
+ Presumably, the solution will require SetVariable() to return
+ EFI_INVALID_PARAMETER if called with the EFI_VARIABLE_NON_VOLATILE
+ attribute, but beyond that there are a number of options:
+
+ #. Clear EFI_VARIABLE_NON_VOLATILE from all variables at ExitBootServices()
+
+ If the platform is incapable of updating non-volatile variables from Runtime
+ Services then it must clear the EFI_VARIABLE_NON_VOLATILE attribute from all
+ non-volatile variables when ExitBootServices() is called.
+
+ An OS can discover that non-volatile variables cannot be updated at
+ runtime by noticing that the NON_VOLATILE attribute is not set.
+
+ #. Clear all variables at ExitBootServices()
+
+ If the platform is incapable of updating non-volatile variables from Runtime
+ Services then it will clear all variables and return EFI_INVALID_PARAMETER
+ on all calls to SetVariable().
+
+ SUSE in particular currently uses this behaviour to decide whether or not
+ to treat the ESP as removable media.
+
+ #. Advertise that SetVariable() doesn't work at runtime with another variable
+
+ Platforms can check another variable to determine if they have this quirk,
+ perhaps by adding a new BootOptionSupport flag.
+
+ This is not a complete list, and other options can still be proposed. We're
+ looking for feedback on what would be most faithful to the UEFI spec, and
+ would work for the OS distributions before filling out this section of the
+ specification.
+
+ Comments can be sent to the boot-architecture(a)lists.linaro.org mailing list.
-Non-volatile UEFI variables must persist across reset, and emulated variables
-in RAM are not permitted.
-The UEFI Runtime Services must be able to update the variables directly without
-the aid of the Operating System.
+.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
+ regarding secure storage.
+ OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
+ storage operations on behalf of OP-TEE.
+ The same solution may be applicable to solving the UEFI non-volatile
+ variable problem, but that approach is also not entirely UEFI compliant
+ because it requires additional OS support to work.
-.. note:: This normally requires dedicated storage for UEFI variables that is
- not directly accessible from the Operating System.
+ https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage…
--
2.13.0
Hi Mark
> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Thursday, July 12, 2018 8:20 PM
> To: Udit Kumar <udit.kumar(a)nxp.com>
> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>; Architecture Mailman List
> <boot-architecture(a)lists.linaro.org>; nd <nd(a)arm.com>; arm.ebbr-discuss
> <arm.ebbr-discuss(a)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 ?
Regards
Udit
On 12/07/2018 15:50, Mark Brown wrote:
> 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.
There is a hard break at least between when variables are used in boot
services, and when they are used at runtime. For Linux, only the UEFI
stub will read the variables at boot time (if at all) before calling
exitBootServices(). By the time the kernel starts, runtime services are
the only way to access variables. There is no caching of variables from
the stub to the kernel as far as I can tell.
As far as the kernel and userspace are concerned, all the variables will
have only ever been volatile.
g.
>
>
>
> _______________________________________________
> Arm.ebbr-discuss mailing list
> Arm.ebbr-discuss(a)arm.com
>
Add details on what to do if the platform is unable to set persistent
variables in runtime services. The idea here is that the GetVariable()
and SetVariable() APIs should continue to work, and the OS can obtain
all the variable settings, but if it cannot be written then the
NON_VOLATILE attribute is cleared so the OS knows that persistence is
not available.
Cc: Dong Wei <dong.wei(a)arm.com>
Cc: Alexander Graf <agraf(a)suse.de>
Cc: Peter Robinson <pbrobinson(a)redhat.com>
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
Alex/Peter: Does this approach work for you? I tried to come up with
something that is faithful to the spec, gives the OS information that
non-volatile variables aren't available, but still have the ability to
query the boot environment.
Dong: Is this an appropriate way to use {Get,Set}Variable()?
Cheers,
g.
---
source/chapter2-uefi.rst | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 7b6843e..57594bc 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -197,13 +197,13 @@ command:
Operating Systems calls to reset the system will go via Runtime Services
and not directly to PSCI.
-Set Variable
-------------
-
-Non-volatile UEFI variables must persist across reset, and emulated variables
-in RAM are not permitted.
-The UEFI Runtime Services must be able to update the variables directly without
-the aid of the Operating System.
+Runtime Variable Access
+-----------------------
-.. note:: This normally requires dedicated storage for UEFI variables that is
- not directly accessible from the Operating System.
+Non-volatile UEFI variables must persist across reset.
+If the platform is incapable of updating non-volatile variables from Runtime
+Services then it must clear the EFI_VARIABLE_NON_VOLATILE attribute from all
+non-volatile variables when ExitBootServices() is called.
+Similarly, if non-volatile variables cannot be set from Runtime Services, then
+SetVariable() must return EFI_INVALID_PARAMETER if the
+EFI_VARIABLE_NON_VOLATILE attribute is set.
--
2.13.0
On 12/07/2018 14:12, Mark Brown wrote:
> On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote:
>> On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote:
>>> Add details on what to do if the platform is unable to set persistent
>>> variables in runtime services. The idea here is that the GetVariable()
>>> and SetVariable() APIs should continue to work, and the OS can obtain
>>> all the variable settings, but if it cannot be written then the
>>> NON_VOLATILE attribute is cleared so the OS knows that persistence is
>>> not available.
>>
>> I'm really struggling to wrap my head around this one.
>>
>> How does incorrectly describing a non-volatile but non-modifiable
>> variable as volatile help the OS do the right thing?
I took a read through section 8.2 of the UEFI spec (Variable services)
before drafting the proposal.
UEFI doesn't define a "read-only" attribute for variables. It has a
non-volatile attribute that says a variable change will be persistant.
My thought here was that clearing the non-volatile flag will indicate
that making a change to that variable will not be saved, and so won't
change the boot order.
If an OS tries to modify a variable without using the exact same
attributes, then SetVariable() will fail. e.g., If the OS tries to set
EFI_VARIABLE_NON_VOLATILE on a veriable without that attribute, then it
will fail with EFI_INVALID_PARAMETER (See description of SetVariable()).
With my proposed text, if the OS tries to set a new variable with the
EFI_VARIABLE_NON_VOLATILE attribute set, then SetVariable() will also
fail. (At runtime only; boot time SetVariable() should work as defined).
An OS can determine in two ways if variable writes are allowed.
1) If the BOOT* varilables don't have the NON_VOLATILE attribute.
2) A EFI_INVALID_PARAMETER return code when attempting to create an
non-volatile variable, or set the NON_VOLATILE attribute.
>> The OS will discover the variable is non-modifiable when it tried to
>> set it. Won't the current proposal mislead standards compliant use of
>> GetVariable()? For example does it it makes standards compliant code
>> *more* likely to call SetVariable() in order to fix up a variable that
>> it thinks was incorrectly set with the NON_VOLATILE attribute.
If it tried to, the call to SetVariable() will fail.
>
> Do any existing implementations change variables from non-volatile to
> volatile?
I don't know. That's part of why this is an RFC. I'm looking for the
most spec-compatible way to deal with platforms that cannot set
non-volatile variables at runtime. The UEFI spec is written with the
assumption that non-volatile variables can be written at runtime. EBBR
encompases platforms that cannot (yet?) do that, so we're in new territory.
There are other approaches that could be taken too.
- Alex said a while back that if UEFI doesn't provide any variables at
runtime, then it assumes non-volatile variables aren't available and
will treat the ESP as if it were removable media.
- The problem with this approach is it is a very blunt hammer. It
eliminates all possible users of variables at runtime.
- We could add an EBBR_FLAGS variable or something similar to indicate
EBBR style quirks, like non-volatile variables cannot be written at runtime.
Let's talk about this in the weekly meeting later today.
g.