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 <wmi...@ti.com> > > > [glikely: made it more verbose to make the intent clear] > > > Signed-off-by: Grant Likely <grant.lik...@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 an > > > > > > > Yes, 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-disc...@arm.com _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
