On 08/07/2018 22:42, Alexander Graf wrote:
On 06.07.18 18:26, 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 <[email protected]>
[glikely: made it more verbose to make the intent clear]
Signed-off-by: Grant Likely <[email protected]>
---
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 [email protected].
+Guiding Principals
+==================
+
+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.
principles?
fixed
+
+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
+migrating existing firmware projects (U-Boot) to a defined standard (UEFI).
+
+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.
You probably want to clarify that they are the most important firmware
projects *implementing UEFI*. I'm quite sure that whatever Android does
easily outnumbers us ;).
Good point
+ 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.
This document will love for a while. Maybe better document it as trajectory:
... and has steadily been adding UEFI compliance since 2016.
added
+
+The following guiding principals of the EBBR specification and its
principles again, but I guess you'll just search&replace.
+process:
+
+- 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
many
+ 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.
... and adhere to strict compatbility rules.
I've flushed this out a bit. I'll post my thoughts in the followup patch
g.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
