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