EBBR Notes 2021.01.18

EBBR Meeting Notes - 18 Jan 2021

Attendees

• Ilias Apalodimas (Linaro)
• Grant Likely (Arm)
• Joakim Bech (Linaro)
• Mark Brown (Arm)
• Daniel Thompson (Linaro)
• Vincent Stehlé (Arm)
• Jose Marinho
• Bill Mills
• Heinrich Schuchardt
• Reed Hinkel
• Matthias Brugger
• Francois Ozog

Agenda

• Update on specific required protocols
  • https://github.com/ARM-software/ebbr/issues/60
  • https://github.com/ARM-software/ebbr/issues/61
  • https://github.com/ARM-software/ebbr/issues/64
• Firmware update requirements
  • https://github.com/ARM-software/ebbr/issues/69
• DT fixup protocol proposal
  • https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
  • https://github.com/ARM-software/ebbr/issues/68
• UART/Console requirements
• Initrd passing
• Next release of EBBR
• Other business

Notes

Update on specific required protocols

• Wiki now has "a good list of required protocols" (https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols ).
• Largely based on what is implemented in u-boot at present.
• Reviewed current wiki page during meeting and updated
• Is "if platform has" right for embedded file and network protocols (where we are based on use-cases rather than hardware cpability)? Replace with "if platform supports booting".
• Pre-reviewed a patch Grant is working on... will be shared as a patch for wider review (in particular, Grant plans to poke some of the distro folks for comments)
• Q: What is meant by a "graphics console"? It is meant to include splash screens or does it imply the firmware is graphically interactive. Deferred discussion on this.

Firmware update requirements

• Grant has shared a patch with initial proposals to require EBBR systems to provide (mandatory) firmware update.
• Currently proposal splits between in-band (capsule update and ESRT table for fwupd/Win32/... to use, boot services only) and out-of-band (BMC) without recommendation on which to adopt.
• u-boot currently has patches (landed or pending) for much of this... but ESRT support is not there yet
• Q: Should we make support for capsule updates mandatory (e.g. require in-band update support)?
• Q: Should we present in-band and out-of-band updates as equal choices (out-of-band updates can be met with a nerve pinch during reboot and a USB stick... this is not comparable to proper in-band updates). As minimum we will tighten the language so if in-band is implemented it must be capsule based.
• This provoked quite a bit of discussion... which had be stoped to make space for the rest of the agenda

DT fixup protocol proposal

• Motivation by the way Linux device-trees tend to be neither forward nor backwards compatible
• Want to provide a mechanism for grub to deliver a DT matched to the kernel... and provide an EFI protocol to fixup that DT with runtime info (reserved memory,
• https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL (+ presentation https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL/blob/master/presentations/EFI_DT_FIXUP_PROTOCOL.pdf )
• Q: Is this a good fit for EBBR (and have EBBR committee members been reviewing the proposal)?
• u-boot already does apply fixups but without a specification
• Q: How does the fixup protocol handle errors (e.g. missing nodes, etc, etc)? Still open...

UART/Console requirements

• Q: Should EBBR mandate platforms (where is makes sense) to provide OS with clear indiciation of what console to use?
• Arguably a rquirement of SystemReady (can't boot two unmodified OS if they can't find a console)
• DT provides an approach (chosen stdout)
• ACPI does not provide any equivalent (PCs have EFI framebuffer ;-) )
• SBSA/SBBR provides a strong lead here w.r.t. ACPI (must have NS16550A or PL011 and there is a table to identify a console)
• No objections but details need to be fleshed out (please continue via e-mail, fzog thread)

Initrd passing

Not reached. Deferred to next meeting.