On 01/06/2020 14:23, Heinrich Schuchardt wrote:
On 6/1/20 11:32 AM, Grant Likely wrote:
[...]
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index f6a5802..c9c0101 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -9,7 +9,7 @@ platforms.
UEFI Version
============
-This document uses version 2.7 of the UEFI specification [UEFI]_.
+This document uses version 2.8 Errata A of the UEFI specification [UEFI]_.
UEFI Compliance.
===============
@@ -86,12 +86,41 @@ tables.
%s/tables\./tables:/
- An Advanced Configuration and Power Interface [ACPI]_ table, or
%s/An/an/
Done
- a Devicetree [DTSPEC]_ system description
-As stated above, EBBR systems must not provide both ACPI and Devicetree
+EBBR systems must not provide both ACPI and Devicetree
tables at the same time.
This sentence is redundant. Above the spec already says:
"Compliant systems are required to provide one, but not both, of the
following tables." Please, remove the redundancy.
The redundancy is intentional! :-) This has been a contentious point, so it
is stated in two different ways to make the point that platforms should not
try to do both.
Systems that support both interfaces must provide a configuration
mechanism to select either ACPI or Devicetree,
and must ensure only the selected interface is provided to the OS loader.
+Devicetree
+^^^^^^^^^^
+
+If firmware provides a Devicetree system description then it must be
provided
+in Flattened Devicetree (DTB) format version 17 or higher as described in
+[DTSPEC]_ § 5.1.
+The following GUID must be used in the EFI system table ([UEFI]_ § 4)
+to identify the DTB.
The device tree spec has a sentence starting "The Devicetree Blob (DTB)
format ...". So maybe:
%s/the DTB\./the Devicetree Blob (DTB)./
I went with %s/Devicetree (DTB)/Devicetree Blob (DTB)/ a couple of lines above.
ACPI and DTB are missing in the glossary.
+The DTB must be contained in memory of type EfiACPIReclaimMemory.
The UEFI spec that says:
In general, UEFI Configuration Tables loaded at boot time (e.g., SMBIOS
table) can be contained in memory of type EfiRuntimeServicesData
(recommended), EfiBootServicesData, EfiACPIReclaimMemory or
EfiACPIMemoryNVS.
Our requirement contradicts this recommendation of the UEFI 2.8A spec.
But the spec also says: "ACPI Tables loaded at boot time can be
contained in memory of type EfiACPIReclaimMemory (recommended) or
EfiACPIMemoryNVS."
So I suggest to add a sentence here that explains our choice, e.g.:
"EfiACPIReclaimMemory was chosen to match the recommendation for ACPI
tables which fulfill the same task as the DTB."
Added this line verbatim. Thanks.
+
+.. code-block:: c
+
+ #define EFI_DTB_GUID \
+ EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
+ 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
+
+Firmware must have the DTB resident in memory and installed in the EFI
system table
+before executing any UEFI applications or drivers that are not part of
the system
+firmware image.
+Once the DTB is installed as a configuration table,
+the system firmware must not make any modification to it or reference
any data
+contained within the DTB.
This is something I need to fix in U-Boot. Currently we are installing a
new instance of the the device tree every time that the 'bootefi'
command is executed.
How about the ACPI and SMBIOS tables? Shouldn't we require the same: "Do
not change the ACPI and SMBIOS tables once they are passed to outside
the system firmware."?
We've not had a debate about ACPI or SMBIOS. I don't know if there is any
expectation of ACPI or SMBIOS tables being modified at ExitBootServices
time (I simply don't have enough experience with either to know what is
appropriate, so what I've written is focused on the DT use case).
Why are the SMBIOS tables not mentioned at all in the EBBR?
Hasn't come up in any previous discussions. Typically the debate is over
ACPI vs. DT, and as I understand it ACPI doesn't require SMBIOS to be
present. Nothing in EBBR excludes the creation of SMBIOS tables.
In U-Boot we currently create:
BIOS Information (Type 0)
System Information (Type 1)
Baseboard(or Module) Information (Type 2)
System Enclosure or Chassis (Type 3)
Processor Information (Type 4)
System Boot Information (Type 32)
End-of-Table (Type 127)
Thanks for taking care of the release.
Thanks for the review.
g.
Best regards
Heinrich
+
+UEFI applications are permitted to modify or replace the loaded DTB.
+System firmware must not depend on any data contained within the DTB.
+If system firmware makes use of a DTB for its own configuration,
+it should use a separate private copy that is not installed in the
+EFI System Table or otherwise be exposed to EFI applications.
+
UEFI Secure Boot (Optional)
---------------------------
@@ -111,7 +140,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 `RuntimeServicesSupported`
variable to
+then firmware shall provide the `EFI_RT_PROPERTIES_TABLE` to
indicate which functions are available during runtime services.
Functions that are not available during runtime services shall return
EFI_UNSUPPORTED.
@@ -148,7 +177,7 @@ Firmware shall not create runtime mappings, or
perform any runtime IO that will
conflict with device access by the OS.
Normally this means a device may be controlled by firmware, or
controlled by
the OS, but not both.
-e.g. If firmware attempts to access an eMMC device at runtime then it will
+E.g. if firmware attempts to access an eMMC device at runtime then it will
conflict with transactions being performed by the OS.
Devices that are provided to the OS (i.e., via PCIe discovery or ACPI/DT
@@ -202,7 +231,8 @@ If a platform does not implement modifying
non-volatile variables with
SetVariable() after ExitBootServices(),
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.
+via the `RuntimeServicesSupported` value in the `EFI_RT_PROPERTIES_TABLE`
+as defined in [UEFI]_ § 4.6.
EFI applications can read `RuntimeServicesSupported` to determine if calls
to SetVariable() need to be performed before calling ExitBootServices().
diff --git a/source/chapter3-secureworld.rst
b/source/chapter3-secureworld.rst
index 4e9fa61..9c51bca 100644
--- a/source/chapter3-secureworld.rst
+++ b/source/chapter3-secureworld.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
-******************************
-Priviledged or Secure Firmware
-******************************
+*****************************
+Privileged or Secure Firmware
+*****************************
AArch32 Multiprocessor Startup Protocol
=======================================
diff --git a/source/index.rst b/source/index.rst
index 9bc4a09..7a5ded9 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -45,6 +45,9 @@ Creative Commons, PO Box 1866, Mountain View, CA
94042, USA.
31 March 2019 1.0 - Remove unnecessary UEFI requirements
appendix
- Allow for ACPI vendor id in firmware path
+ 1 June 2020 1.0.1-rc1 - Update to UEFI 2.8 Errata A
+ - Specify UUID for passing DTB
+ - Typo and editorial fixes
================= =========
=============================================
.. toctree::
diff --git a/source/references.rst b/source/references.rst
index a12c1a2..1eb0509 100644
--- a/source/references.rst
+++ b/source/references.rst
@@ -8,8 +8,8 @@
<https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2>`_,
`Devicetree.org <https://devicetree.org>`_
-.. [LINUXA64BOOT] `Linux Documentation/arm64/booting.txt
-
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/arm64/booting.txt>`_,
+.. [LINUXA64BOOT] `Linux Documentation/arm64/booting.rst
+ <https://www.kernel.org/doc/html/latest/arm64/booting.html>`_,
Linux kernel
.. [PSCI] `Power State Coordination Interface Issue C (PSCI v1.0)
@@ -20,6 +20,6 @@
<https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf>`_
8 March 2016, `Arm Limited <http://arm.com>`_
-.. [UEFI] `Unified Extensable Firmware Interface Specification v2.7A
-
<http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf>`_,
- August 2017, `UEFI Forum <http://www.uefi.org>`_
+.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8
Errata A
+
<https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_,
+ February 2020, `UEFI Forum <http://www.uefi.org>`_
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
