Give some rationale behind EBBR so the reader understands what problem the specification is intended to solve.
Signed-off-by: Bill Mills wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com --- 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-discuss@arm.com.
+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. + +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. + 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: + +- 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. + + However, existing compliant boards will remain compliant. + Scope ===== This document defines the boot and runtime services that are expected by an
Very nice Grant. At some point we should make this into a blog or whitepaper. It is important to explain the rational behind any specification effort, I am glad to see EBBR taken a step in that direction.
- DW - -----Original Message----- From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of Grant Likely Sent: Friday, July 6, 2018 9:26 AM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Cc: nd nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH] Introduction: add a manifesto
Give some rationale behind EBBR so the reader understands what problem the specification is intended to solve.
Signed-off-by: Bill Mills wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com --- 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-discuss@arm.com.
+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. + +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. + 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: + +- 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. + + However, existing compliant boards will remain compliant. + Scope ===== This document defines the boot and runtime services that are expected by an -- 2.13.0
_______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@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-discuss@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
On Fri, Jul 06, 2018 at 01:28:20PM -0400, William Mills wrote:
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@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-discuss@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.
I'm hardly the world's best speller but this one is burned into my brain because I used the wrong one on my CV for a period of time...
Daniel.
+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 _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 06/07/2018 18:28, William Mills wrote:
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com
Don't know the protocol but signed-off-by and/or reviewed-by me again.
Normally I'd add another reviewed by tag for you because I added a significant amount of text, where s-o-b only tracks the authorship chain. However, since I've already committed the change I'll merely make a note in the commit text of the fixup.
+Guiding Principals +==================
s/Principals/Principles/
You carried forward my mistake. Daniel correctly pointed out that we are not talking about a helpful person.
Oops!
+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.
Good catch. Fixed.
+- 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.
I'll read Daniel's comments and then respond from there.
- However, existing compliant boards will remain compliant.
Scope
This document defines the boot and runtime services that are expected by anYes, I like your enhanced version much better and it still has all the points I wanted to make.
Thanks for the quick review.
g.
On Mon, Jul 09, 2018 at 12:07:18PM +0100, Grant Likely wrote:
On 06/07/2018 18:28, William Mills wrote:
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com
Don't know the protocol but signed-off-by and/or reviewed-by me again.
Normally I'd add another reviewed by tag for you because I added a significant amount of text, where s-o-b only tracks the authorship chain. However, since I've already committed the change I'll merely make a note in the commit text of the fixup.
+Guiding Principals +==================
s/Principals/Principles/
You carried forward my mistake. Daniel correctly pointed out that we are not talking about a helpful person.
Oops!
+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.
Good catch. Fixed.
+- 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.
I'll read Daniel's comments and then respond from there.
I'm not sure I fully articulated reasoning in the thread...
Basically there is no limit on *where* (hardware, firmware, OS) we might choose to tighten requirements are we rise through the levels and learn from whatever mistakes we are currently making. Thus it seems odd to privilege hardware requirements over other forms of requirement.
Daniel.
- However, existing compliant boards will remain compliant.
Scope
This document defines the boot and runtime services that are expected by anYes, I like your enhanced version much better and it still has all the points I wanted to make.
Thanks for the quick review.
g. _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 09/07/2018 12:18, Daniel Thompson wrote:
On Mon, Jul 09, 2018 at 12:07:18PM +0100, Grant Likely wrote:
On 06/07/2018 18:28, William Mills wrote:
+- 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.
I'll read Daniel's comments and then respond from there.
I'm not sure I fully articulated reasoning in the thread...
Basically there is no limit on *where* (hardware, firmware, OS) we might choose to tighten requirements are we rise through the levels and learn from whatever mistakes we are currently making. Thus it seems odd to privilege hardware requirements over other forms of requirement.
fair enough, I've refined the text and alreadly posted it to the list.
g.
+1
On Fri, Jul 6, 2018, 5:26 PM Grant Likely grant.likely@arm.com wrote:
Give some rationale behind EBBR so the reader understands what problem the specification is intended to solve.
Signed-off-by: Bill Mills wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com
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-discuss@arm.com.
+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.
+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.
- 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:
+- 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, butAArch32 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.
- However, existing compliant boards will remain compliant.
Scope
This document defines the boot and runtime services that are expected by an -- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com
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-discuss@arm.com. +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
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 wmills@ti.com [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely grant.likely@arm.com
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-discuss@arm.com. +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@lists.linaro.org
-
Alexander Graf -
Daniel Thompson -
David Rusling -
Dong Wei -
Grant Likely -
William Mills