EBBR Notes 2020.11.25
- Ilias Apalodimas (Linaro)
- Grant Likely (Arm)
- Mark Brown (Arm)
- Daniel Thompson (Linaro)
- Vincent Stehlé (Arm)
- Jose Marinho
- Bill Mills
- Atish
- Heinrich
- Samer
- Issue & PR review
- UEFI Requirements Section
- Round table
- Any other business
-
RISC-V (#57 and #56): Should it wait for the SystemReady changes to land? Arm specific items on exception levels will move out of BBR. No need to wait though, RISC-V will not have equivalent of BBR so carrying these in EBBR is not a problem (unless it is duplicative w.r.t. other RV standards).
-
RISC-V (#57 and #56): Patch will be reposted by authors for (hopefully) final review
-
Storage location of device tree files (#58): Assign to Bill M, want to have way for bootloaders to alter non-firmware owned DT (which is not currently in scope for EBBR... but could be).
-
Others: No news...
Grant has added draft text to the wiki: https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols
Plan to overide some of the requirements in UEFI 2.6 (in order to relax them). Describing the differences proved to be difficult so the strategy taken is to write a replacement for all of 2.6.
Summary is to relax the general requirements that are not currently implemented in u-boot (since that implies systems can be useful without it) and to drop almost all platform-specific elements (which are mostly conditional: if the device has XXX then YYY).
For all relaxations we'd like to include reasons in EBBR that we can use to justify both EBBR and any derived certificatons.
Contentious during review:
- GET_NEXT_HIGH_MONO_TIME (runtime) - looks like this cannot be required by EBBR since we do not want to require anything to be persisted post boot.
- GET_TIME/SET_TIME and friends - can be implemented using a virtual RTC but it is not clear that this is useful enough to be mandatory (since it is usually added to get SCT passes)
Actions:
- All: Review via collaborative editing (or note/questions at to the bottom if you don't want to make unilateral changes) of the wiki page for next two weeks, then Grant will convert the proposal to patch and publish for secondary review.
- u-boot (?Heinrich?): consider whether it is "right" to relax load image protocol support in EBBR or to implement it in u-boot
- Unspecified: Revisit EFI_RUNTIME_SERVICES table
Heinrich:
- ConnectController() in U-Boot does not yet implement support PlatformOverrideProtocol, DriverFamilyProtocol and BusOverrideProtocol. As U-Boot does not make much use of UEFI drivers this may be justified.
- LoadImage() in U-Boot does not yet support the LoadFileProtocol and the LoadFile2Protocol. Implementing these does not seem too difficult. At least iPXE could make use of LoadFileProtocol.