Grant,

Excellent. Some suggestions in-line:

On 07/06/2018 12:26 PM, Grant Likely wrote:

Give some rationale behind EBBR so the reader understands what problem the specification is intended to solve.

Signed-off-by: Bill Mills wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com

Don't know the protocol but signed-off-by and/or reviewed-by me again.

---

source/chapter1-about.rst | 94 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index b667f1b..cb675d9 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -23,6 +23,100 @@ It leverages the prevalent industry standard firmware specification of [UEFI]_. Comments or change requests can be sent to arm.ebbr-discuss@arm.com. +Guiding Principals +==================

s/Principals/Principles/

You carried forward my mistake. Daniel correctly pointed out that we are not talking about a helpful person.

+EBBR as a specification defines requirements on platforms and operating systems, +but requirements alone don't provide insight into why the specification is +written the way it is, or what problems it is intended to solve. +Using the assumption that better understanding of the thought process behind +EBBR will result in better implementations, this section is a discussion of the +goals and guiding principle that shaped EBBR.

+This section should be considered commentary, and not a formal part of the specification.

+EBBR was written as a response to the lack of boot sequence standardization in the embedded system ecosystem. +As embedded systems are becoming more sophisticated and connected, +it is becoming increasingly important for embedded systems to run standard OS +distributions and software stacks, or to have consistent behaviour across a +large deployment of heterogeneous platforms. +However, the lack of consistency between platforms often requires per-platform +customization to get an OS image to boot on multiple platforms.

+A large part of this ecosystem is based on U-Boot and Linux. +Vendors have heavy investments in both projects and are not interested in large +scale changes to their firmware architecture. +The challenge for EBBR is to define a set of boot standards that reduce the +amount of custom engineering required, make it possible for OS distributions to +support embedded platforms, while still preserving the firmware stack product +vendors are comfortable with. +Or in simpler terms, EBBR is designed to solve the embedded boot mess by

Instead of:

+migrating existing firmware projects (U-Boot) to a defined standard (UEFI).

How about + adding a defined standard (UEFI) to the existing firmware projects (U-boot)

More accurate, less scary sounding. Makes it clear you are not changing code bases. Some people still think UEFI is a code base.

+However, EBBR is a specification, not an implementation. +The goal of EBBR is not to mandate U-Boot and Linux. +Rather, it is to mandate interfaces that can be implemented by any firmware or +OS project, while at the same time work with both Tianocore/EDK2 and U-Boot to +ensure that the EBBR requirements are implemented by both projects. +[#EDK2Note]_

+.. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the

• time of writing these are the two most important firmware projects.
• Tianocore/EDK2 is a full featured UEFI implementation and so should
• automatically be EBBR compliant. U-Boot is the incumbant firmware project
• for embedded platforms and has added basic UEFI compliance.

+The following guiding principals of the EBBR specification and its +process:

s/principals/principles/

+- Be agnostic about ACPI and Devicetree.

• EBBR explicitly does not require a specific system description language.
• Both Devicetree and ACPI are supported.
• While ACPI provides more standardization, Devicetree is preferred in may embedded
• platforms for its flexibility.
• The Linux kernel supports both equally well, and so EBBR doesn't require one
• over the other.
• However, it does require the system description to be provided by the
• platform, and that it conform to the relevant ACPI or DT specifications.

+- Focus on the UEFI interface, not a specific codebase

• EBBR does not require a specific firmware implementation.
• Any firmware project can implement these interfaces.
• Neither U-Boot nor Tianocore/EDK2 are required.

+- Design to be implementable and useful today

• The drafting process for EBBR worked closely with U-Boot and Tianocore
• developers to ensure that current upstream code will meet the requirements.

+- Design to be OS independent

• This document uses Linux as an example but other OS's are expected.

+- Support multiple architectures

• Any architecture can implement the EBBR requirements.
• .. note::

• At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected.
  

+- Design for common embedded hardware

• EBBR support will be implemented on existing developer hardware.
• Generally anything that has a near-upstream U-Boot implementation should be
• able to implement the EBBR requirements.
• EBBR was drafted with readily available hardware in mind, like the
• Raspberry Pi and BeagleBone families of boards, and it is applicable for low cost boards (<$10).

+- Plan to evolve over time

• The first release of EBBR is firmly targeting current embedded hardware.
• Future versions will add capabilities which may tighten the hardware requirements.

Daniel asked if we want to drop the "hardware" here.

• However, existing compliant boards will remain compliant.

Scope

This document defines the boot and runtime services that are expected by an

Yes, I like your enhanced version much better and it still has all the points I wanted to make.

Thanks, Bill