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