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
+.. [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 boot-architecture@lists.linaro.org 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.