See below.
As I have said before, I like a document that has examples. We all have traded example use cases and platforms to make our points about what should and should not be required. That should not be left embedded deep in mail archives. Instead we should give the spec reader the same benefit of understanding.
The examples of course would not be binding as requirements or even recommendations. They are only to give deeper understanding of the motivation.
On 05/21/2018 08:59 AM, Grant Likely wrote:
I've been thinking about how to organize EBBR. It started matching the SBBR document structure with the ACPI & ACPI sections removed, but I've moved things around a bit (for instance, citations are now at the end and use the citation markup so they can be collected from the whole document.) We also want to talk about some device sharing issues that SBBR doesn't need to get into, so we need a place to put that stuff.
For discussion, what do you think of the following Table of Contents? I do expect this to change, but I'd like to come to general agreement on how the document is structured.
- About this Document
1.1 Introcution 1.2 Scope
- UEFI
2.1 UEFI Version 2.2 UEFI Compliance 2.3 UEFI System Environment and Configuration 2.4 UEFI Boot Services 2.4.1 Required (Moved from Appendix to here) 2.4.2 Optional (this section may be redundant. If it isn't required, then by default it is optional!!) 2.5 UEFI Runtime Services 2.5.1 Required 2.5.2 Optional
- System Configuration Data
3.1 Devicetree 3.2 ACPI
- Privileged Firmware
4.1 PSCI 4.2 Secure Services
- Hardware Configuration and Access
5.1 Shared Storage Media 5.1.1 Block device partitioning 5.1.2 Protecting firmware partitions/blocks 5.2 Shared access (i2c/SPI) 5.3 RTC
I like these 5.* sections. A specific section to discuss the various points of a specific concept. This is much better than trying to make some of those points in the UEFI requirements/recommendation sections. This allows the UEFI sections to be fairly dry and crisp.
(Everything below is additional guidance material, and doesn't make up part of the spec. I've not decided if I'd rather have it in the documentm, or as a separate guidance note) Appendix A - U-Boot implementation note (How to configure U-Boot to be EBBR compliant) Appendix B - EBBR Compliance Testing
Appendix C - Example Platforms
Non binding example platforms to illustrate some of the concepts. Pick two or maybe three to best illustrate various situations. Example examples: * Dedicated firmware storage, Embedded OS storage, and removable media (PC like) * Single Embedded storage and no removable storage but network access
Appendix D - Example Use cases
* Daniel's example of OS installer image on removable media or network "iso" that then installs to embedded storage (or a different removable storage)
* EBBR Noob * Platform specific OS image * Platform recovery image (not bound by EBBR)