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 <[email protected]>
---
  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 [email protected]. +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
[email protected]

_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to