# 26 April 2018
## Attendees
* 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)
## Agenda
* Action item review
* Behaviour without persistent variables
* DTB Update policy/behaviour
* Any other business
## Notes
### Action item review
* 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
### Behaviour without persistent variables
* 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](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?
### Any other business
* 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
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
