Some of the glossary terms got split across lines which put half the term in the description instead of the entry name. Fix the 'AArch64 State' and 'EFI Loaded Image' entries.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 4269b49..9e787ed 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -77,16 +77,16 @@ This document uses the following terms and abbreviations. The 64-bit ARM instruction set used in AArch64 state. All A64 instructions are 32 bits.
- AArch64 - state The ARM 64-bit Execution state that uses 64-bit general purpose + AArch64 state + The ARM 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and exception link registers (ELR).
AArch64 Execution state provides a single instruction set, A64.
- EFI - Loaded Image An executable image to be run under the UEFI environment, + EFI Loaded Image + An executable image to be run under the UEFI environment, and which uses boot time services.
EL0
Use reStructuredText citation markup to capture all referenced documents. Sphinx will take care of creating a table of references at the end of the document.
Fixes #6 Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 53 +++++++++++++++++++---------------------------------- 1 file changed, 19 insertions(+), 34 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 9e787ed..7adcd0a 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -40,23 +40,6 @@ It leverages the prevalent industry standard firmware specifications of UEFI.
Comments or change requests can be sent to arm.ebbr-discuss@arm.com.
-References -========== - -This document refers to the following documents. - -========= ====================== ======== ===== -Reference Doc No Authors Title -========= ====================== ======== ===== -1 ARM DDI 0487 ARM ARM® Architecture Reference Manual, - ARMv8, for ARMv8-A architecture profile -2 UEFI Specification 2.7 UEFI.org Unified Extensible Firmware Interface - Specification. - Version 2.7 -3 ARM DEN 022 ARM Power State Coordination Interface (PSCI) - Version 1.1 -========= ====================== ======== ===== - Cross References ---------------- This document cross-references sources that are listed in the References @@ -64,7 +47,7 @@ section by using the section sign §.
Examples:
-UEFI § 6.1 - Reference to the UEFI specification [4] section 6.1 +UEFI § 6.1 - Reference to the UEFI specification [UEFI]_ section 6.1
Terms and abbreviations ======================= @@ -132,22 +115,11 @@ This document defines the boot and runtime services that are expected by an Operating System or hypervisor, for an ARM embedded device, which follows the UEFI specification.
-This document references the following specification and versions: - - UEFI 2.7 - Published June 2017, includes the AArch64 bindings. - This specification defines the boot and runtime services for a physical system, including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest Operating System.
-When present with in a system, this document makes additional references to the -Power State Coordination Interface: - - PSCI 1.1 - Published April 2017. - **** UEFI **** @@ -156,13 +128,13 @@ UEFI Version ============
Boot and system firmware for ARM embedded devices can be based on the UEFI -specification[2], version 2.7 or later, incorporating the AArch64 bindings. +specification[UEFI_], version 2.7 or later, incorporating the AArch64 bindings.
UEFI Compliance ===============
Any UEFI-compliant system must follow the requirements that are laid out in -section 2.6 of the UEFI specification. +section 2.6 of the UEFI specification[UEFI_]. However, to ensure a common boot architecture for embedded-class, systems compliant with this specification must always provide the UEFI services and protocols that are listed in Appendix A, Appendix B, and Appendix C of this @@ -306,9 +278,10 @@ command:
- EfiWarmReset()
-.. note:: When Runtime Services and PSCI co-exist, it is anticipated that - Operating System calls to reset the system will go via Runtime Services and - not directly to PSCI. +.. note:: On platforms implementing the Power State Coordination Interface + specification[PSCI_], it is still required that EBBR compliant + Operating Systems calls to reset the system will go via Runtime Services + and not directly to PSCI.
Set Variable ------------ @@ -545,3 +518,15 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. note:: Support for iSCSI is only required on machines that lack persistent storage, such as a, HDD. This configuration is intended for thin clients and compute-only nodes + +.. Collect all references below this line + +.. [ACPI] `Advanced Configuration and Power Interface specification v6.2A + http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, + September 2017, `UEFI Forum http://www.uefi.org`_ +.. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) + http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, + 21 April 2017, `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`_
Be specific that an EBBR platform must provide either ACPI or Devicetree data in the EFI configuration table, but not both. Platforms are allowed to support both ACPI & DT booting as a configuration option, but only one interface can be presented to the OS at a time.
Also add references to the ACPI and Devicetree specifications.
Fixes #5 Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 7adcd0a..858bd01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -198,9 +198,16 @@ Configuration Tables --------------------
A UEFI system that complies with this specification may provide the additional -tables via the EFI Configuration Table. -For example, ACPI table or Device Tree table may be needed to support -configuration and power management. +tables via the EFI Configuration Table. At a minimum, the system must provide +system data that conforms with either: + +- the Advanced Configuration and Power Interface specification[ACPI_], or +- the Devicetree Specification[DTSPEC_]. + +While a platform may provide either ACPI or Devicetree, it must not +provide both at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time mechanism +to select one or the other before an OS Loader is executed.
UEFI Secure Boot (Optional) --------------------------- @@ -524,6 +531,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, September 2017, `UEFI Forum http://www.uefi.org`_ +.. [DTSPEC] `Devicetree specification v0.2 + https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2`_, + `Devicetree.org https://devicetree.org`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
On Fri, May 18, 2018 at 02:06:09PM +0100, Grant Likely wrote:
Be specific that an EBBR platform must provide either ACPI or Devicetree data in the EFI configuration table, but not both. Platforms are allowed to support both ACPI & DT booting as a configuration option, but only one interface can be presented to the OS at a time.
Also add references to the ACPI and Devicetree specifications.
Fixes #5 Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 7adcd0a..858bd01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -198,9 +198,16 @@ Configuration Tables
A UEFI system that complies with this specification may provide the additional -tables via the EFI Configuration Table. -For example, ACPI table or Device Tree table may be needed to support -configuration and power management. +tables via the EFI Configuration Table. At a minimum, the system must provide
Perhaps remove "At a minium"? It implies both might acceptable but that is then ruled out in the following paragraph.
+system data that conforms with either:
+- the Advanced Configuration and Power Interface specification[ACPI_], or +- the Devicetree Specification[DTSPEC_].
+While a platform may provide either ACPI or Devicetree, it must not +provide both at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time mechanism +to select one or the other before an OS Loader is executed. UEFI Secure Boot (Optional)
@@ -524,6 +531,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, September 2017, `UEFI Forum http://www.uefi.org`_ +.. [DTSPEC] `Devicetree specification v0.2
- https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2`_,
- `Devicetree.org https://devicetree.org`_
.. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ -- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 18/05/2018 16:28, Daniel Thompson wrote:
On Fri, May 18, 2018 at 02:06:09PM +0100, Grant Likely wrote:
Be specific that an EBBR platform must provide either ACPI or Devicetree data in the EFI configuration table, but not both. Platforms are allowed to support both ACPI & DT booting as a configuration option, but only one interface can be presented to the OS at a time.
Also add references to the ACPI and Devicetree specifications.
Fixes #5 Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 7adcd0a..858bd01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -198,9 +198,16 @@ Configuration Tables
A UEFI system that complies with this specification may provide the additional -tables via the EFI Configuration Table. -For example, ACPI table or Device Tree table may be needed to support -configuration and power management. +tables via the EFI Configuration Table. At a minimum, the system must provide
Perhaps remove "At a minium"? It implies both might acceptable but that is then ruled out in the following paragraph.
I was trying to get across that it isn't acceptable to provide neither, without ruling out other supplmental tables. ie. SMBIOS.
Would this be better?
A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table. + +EBBR systems are required to provide one, but not both, of the +following supplimental tables. + +- An Advanced Configuration and Power Interface[ACPI_] table, or +- A Devicetree[DTSPEC_] system description. + +As stated above, an EBBR system must not provide both ACPI and +Devicetree tables at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time +mechanism to select one or the other, before the OS Loader is +executed.
+system data that conforms with either:
+- the Advanced Configuration and Power Interface specification[ACPI_], or +- the Devicetree Specification[DTSPEC_].
+While a platform may provide either ACPI or Devicetree, it must not +provide both at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time mechanism +to select one or the other before an OS Loader is executed. UEFI Secure Boot (Optional)
@@ -524,6 +531,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, September 2017, `UEFI Forum http://www.uefi.org`_ +.. [DTSPEC] `Devicetree specification v0.2
- https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2`_,
- `Devicetree.org https://devicetree.org`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On Fri, May 18, 2018 at 8:06 AM, Grant Likely grant.likely@arm.com wrote:
Be specific that an EBBR platform must provide either ACPI or Devicetree data in the EFI configuration table, but not both. Platforms are allowed to support both ACPI & DT booting as a configuration option, but only one interface can be presented to the OS at a time.
Also add references to the ACPI and Devicetree specifications.
Fixes #5 Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 7adcd0a..858bd01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -198,9 +198,16 @@ Configuration Tables
A UEFI system that complies with this specification may provide the additional -tables via the EFI Configuration Table. -For example, ACPI table or Device Tree table may be needed to support -configuration and power management. +tables via the EFI Configuration Table. At a minimum, the system must provide +system data that conforms with either:
+- the Advanced Configuration and Power Interface specification[ACPI_], or +- the Devicetree Specification[DTSPEC_].
+While a platform may provide either ACPI or Devicetree, it must not +provide both at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time mechanism +to select one or the other before an OS Loader is executed.
UEFI Secure Boot (Optional)
@@ -524,6 +531,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, September 2017, `UEFI Forum http://www.uefi.org`_ +.. [DTSPEC] `Devicetree specification v0.2
Do we really want the exact version that we have to update? Also, it is not like 0.2 version of the spec is in anyway a complete representation of DT requirements. You can link to .../releases/latest/ BTW. OTOH, the version doesn't change that often.
Rob
On 23/05/2018 19:12, Rob Herring wrote:
On Fri, May 18, 2018 at 8:06 AM, Grant Likely grant.likely@arm.com wrote:
Be specific that an EBBR platform must provide either ACPI or Devicetree data in the EFI configuration table, but not both. Platforms are allowed to support both ACPI & DT booting as a configuration option, but only one interface can be presented to the OS at a time.
Also add references to the ACPI and Devicetree specifications.
Fixes #5 Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 7adcd0a..858bd01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -198,9 +198,16 @@ Configuration Tables
A UEFI system that complies with this specification may provide the additional -tables via the EFI Configuration Table. -For example, ACPI table or Device Tree table may be needed to support -configuration and power management. +tables via the EFI Configuration Table. At a minimum, the system must provide +system data that conforms with either:
+- the Advanced Configuration and Power Interface specification[ACPI_], or +- the Devicetree Specification[DTSPEC_].
+While a platform may provide either ACPI or Devicetree, it must not +provide both at the same time. Platforms that want to offer +both ACPI and Devicetree solutions must implement a boot time mechanism +to select one or the other before an OS Loader is executed.
UEFI Secure Boot (Optional)
@@ -524,6 +531,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf`_, September 2017, `UEFI Forum http://www.uefi.org`_ +.. [DTSPEC] `Devicetree specification v0.2
Do we really want the exact version that we have to update? Also, it is not like 0.2 version of the spec is in anyway a complete representation of DT requirements. You can link to .../releases/latest/ BTW. OTOH, the version doesn't change that often.
Yes, I think we do. A release of a spec like this is built on specific versions (or higher) of the specs it references. I put in v0.2 just because that is what we have right now. If we can get a new DT spec out before EBBR is released, then this should be updated.
g.
Scope doesn't need it's own chapter. Move it into the 'About This Document' chapter. Also expand the text to place this document in relation to the existing SBBR document. SBBR is the stricter of the two, so EBBR can be considered a superset. (ie. all SBBR compliant platforms are also EBBR compliant, but the converse is not true).
Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 858bd01..700feba 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -40,8 +40,29 @@ It leverages the prevalent industry standard firmware specifications of UEFI.
Comments or change requests can be sent to arm.ebbr-discuss@arm.com.
+Scope +===== +This document defines the boot and runtime services that are expected by an +Operating System or hypervisor, for an ARM embedded device, which follows the +UEFI specification. + +This specification defines the boot and runtime services for a physical system, +including services that are required for virtualization. +It does not define a standardized abstract virtual machine view for a Guest +Operating System. + +This specification is similar to the Arm Server Base Boot Requirements +specification[SBBR_] in that it defines the firmware interface presented to an +operating system, with SBBR having stricter requirements than EBBR. EBBR +allows for design decisions that are common in the embedded space, but not +supported by the server ecosystem. +For example, an embedded system may use a single eMMC storage device to hold +both firmware and operating system images. +By definition, all SBBR compliant systems are also EBBR compliant, but the +converse is not true. + Cross References ----------------- +================ This document cross-references sources that are listed in the References section by using the section sign §.
@@ -107,19 +128,6 @@ This document uses the following terms and abbreviations. Functionality that is provided to an Operating System after the ExitBootServices() call.
-***** -Scope -***** - -This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an ARM embedded device, which follows the -UEFI specification. - -This specification defines the boot and runtime services for a physical system, -including services that are required for virtualization. -It does not define a standardized abstract virtual machine view for a Guest -Operating System. - **** UEFI **** @@ -537,6 +545,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ +.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) + 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`_
On Fri, May 18, 2018 at 02:06:10PM +0100, Grant Likely wrote:
Scope doesn't need it's own chapter. Move it into the 'About This Document' chapter. Also expand the text to place this document in relation to the existing SBBR document. SBBR is the stricter of the two, so EBBR can be considered a superset. (ie. all SBBR compliant platforms are also EBBR compliant, but the converse is not true).
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 858bd01..700feba 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -40,8 +40,29 @@ It leverages the prevalent industry standard firmware specifications of UEFI. Comments or change requests can be sent to arm.ebbr-discuss@arm.com. +Scope +===== +This document defines the boot and runtime services that are expected by an +Operating System or hypervisor, for an ARM embedded device, which follows the
nit: Isn't Arm title cased these days?
+UEFI specification.
+This specification defines the boot and runtime services for a physical system, +including services that are required for virtualization. +It does not define a standardized abstract virtual machine view for a Guest +Operating System.
+This specification is similar to the Arm Server Base Boot Requirements +specification[SBBR_] in that it defines the firmware interface presented to an +operating system, with SBBR having stricter requirements than EBBR. EBBR
Perhaps another nit but it would be good to say who the stricter requirements apply to (reducing requirements on firmware typically implies increasing requirements on the OS).
+allows for design decisions that are common in the embedded space, but not +supported by the server ecosystem. +For example, an embedded system may use a single eMMC storage device to hold +both firmware and operating system images. +By definition, all SBBR compliant systems are also EBBR compliant, but the +converse is not true.
Cross References
+================ This document cross-references sources that are listed in the References section by using the section sign §. @@ -107,19 +128,6 @@ This document uses the following terms and abbreviations. Functionality that is provided to an Operating System after the ExitBootServices() call. -***** -Scope -*****
-This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an ARM embedded device, which follows the -UEFI specification.
-This specification defines the boot and runtime services for a physical system, -including services that are required for virtualization. -It does not define a standardized abstract virtual machine view for a Guest -Operating System.
UEFI
@@ -537,6 +545,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ +.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
- 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`_ -- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 18/05/2018 16:39, Daniel Thompson wrote:
On Fri, May 18, 2018 at 02:06:10PM +0100, Grant Likely wrote:
Scope doesn't need it's own chapter. Move it into the 'About This Document' chapter. Also expand the text to place this document in relation to the existing SBBR document. SBBR is the stricter of the two, so EBBR can be considered a superset. (ie. all SBBR compliant platforms are also EBBR compliant, but the converse is not true).
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 858bd01..700feba 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -40,8 +40,29 @@ It leverages the prevalent industry standard firmware specifications of UEFI. Comments or change requests can be sent to arm.ebbr-discuss@arm.com. +Scope +===== +This document defines the boot and runtime services that are expected by an +Operating System or hypervisor, for an ARM embedded device, which follows the
nit: Isn't Arm title cased these days?
Cut and paste of existing text. I'll do a separate patch to sweep out the old usage.
+UEFI specification.
+This specification defines the boot and runtime services for a physical system, +including services that are required for virtualization. +It does not define a standardized abstract virtual machine view for a Guest +Operating System.
+This specification is similar to the Arm Server Base Boot Requirements +specification[SBBR_] in that it defines the firmware interface presented to an +operating system, with SBBR having stricter requirements than EBBR. EBBR
Perhaps another nit but it would be good to say who the stricter requirements apply to (reducing requirements on firmware typically implies increasing requirements on the OS).
How about:
With SBBR having stricter requirements on hardware and firmware than EBBR.
+allows for design decisions that are common in the embedded space, but not +supported by the server ecosystem. +For example, an embedded system may use a single eMMC storage device to hold +both firmware and operating system images. +By definition, all SBBR compliant systems are also EBBR compliant, but the +converse is not true.
- Cross References
+================ This document cross-references sources that are listed in the References section by using the section sign §. @@ -107,19 +128,6 @@ This document uses the following terms and abbreviations. Functionality that is provided to an Operating System after the ExitBootServices() call. -***** -Scope -*****
-This document defines the boot and runtime services that are expected by an -Operating System or hypervisor, for an ARM embedded device, which follows the -UEFI specification.
-This specification defines the boot and runtime services for a physical system, -including services that are required for virtualization. -It does not define a standardized abstract virtual machine view for a Guest -Operating System.
UEFI
@@ -537,6 +545,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ +.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
- 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`_
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On Fri, May 18, 2018 at 05:30:09PM +0100, Grant Likely wrote:
On 18/05/2018 16:39, Daniel Thompson wrote:
On Fri, May 18, 2018 at 02:06:10PM +0100, Grant Likely wrote:
Scope doesn't need it's own chapter. Move it into the 'About This Document' chapter. Also expand the text to place this document in relation to the existing SBBR document. SBBR is the stricter of the two, so EBBR can be considered a superset. (ie. all SBBR compliant platforms are also EBBR compliant, but the converse is not true).
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 858bd01..700feba 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -40,8 +40,29 @@ It leverages the prevalent industry standard firmware specifications of UEFI. Comments or change requests can be sent to arm.ebbr-discuss@arm.com. +Scope +===== +This document defines the boot and runtime services that are expected by an +Operating System or hypervisor, for an ARM embedded device, which follows the
nit: Isn't Arm title cased these days?
Cut and paste of existing text. I'll do a separate patch to sweep out the old usage.
Ok.
+UEFI specification.
+This specification defines the boot and runtime services for a physical system, +including services that are required for virtualization. +It does not define a standardized abstract virtual machine view for a Guest +Operating System.
+This specification is similar to the Arm Server Base Boot Requirements +specification[SBBR_] in that it defines the firmware interface presented to an +operating system, with SBBR having stricter requirements than EBBR. EBBR
Perhaps another nit but it would be good to say who the stricter requirements apply to (reducing requirements on firmware typically implies increasing requirements on the OS).
How about:
With SBBR having stricter requirements on hardware and firmware than EBBR.
Yes. Like this. As changed: Reviewed-by: Daniel Thompson daniel.thompson@linaro.org
Daniel.
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System.
+****************************** +Priviledged or Secure Firmware +****************************** + +Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_]. + +Platforms without EL3 must implement one of: + +- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform + +However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI should +be implemented in all new designs. + **************************************** APPENDIX A - Required UEFI Boot Services **************************************** @@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_, + Linux kernel +.. [MPSTART] `MP Startup for Arm + https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_, + 20 December 2012, `Microsoft http://microsoft.com`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
On Fri, May 18, 2018 at 02:06:11PM +0100, Grant Likely wrote:
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com
Reviewed-by: Daniel Thompson daniel.thompson@linaro.org
source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System. +****************************** +Priviledged or Secure Firmware +******************************
+Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_].
+Platforms without EL3 must implement one of:
+- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform
+However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI should +be implemented in all new designs.
APPENDIX A - Required UEFI Boot Services
@@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_,
- Linux kernel
+.. [MPSTART] `MP Startup for Arm
- https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_,
- 20 December 2012, `Microsoft http://microsoft.com`_
.. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ -- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
This part has been changed in the SBBR spec as we do expect server SoC to support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec reference is 1.0:
UEFI is defined as a uniprocessor specification that only uses a single CPU core for booting. Platforms providing EL3 must implement the Power State Coordination Interface (PSCI) [5]. This interface will be as the main method to boot secondary cores, implementing CPU idling, and providing reset and shutdown runtime services.
... some ACPI related requirements...
All secondary cores remain powered down during boot. After boot, OSPM can call CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI firmware powers up, initializes the core, and starts execution at the provided address.
- DW - -----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Grant Likely Sent: Friday, May 18, 2018 6:06 AM Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com --- source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System.
+****************************** +Priviledged or Secure Firmware +****************************** + +Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_]. + +Platforms without EL3 must implement one of: + +- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI +platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform + +However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI +should be implemented in all new designs. + **************************************** APPENDIX A - Required UEFI Boot Services **************************************** @@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_, + Linux kernel +.. [MPSTART] `MP Startup for Arm + https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_, + 20 December 2012, `Microsoft http://microsoft.com`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_ -- 2.13.0
_______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com 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.
Hi Dong,
Thanks for the comments. Replies below...
On 18/05/2018 19:01, Dong Wei wrote:
This part has been changed in the SBBR spec as we do expect server SoC to support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec reference is 1.0:
Can you double check that please? The copy on developer.arm.com is issue C (psci 1.0), but there is a more recent copy on infocenter; issue D for PSCI 1.1.
UEFI is defined as a uniprocessor specification that only uses a single CPU core for booting. Platforms providing EL3 must implement the Power State Coordination Interface (PSCI) [5]. This interface will be as the main method to boot secondary cores, implementing CPU idling, and providing reset and shutdown runtime services.
... some ACPI related requirements...
All secondary cores remain powered down during boot. After boot, OSPM can call CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI firmware powers up, initializes the core, and starts execution at the provided address.
That helps. Perhaps I'll drop the MP Boot language entirely and leave it at PSCI as the preferred, but Linux spin tables as a fallback, and only for DT systems.
g.
- DW
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Grant Likely Sent: Friday, May 18, 2018 6:06 AM Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System. +****************************** +Priviledged or Secure Firmware +******************************
+Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_].
+Platforms without EL3 must implement one of:
+- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI +platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform
+However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI +should be implemented in all new designs.
APPENDIX A - Required UEFI Boot Services
@@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_,
- Linux kernel
+.. [MPSTART] `MP Startup for Arm
- https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_,
- 20 December 2012, `Microsoft http://microsoft.com`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
Yes, I am referring to the upcoming SBBR v1.1 content. We changed the reference to PSCI back to 1.0 because that version is what we need for the MP support, 1.1 is also fine but not the minimal requirement.
- DW - -----Original Message----- From: Grant Likely Sent: Friday, May 18, 2018 12:47 PM To: Dong Wei Dong.Wei@arm.com Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Hi Dong,
Thanks for the comments. Replies below...
On 18/05/2018 19:01, Dong Wei wrote:
This part has been changed in the SBBR spec as we do expect server SoC to support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec reference is 1.0:
Can you double check that please? The copy on developer.arm.com is issue C (psci 1.0), but there is a more recent copy on infocenter; issue D for PSCI 1.1.
UEFI is defined as a uniprocessor specification that only uses a single CPU core for booting. Platforms providing EL3 must implement the Power State Coordination Interface (PSCI) [5]. This interface will be as the main method to boot secondary cores, implementing CPU idling, and providing reset and shutdown runtime services.
... some ACPI related requirements...
All secondary cores remain powered down during boot. After boot, OSPM can call CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI firmware powers up, initializes the core, and starts execution at the provided address.
That helps. Perhaps I'll drop the MP Boot language entirely and leave it at PSCI as the preferred, but Linux spin tables as a fallback, and only for DT systems.
g.
- DW
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Grant Likely Sent: Friday, May 18, 2018 6:06 AM Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System.
+****************************** +Priviledged or Secure Firmware +******************************
+Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_].
+Platforms without EL3 must implement one of:
+- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI +platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform
+However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI +should be implemented in all new designs.
APPENDIX A - Required UEFI Boot Services
@@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_,
- Linux kernel
+.. [MPSTART] `MP Startup for Arm
- https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_,
- 20 December 2012, `Microsoft http://microsoft.com`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
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.
On 18/05/2018 20:49, Dong Wei wrote:
Yes, I am referring to the upcoming SBBR v1.1 content. We changed the reference to PSCI back to 1.0 because that version is what we need for the MP support, 1.1 is also fine but not the minimal requirement.
Ah, that makes sense. I'll take a look next week and rework the EBBR text to match.
g.
- DW
-----Original Message----- From: Grant Likely Sent: Friday, May 18, 2018 12:47 PM To: Dong Wei Dong.Wei@arm.com Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Hi Dong,
Thanks for the comments. Replies below...
On 18/05/2018 19:01, Dong Wei wrote:
This part has been changed in the SBBR spec as we do expect server SoC to support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec reference is 1.0:
Can you double check that please? The copy on developer.arm.com is issue C (psci 1.0), but there is a more recent copy on infocenter; issue D for PSCI 1.1.
UEFI is defined as a uniprocessor specification that only uses a single CPU core for booting. Platforms providing EL3 must implement the Power State Coordination Interface (PSCI) [5]. This interface will be as the main method to boot secondary cores, implementing CPU idling, and providing reset and shutdown runtime services.
... some ACPI related requirements...
All secondary cores remain powered down during boot. After boot, OSPM can call CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI firmware powers up, initializes the core, and starts execution at the provided address.
That helps. Perhaps I'll drop the MP Boot language entirely and leave it at PSCI as the preferred, but Linux spin tables as a fallback, and only for DT systems.
g.
- DW
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Grant Likely Sent: Friday, May 18, 2018 6:06 AM Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware
Document the requirements for secure firmware to implement PSCI, particularly in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred solution, but make allowance for the other existing methods.
Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -309,6 +309,25 @@ the aid of the Operating System. .. note:: This normally requires dedicated storage for UEFI variables that is not directly accessible from the Operating System. +****************************** +Priviledged or Secure Firmware +******************************
+Multiprocessor Startup Protocol +=============================== +Firmware resident in Trustzone EL3 must implement and conform to the +Power State Coordination Interface specification[PSCI_].
+Platforms without EL3 must implement one of:
+- PSCI at EL2 (leaving only EL1 available to an operating system) +- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI +platform +- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform
+However, the MP Startup and Spintable protocols are strongly discouraged. +Future versions of this specification will only allow PSCI, and PSCI +should be implemented in all new designs.
APPENDIX A - Required UEFI Boot Services
@@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 .. [DTSPEC] `Devicetree specification v0.2 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`_,
- Linux kernel
+.. [MPSTART] `MP Startup for Arm
- https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc`_,
- 20 December 2012, `Microsoft http://microsoft.com`_ .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf`_, 21 April 2017, `Arm Limited http://arm.com`_
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
We don't have a CI generating PDFs yet, but interested parties can go and read the spec in raw form. Mention that in the README.
Cc: William Mills wmills@ti.com Signed-off-by: Grant Likely grant.likely@arm.com --- README.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/README.rst b/README.rst index 67c7e85..851c078 100644 --- a/README.rst +++ b/README.rst @@ -13,6 +13,17 @@ expected in September 2018. You can find the current draft text in this repository, but be aware that everything in the draft text is subject to change before an official v1.0 release is published.
+This repository can be used to build a .pdf of the document, and soon there +will be a CI loop generating a .pdf for each commit. In the mean time you +can look at the source text directly here: + +`EBBR Draft Text`_ + +GitHub does a good job of rendering the reStructuredText markup into +something readable. + +.. _`EBBR Draft Text`: source/ebbr.rst + Build Instructions ==================
On Fri, May 18, 2018 at 02:06:12PM +0100, Grant Likely wrote:
We don't have a CI generating PDFs yet, but interested parties can go and read the spec in raw form. Mention that in the README.
Cc: William Mills wmills@ti.com Signed-off-by: Grant Likely grant.likely@arm.com
Reviewed-by: Daniel Thompson daniel.thompson@linaro.org
README.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/README.rst b/README.rst index 67c7e85..851c078 100644 --- a/README.rst +++ b/README.rst @@ -13,6 +13,17 @@ expected in September 2018. You can find the current draft text in this repository, but be aware that everything in the draft text is subject to change before an official v1.0 release is published. +This repository can be used to build a .pdf of the document, and soon there +will be a CI loop generating a .pdf for each commit. In the mean time you +can look at the source text directly here:
+`EBBR Draft Text`_
+GitHub does a good job of rendering the reStructuredText markup into +something readable.
+.. _`EBBR Draft Text`: source/ebbr.rst
Build Instructions
2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
boot-architecture@lists.linaro.org
-
Daniel Thompson -
Dong Wei -
Grant Likely -
Rob Herring