I've made the following changes to EBBR to prepare for the v1.0 release. Most of these are editorial. The biggest change is the SetVariable() language which has already been discussed.
Cheers, g.
Instead of masking out GetVariable() when SetVariable() isn't available during runtime services, simplify the requirements without losing the ability to read variables by using the RuntimeServicesSupported variable from UEFI v2.8 (in review for release); Mantis issue 1961.
Peter Jones's earlier patch also specified a Capsule-on-Disk format for updating variables that the OS could store in the ESP. I've not included that specification in this patch as it is logically a separate feature. It may reappear in a separate patch at a later date, or it may get proposed for inclusion in the UEFI spec proper.
Signed-off-by: Grant Likely grant.likely@arm.com Cc: Peter Jones pjones@redhat.com --- source/chapter2-uefi.rst | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 379f0ca..bfce452 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -112,7 +112,7 @@ during both boot services and runtime services. However, it isn't always practical for all EFI_RUNTIME_SERVICES functions to be callable during runtime services due to hardware limitations. If any EFI_RUNTIME_SERVICES functions are only available during boot services -then firmware shall provide the global `RuntimeServicesAvailable` variable to +then firmware shall provide the global `RuntimeServicesSupported` variable to indicate which functions are available during runtime services. Functions that are not available during runtime services shall return EFI_UNSUPPORTED. @@ -201,14 +201,15 @@ variables stored on shared media. [#OPTEESupplicant]_
If a platform does not implement modifying non-volatile variables with SetVariable() after ExitBootServices(), -then it must not provide any variable operations after ExitBootServices(). -Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(), -GetNextVariableName() and SetVariable(). -Firmware shall not emulated non-volatile variables using volatile RAM cache. +then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(), +and must advertise that SetVariable() isn't available during runtime services +via the `RuntimeServicesSupported` variable as defined in UEFI version 2.8. +EFI applications can read `RuntimeServicesSupported` to determine if calls +to SetVariable() need to be performed before calling ExitBootServices().
-.. note:: The behaviour when SetVariable() is not supported during runtime - services is still under discussion and subject to change. - Do not make any firmware implementation decisions based on this text yet. +Even when SetVariable() is not supported during runtime services, firmware +should cache variable names and values in EfiRuntimeServicesData memory so +that GetVariable() and GetNextVeriableName() can behave as specified.
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. @@ -216,5 +217,7 @@ Firmware shall not emulated non-volatile variables using volatile RAM cache. storage operations on behalf of OP-TEE. The same solution may be applicable to solving the UEFI non-volatile variable problem, but it requires additional OS support to work. + Regardless, EBBR compliance does not require SetVariable() support + during runtime services.
https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage....
Clarify the text that firmware may implement as many block device partitioning schemes as it likes. i.e., MTD for raw NAND. However, doing so is outside the scope of this specification and there are no guarantees that the OS will support them.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter2-uefi.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index bfce452..b4c01c1 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -24,7 +24,10 @@ document. Block device partitioning -------------------------
-The system firmware must implement support for MBR, GPT and El Torito partitioning. +The system firmware must implement support for MBR, GPT and El Torito partitioning +on block devices. +System firmware may also implement other partitioning methods as needed by the platform, +but OS support for other methods is outside the scope of this specification.
UEFI System Environment and Configuration =========================================
The working of this section made it read like the spec was specifically for AArch64. Reword slightly so it is clearer that this paragraph applies specifically for AArch64
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter2-uefi.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index b4c01c1..4d813be 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -45,8 +45,8 @@ legitimately be loaded into either EL1 or EL2 on AArch64. AArch64 Exception Levels ------------------------
-UEFI shall execute as 64-bit code in AArch64 model at either EL1 or EL2, -depending on whether or not virtualization is used or supported. +On AArch64 UEFI shall execute as 64-bit code at either EL1 or EL2, +depending on whether or not virtualization is available at OS load time.
UEFI Boot at EL2 ^^^^^^^^^^^^^^^^
Table reference wasn't working. Fix by adding numfig=True and using the correct syntax.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter2-uefi.rst | 2 +- source/conf.py | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 4d813be..a8fe3a3 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -120,7 +120,7 @@ indicate which functions are available during runtime services. Functions that are not available during runtime services shall return EFI_UNSUPPORTED.
-Table :numref:_uefi_runtime_service_requirements details which EFI_RUNTIME_SERVICES +:numref:`uefi_runtime_service_requirements` details which EFI_RUNTIME_SERVICES are required to be implemented during boot services and runtime services.
.. _uefi_runtime_service_requirements: diff --git a/source/conf.py b/source/conf.py index 09287ce..0bfa5e3 100644 --- a/source/conf.py +++ b/source/conf.py @@ -82,6 +82,7 @@ pygments_style = 'sphinx' # If true, `todo` and `todoList` produce output, else they produce nothing. todo_include_todos = True
+numfig = True
# -- Options for HTML output ----------------------------------------------
boot-architecture@lists.linaro.org
-
Grant Likely