BKK16-411 Devicetree Specification
0 likes766 views
The document outlines a proposal for creating an open, vendor-neutral device tree specification to reduce fragmentation and enhance coherence across architectures in hardware description. It details the initiative's goals, a phased timeline for implementation, and the establishment of an interim committee to manage the process. Membership is structured to foster contributions while ensuring sustainability and governance, allowing companies to engage actively in the evolution of the specification.
BKK16-411 Devicetree Specification
- 1. Presented by Date Event Devicetree Specification Kanta Vekaria and Grant Likely BKK16-411 March 2016 Linaro Connect BKK16
- 2. Introduction ● Devicetree ○ Well established data structure to describe HW ○ Widely used in Linux and other communities ● But we need to ensure: ○ Efforts are not fragmented (Kernel vs U-Boot vs BSD) ○ Definitions and usage are coherent across device/architectures ○ Best practices are applied and adhered to ● How? ○ Through a vendor neutral, portable and open devicetree specification
- 3. Goals To reduce fragmentation, improve maintainability and increase multiplatform support in hardware description. To build on existing device tree standards and documentation to reflect the current best practices and technology. This standard will be supported by an open process that encourages wide community participation and industry support.
- 4. Guiding Principle The initiative will operate transparently, openly and collaboratively. The proposals, timelines, and status of the specification must not merely be open, but also easily visible to non-members.
- 5. Technical Goals ● Create new specification which reflects current practice ○ ePAPR needs replacing. It is out of date and stuck behind a clickthrough ○ Need to add ARM architecture bindings ○ Move core details out of the Linux tree and into a common document. ● Place to capture new features ○ GPIO, Clocks, Regulators, IOMMU, etc ○ Overlays for extending DT ● Coordinate spec work with new tooling ● Collaboration between projects ○ FreeBSD ○ U-Boot ○ UEFI ○ OpenPOWER
- 6. Proposed Approach ● New organization to manage specification ○ Funded by membership ○ Steering committee makes Governance decisions ○ Hosted by Linaro ● Open by default ○ Open mailing lists ○ Participation does not require membership ● Developer-friendly workflow ○ Master documents in git tree ○ Post patches to mailing list to propose changes
- 7. High-Level Timeline Jan ‘17Jan ‘16 May ‘16 Sept ‘16 Phase 1 Initialisation: Spec write up, Interim SC, Hosting Phase 2 Evolution: Spec new features, Governance, Roles and Community Awareness Phase 3 Official Launch: Operational mode, Formal SC, new Members Release 1 Release 2 Release 3
- 8. Phase 1 ● Setup small interim committee ○ Linaro: Grant, Kanta, Rob ○ ARM: Charles Garcia-Tobin, Mark Rutland ○ NXP: Stuart Yoder ○ IBM: Jeff Scheel, Stewart Smith ● Get agreement for Linaro to host and license the specification ○ Determine licensing for released documents ○ Contribution agreements in place ● Setup mailing lists and web presence - www.devicetree.org ● Release 1 - April ○ ePAPR reorganised ○ No new content ○ Plan for Release 2 ● Raise community awareness: TSC, BKK Session
- 9. Phase 2 ● Finalise: ○ Membership Model ○ Committee roles and rules ○ Operational Processes ● Release 2 - August ● Open to join ● Raise community awareness: Soft Press Release
- 10. Phase 3 ● Transition from interim to formal SC ● Release 3 - December ● Launch Press Release ● Raise community awareness: ○ Conferences: ELC, Collaboration Summit, etc ○ Other communities ■ FreeBSD, U-Boot, UEFI, Xen, OpenPOWER
- 11. Expected Technical Content ● Current core bindings missing from ePAPR ○ ARM Architecture Bindings ○ GPIO ○ Regulators ○ Clocks ○ Pinmux ● Features currently in progress ○ Overlays ○ Schema language and checking ● Future Features ○ “append” format for binary blob ○ Portable overlays
- 12. Proposed Roles ● Establish a Technical Steering Committee ○ Chair ○ Vice-Chair ○ Technical Writer ○ Administrator (organisational role) ○ Member representatives - one per member
- 13. Why is membership needed? ● To keep the specification alive in the longer term ● To fund the process to maintain it ● To allow companies to have a stake in it ● To show a sense of ownership and confidence in the specification process ● To make and influence decisions about releases and patches
- 14. Proposed Membership Model ● Anyone can contribute/participate ○ No membership is required ● Members get a seat on the steering committee ○ Governance issues ○ Release schedule ○ Due diligence review ● Membership fees: ○ Corporate Members: Flat Annual membership ○ Individuals: By invitation - no fee
- 15. devicetree.org ● Ownership to be transferred to Linaro ● Point to latest documents, mailing lists, etc
- 16. Open Questions ● Contribution Agreement? ○ Probably DCO process as by Linux kernel ● Document license, which one? ○ Apache V2 ● Bring in more interim committee members?