On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
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####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
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.
Currently the "bootefi bootmgr" command only implements "BootOrder".
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. /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.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex