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 <wmi...@ti.com>
> [glikely: made it more verbose to make the intent clear]
> Signed-off-by: Grant Likely <grant.lik...@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-disc...@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
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to