Thanks Grant
-----Original Message----- From: Grant Likely [mailto:grant.likely@arm.com] Sent: Thursday, July 12, 2018 1:44 AM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss@arm.com Cc: Udit Kumar udit.kumar@nxp.com; Grant Likely grant.likely@arm.com Subject: [PATCH] v0.6-pre1 draft comments responses
Edits responding to comments from Udit Kumar
Suggested-by: Udit Kumar udit.kumar@nxp.com Signed-off-by: Grant Likely grant.likely@arm.com
Reviewed by : Udit Kumar udit.kumar@nxp.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 platforms. 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 b/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 (ESP). 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]_ -- 2.13.0
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.