-
Notifications
You must be signed in to change notification settings - Fork 36
EBBR Notes 2018.04.26
- Abner Chang (HPE)
- Palmer Dabbelt (SiFive)
- Andreas Färber (SUSE)
- Alex Graf (SUSE)
- Ryan Harkin (Linaro)
- Rob Herring (Linaro)
- Udit Kumar (NXP)
- Grant Likely (Arm)
- Leif Lindholm (Linaro)
- Bill Mills (TI)
- Tom Rini (Konsulko)
- Michal Simek (Xilinx)
- Daniel Thompson (Linaro)
- Dong Wei (Arm)
- Action item review
- Behaviour without persistent variables
- DTB Update policy/behaviour
- Any other business
- Relicense and publish EBBR
- Slipped by one week per week (progress as been made… but wheels still need to turn)
- Github repo
- Complete but cannot be published until relicensing action (above) is complete
- Policy for sharing HW between firmware and OS
- NTR, next week
- Handling platforms without persistent variables
- Proposed text shared on mailing list
-
Grant: Role of EBBR. It interprets UEFI and it restricts UEFI (by implication to things supportable in u-boot)
-
Alex:
- Current code in SUSE depends on no variables presented if persistent variables are not supported
- would return device error for EBBR level 0 on GetVariable()
-
Leif: Need plan for read-only variable implementation
-
Daniel/Grant: No flag day. EBBR level 0 OS must be able to run on EBBR level 1 firmware. Makes above problematic.
-
Bill: No get/set, Get but not set, get/set-temporary, get/set-persisent
-
Daniel: Let's ban get/set-temporary
-
Leif: get/set-temporary exists in the wild (is it OK for such systems to be non compliant.
-
Identified scenarios:
- No get/set
- Get, but no set
- Get & Set, but Set does not persist
- Get & Set fully works
-
Use case 1:
- Distro needs to decide how to install itself
- Either using variables (standards compliant) or like removable media
-
Use case 2:
- Use non-persistent variables to alter boot order and allow the variable to survive, in RAM, through the OS and firmware reset and allow it to select the next kernel to be booted
- Bill/Daniel: Distros already have a tool that can achieve similar use-case (grub) and this is a property of the distro not a property of EBBR
- Grant: https://cateee.net/lkddb/web-lkddb/EFI_BOOTLOADER_CONTROL.html (not full variable support, simply a means to pass a single message bootloader, good for A/B style updates and temporary diversions of kernel under dirtect)
-
Leif:
Boot manager behaviour without persistent variable store ======================================================== Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI. Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####, Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables. Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in[ http://uefi.org/registry](http://uefi.org/registry). /BOOT must not be used except where explicitly permitted by UEFI. Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed. Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used. [1] This is worth discussing, but if we were to support dynamic creation of these, we need _very_ strict rules around it._ -
Grant: What are the scenarios/use-cases enabled by the statically defined image support, etc.
-
Leif: Is this images exists then I want to run it on boot, update configuration tables, etc.
-
Grant: Need concrete use-cases, could ban these variables from existing unless user interferes/hacks with the bootloader (e.g. u-boot has persistent variables… its just that we cannot set them at runtime)
-
Grant: Can/should an EFI application be able to set variables persistently (or temporarily)? (for example configuring network booting parameters during initial commissioning)
-
Summary:
- We follow UEFI spec w.r.t variables
- Boot, OSRecover, etc variables ship undefined
- Fallback to removable media boot in the absence of boot variables
- Didn't catch the last one!
-
Leif: Did we get agreement to require that variables be persistent but only if they are set from boot services?
- Capsule update and other runtime variables
- Udit: Is this optional? Like persistent variables.
- Leif: Yes, in first version we should make this optional for similar reasons to persistent variables
- Leif: We want the runtime services to be supported long term, so we focus on optionality on a case by case basis rather than ruling them all out wholesale
- Grant: Runtime services are not optional… we are simply allowing them not to work (return failed)
- Udit: Also wants get/set long term