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? > + > +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 ;). > + 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. > + > +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. Alex _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
