Thanks Grant
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@arm.com]
> Sent: Thursday, July 12, 2018 1:44 AM
> To: boot-architecture@lists.linaro.org; arm.ebbr-disc...@arm.com
> Cc: Udit Kumar ; Grant Likely
> Subject: [PATCH] v0.6-pre1 draft comments responses
>
> Edits responding to comments from Udit Kumar
>
> Suggested-by: Udit Kumar
> Signed-off-by: Grant Likely
Reviewed by : Udit Kumar
> ---
> 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.
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
