On 07/05/2018 11:00 AM, Daniel Thompson wrote:
On Thu, Jul 05, 2018 at 09:17:59AM -0400, Bill Mills wrote:
Tell people what to expect from EBBR in easy bullet form.
Signed-off-by: Bill Mills wmills@ti.com
source/chapter1-about.rst | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 125e400..83c682f 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -18,6 +18,46 @@ while leaving plenty of room for innovations and design details. This specification is intended to be OS-neutral. It leverages the prevalent industry standard firmware specifications of UEFI. +Guiding Principals
s/Principals/Principles/
+==================
+The following are the guiding principals of the EBBR specification and its +process:
Stating the guiding principles seems like a good way to help potential contributors understand the scope of EBBR.
+- DeviceTree or ACPI
- Describes the hardware and firmware to the OS
+- UEFI interface, not a specific codebase
- Can be implemented by U-Boot or Tianocore/EDK2 or others
EBBR is a fairly narrow subset of UEFI and this section doesn't really communicate that.
Maybe something like:
Loads and runs UEFI applications (including OS bootloaders)
Does not require a fully featured UEFI implementation; can be implemented by u-boot or Tianocore/EDK2 or others
OK, that looks fine to me
+- Implementable and useful today
- EBBR is always defined so that current U-Boot can implement the requirements
+- OS independant
- This document may use Linux as an example but other OS's are expected
+- Multiple Architectures
- This document addresses AArch64 today but AArch32 and others are expected
+- Is designed with Embedded Hardware in mind
- Works on today's boards
- Simple low cost hardware recommendations for tomorrow's boards
Can we remove "hardware" here?
Sure
- Is appropriate for boards < $10
+- Will evolve
- Future versions will add capabilities and may tighten hardware requirements
Again... we have scope to tighten more than just hardware requirements.
Yes, but it is the HW changes that will cause the biggest concern. The existing board HW & Firmware will remain compliant to the old level. If the vendor changes the firmware she may be able to achieve compliance to the new level (new features etc) but will not have to meet the requirements for "new hardware".
Some of the issue here is we don't talk about levels yet.
I guess until we do I will just simplify as you suggest.
- However, existing compliant boards will remain compliant
ALSO:
I won't add a bullet for CI
What I got out of the exchange between Grant & Alex is don't talk about CI at all until we are better prepared. It can always be added later.
Thank, Bill