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