EBBR Notes 2024.02.12

Attendees

Pull request #115: Bump PSCI + recommend >= 1.0: approved. Next step is to look at SMCCC.
Heads up on upcoming work on A/B update from SysArchAc IoT: may or may not impact EBBR, certainly UEFI.
Support for OS provided DTBs: next steps towards a standard solution: present ideas to reach agreement, push what makes sense to UEFI and EBBR.

Pull request #115: Bump PSCI + recommend >= 1.0
- TRNG in TF-A, SMCCC version, discovery. There is a feature discovery in PSCI starting with 1.0. In that case, one can use the SMCCC feature discovery as well. Link with PSCI is specified in SMCCC version.
- Next: clarify required SMCCC version (>= 1.1?).
- Would be nice to have at least the SMCCC features discovery. Which version for TRNG?
- Agreed.
Heads up on upcoming work on A/B update from SysArchAc IoT
- Capsule update, potential impact to UEFI. EBBR might "just" have to follow UEFI versions, or maybe recommend/require more.
Support for OS provided DTBs
- What are the next steps? Do not diverge from UEFI.
- Fedora for example supplying DTBs in a specific location on disk; expect firmware to look there.
- For firmware supplied devicetree, capsule update. For OS devicetree, need to know the platform. U-Boot case: load dtb from ESP at known per-platform location, not specified in UEFI.
- Standard boot flow, UEFI boot manager with U-Boot, no code to look for ESP and a devicetree. Only uses U-Boot Devicetree. The UEFI recovery boot path with bootefi is looking for a <board_name>.dtb.
- U-Boot specific behaviour, which highlights that UEFI & EBBR have not standardized this aspect.
- Jon will present further ideas to this forum.