On 11.07.18 22:15, Grant Likely wrote: > On 11/07/2018 21:13, Simon Glass wrote: >> Hi Grant, >> >> On 9 July 2018 at 06:17, Grant Likely <grant.lik...@arm.com> wrote: >>> Editing in response to comments from Bill Mills, Daniel Thompson, and >>> Alex Graf. Mostly trivial editorial, but did flush out the discussion of >>> how future updates to the specification would be handled, and added a >>> note about DT platform compatibility rules. >>> >>> Signed-off-by: Grant Likely <grant.lik...@arm.com> >>> Cc: Bill Mills <wmi...@ti.com> >>> Cc: Alexander Graf <ag...@suse.de> >>> Cc: Daniel Thompson <daniel.thomp...@linaro.org> >>> --- >>> source/chapter1-about.rst | 49 >>> ++++++++++++++++++++++++++++++++--------------- >>> 1 file changed, 34 insertions(+), 15 deletions(-) >>> >> >> Reviewed-by: Simon Glass <s...@chromium.org> > > hahaha! You are about 5 minutes too late. I just pushed the patch to > mainline. :-) > > The mailing list archives are forever... > >> >>> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst >>> index cb675d9..a2561d6 100644 >>> --- a/source/chapter1-about.rst >>> +++ b/source/chapter1-about.rst >>> @@ -23,7 +23,7 @@ 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 >>> +Guiding Principles >>> ================== >>> >>> EBBR as a specification defines requirements on platforms and >>> operating systems, >>> @@ -51,7 +51,7 @@ 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). >>> +adding a defined standard (UEFI) to the existing firmware projects >>> (U-Boot). >>> >>> However, EBBR is a specification, not an implementation. >>> The goal of EBBR is not to mandate U-Boot and Linux. >>> @@ -61,24 +61,33 @@ 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. >>> + time of writing these are the two most important firmware >>> projects that >>> + implement UEFI. >>> 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. >>> + automatically be EBBR compliant. >>> + U-Boot is the incumbant firmware project for embedded platforms >>> and has >>> + steadily been adding UEFI compliance since 2016. >> >> Or 2015? That's when it got payload and app support. But I suspect you >> are talking about the efi_loader support only? > > Ask Alex, He provided the wording. :-)
Yes, EBBR only cares about the efi_loader parts. I guess you could stretch the sentence to mean payload support too which really helped a lot, but then again 1 year left or right won't make a big difference. Alex _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
