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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org --- source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
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-discuss@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.
-The following guiding principals of the EBBR specification and its -process: +The following guiding principles are used while developing the EBBR specification.
- 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. + While ACPI provides more standardization, Devicetree is preferred in many + 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. + However, EBBR does require the system description to be supplied by the + platform, not the OS. + The platform must also conform to the relevant ACPI or DT specifications and + adhere to platform compatibility rules. [#CompatRules]_ + +.. [#CompatRules] It must be acknowledged that at the time of writing this + document, platform compatibility rules for DT platforms are not well defined + or documented. + We the authors recognize that this is a problem and are working to solve it + in parallel with this specification.
- Focus on the UEFI interface, not a specific codebase
@@ -112,10 +121,20 @@ process:
- 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. - - However, existing compliant boards will remain compliant. + The v1.0 release of EBBR is firmly targeted at existing platforms so that + gaining EBBR compliance may require a firmware update, but will not require + hardware changes for the majority of platforms. + + Future EBBR releases will tighten requirements to add features and improve + compatibility, which may affect hardware design choices. + However, EBBR will not retroactively revoke support from previously compliant + platforms. + Instead, new requirements will be clearly documented as being over and above + what was required by a previous release. + Existing platforms will be able to retain compliance with a previous + requirement level. + In turn, OS projects and end users can choose what level of EBBR compliance + is required for their use case.
Scope =====
On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely 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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org
Reviewed-by: Daniel Thompson daniel.thompson@linaro.org
source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
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-discuss@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.
-The following guiding principals of the EBBR specification and its -process: +The following guiding principles are used while developing the EBBR specification.
- 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.
- While ACPI provides more standardization, Devicetree is preferred in many
- 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.
- However, EBBR does require the system description to be supplied by the
- platform, not the OS.
- The platform must also conform to the relevant ACPI or DT specifications and
- adhere to platform compatibility rules. [#CompatRules]_
+.. [#CompatRules] It must be acknowledged that at the time of writing this
- document, platform compatibility rules for DT platforms are not well defined
- or documented.
- We the authors recognize that this is a problem and are working to solve it
- in parallel with this specification.
- Focus on the UEFI interface, not a specific codebase
@@ -112,10 +121,20 @@ process:
- 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.
- However, existing compliant boards will remain compliant.
- The v1.0 release of EBBR is firmly targeted at existing platforms so that
- gaining EBBR compliance may require a firmware update, but will not require
- hardware changes for the majority of platforms.
- Future EBBR releases will tighten requirements to add features and improve
- compatibility, which may affect hardware design choices.
- However, EBBR will not retroactively revoke support from previously compliant
- platforms.
- Instead, new requirements will be clearly documented as being over and above
- what was required by a previous release.
- Existing platforms will be able to retain compliance with a previous
- requirement level.
- In turn, OS projects and end users can choose what level of EBBR compliance
- is required for their use case.
Scope ===== -- 2.13.0
On 07/09/2018 08:17 AM, Grant Likely 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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org
Reviewed-by: Bill Mills wmills@ti.com
-- Thanks, Bill
source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
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-discuss@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.
-The following guiding principals of the EBBR specification and its -process: +The following guiding principles are used while developing the EBBR specification.
- 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.
- While ACPI provides more standardization, Devicetree is preferred in many
- 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.
- However, EBBR does require the system description to be supplied by the
- platform, not the OS.
- The platform must also conform to the relevant ACPI or DT specifications and
- adhere to platform compatibility rules. [#CompatRules]_
+.. [#CompatRules] It must be acknowledged that at the time of writing this
- document, platform compatibility rules for DT platforms are not well defined
- or documented.
- We the authors recognize that this is a problem and are working to solve it
- in parallel with this specification.
- Focus on the UEFI interface, not a specific codebase
@@ -112,10 +121,20 @@ process:
- 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.
- However, existing compliant boards will remain compliant.
- The v1.0 release of EBBR is firmly targeted at existing platforms so that
- gaining EBBR compliance may require a firmware update, but will not require
- hardware changes for the majority of platforms.
- Future EBBR releases will tighten requirements to add features and improve
- compatibility, which may affect hardware design choices.
- However, EBBR will not retroactively revoke support from previously compliant
- platforms.
- Instead, new requirements will be clearly documented as being over and above
- what was required by a previous release.
- Existing platforms will be able to retain compliance with a previous
- requirement level.
- In turn, OS projects and end users can choose what level of EBBR compliance
- is required for their use case.
Scope =====
Hi Grant,
On 9 July 2018 at 06:17, Grant Likely grant.likely@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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org
source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
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-discuss@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?
Regards, Simon
On 11/07/2018 21:13, Simon Glass wrote:
Hi Grant,
On 9 July 2018 at 06:17, Grant Likely grant.likely@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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org
source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
Reviewed-by: Simon Glass sjg@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-discuss@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. :-)
g.
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.likely@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.likely@arm.com Cc: Bill Mills wmills@ti.com Cc: Alexander Graf agraf@suse.de Cc: Daniel Thompson daniel.thompson@linaro.org
source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-)
Reviewed-by: Simon Glass sjg@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-discuss@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@lists.linaro.org
-
Alexander Graf -
Daniel Thompson -
Grant Likely -
Simon Glass -
William Mills