Edits responding to comments from Udit Kumar

Suggested-by: Udit Kumar <udit.ku...@nxp.com>
Signed-off-by: Grant Likely <grant.lik...@arm.com>
 source/chapter1-about.rst          | 16 +++++++++-------
 source/chapter4-firmware-media.rst |  3 ++-
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index a2561d6..1dafd39 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -10,7 +10,7 @@ between platform firmware and an operating system that is 
suitable for embedded
 EBBR compliant platforms present a consistent interface that will boot an EBBR
 compliant operating system without any custom tailoring required.
-For example, an Arm A-class embedded networking platform will benefit
+For example, an Arm A-class embedded platform will benefit
 from a standard interface that supports features such as secure boot and
 firmware update.

@@ -149,12 +149,14 @@ 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 on hardware and
-firmware 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.
+operating system.
+SBBR is targeted at the server ecosystem and places strict requirements on the
+platform to ensure cross vendor interoperability.
+EBBR on the other hand allows more flexibility to support embedded designs
+which do not fit within the SBBR model.
+For example, a platform that isn't SBBR compliant because the SoC is only
+supported using Devicetree could be EBBR compliant, but not SBBR compliant.
 By definition, all SBBR compliant systems are also EBBR compliant, but the
 converse is not true.

diff --git a/source/chapter4-firmware-media.rst 
index 604df18..39a1c03 100644
--- a/source/chapter4-firmware-media.rst
+++ b/source/chapter4-firmware-media.rst
@@ -4,7 +4,8 @@ Firmware Storage

 In general, EBBR compliant platforms should use dedicated storage for boot
 firmware images and data,
-independent of the storage used for OS partitions and the ESP.
+independent of the storage used for OS partitions and the EFI System Partition
 This could be a physically separate device (e.g. SPI flash),
 or a dedicated logical unit (LU) within a device
 (e.g. eMMC boot partition, [#eMMCBootPartition]_

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

Reply via email to