I'm resending these notes to the list because the boot-architecture list rejected it the first time around. Resending so it appears in the archive.
g.
---
Hi folks,
At Linaro Connect in Hong Kong this week there has been some EBBR (Embedded Base Boot Requirements) discussions. One of the interesting angles that came up is that the 96Boards project would like to specify EBBR in an upcoming specification, so they need EBBR to be published and realistic. The Fedora and SuSE representatives are very supportive of that notion, because it gives them a path to support boards conforming to that spec. A few of us here had a quick meeting to work out how we could make that happen.
Attendees: Alexander Graf (SuSE) Grant Likely (Arm) Bill Mills (TI) Peter Robinson (Red Hat/Fedora) Dong Wei (Arm) Yang Zhang (Linaro/96Boards)
Notes: - We discussed the purpose & intent of EBBR - Is intended to document the basic requirements on firmware to implement a 'standard' boot path on embedded boards. - Needed by distros (Fedora, SuSE, Debian, etc) to support boards out of the box - Needed by OpenEmbedded, Yocto, etc to get away from custom platform specific hacks - Establishes a foundation for implementing SecureBoot, A/B updates, and other useful boot scenarios in a consistent way. - We expect the primary users of EBBR will be embedded & developer Arm boards using U-Boot firmware and Devicetree machine description - We expect a distribution will be able to use the same software (Distro Installer, Grub, Linux UEFI stub, Shim), and the same media (installer images) on both embedded and server platforms
- We discussed what EBBR should contain - Will document interfaces and standards; not specific projects - Will specify a subset of the UEFI specification. - Boot services are in - Runtime services can be implemented with empty stubs - Need to work out what to do with runtime setting of variables - For the first release ("EBBR level 0"), it will track features available in upstream - In concrete terms this means EBBR can be implemented with upstream U-Boot or Tianocore. - Subsequent releases will refine the requirements as needed and as software improves
- Expected target audience - embedded board vendors - Gives strong guidance on how to make a widely supported board - Linux distributions - Can make EBBR compliance a requirement for support - End users - EBBR will make it simpler to use embedded Arm boards because each board will not require special setup instructions or image formats
- Roadmap - 96Boards wants to specify EBBR compliance in an upcoming spec to be announced at Linaro Connect in the fall (about 6 months time) - Need to have general agreement on the content of EBBR well before that (2-3 months?) - Need to have a final EBBR 1.0 release before the 96Boards spec announcement - Work items: - Transcode existing EBBR draft into text markup and check into Git repo - Review current EBBR draft and compare with available U-Boot functionality - Identify changes required to EBBR spec - Identify gaps in U-Boot functionality that can reasonably be ad
Open Questions: - Can the EBBR document be drafted in public? (Dong to follow up internally at Arm) - Where do the Engineering resources come from to make EBBR a reality - General call for engineering effort to be committed by interested parties
Actions: - Dong to have Arm internal discussion about moving EBBR draft process onto GitHub or similar - Markup candidate: Sphinx-doc with reStructuredText markup - Grant to organize a regular weekly meeting to track EBBR drafting process - Make sure to include Tom Rini and Ard Biesheuvel - Yang to socialize with 96Boards partners to prepare them for EBBR compliance - (Unassigned) Create a hosting page with issue tracker for EBBR -- TBD after Dong finishes internal due diligence on moving EBBR drafting to a public repository - Probably GitHub