On 26/04/2018 17:52, William Mills wrote:
On 04/26/2018 08:43 AM, Alexander Graf wrote:
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".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
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.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
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
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
- A system where Sets and Gets work and are persisten
I've had a bit more of a think about this, and I would like to propose a different list. First, I think we should require that GetVariable() always works, and it should match whatever was in the UEFI variables during boot services. This should not be onerous to implement for anyone as it only requires the variables to be preserved in a UEFI memory region.
I also think I too quickly discounted systems where SetVariable() never works. HiKey for instance falls into that category. Maybe we still need to support that for EBBR.0
New list of systems to be prepared for: 1) SetVariable() never works (return EFI_WRITE_PROTECTED?) 2) SetVariable() only works at boot time (return EFI_WRITE_PROTECTED at runtime?) 3) SetVariable() works at both boot and runtime
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough
I think that's fair. non-persistant SetVariable() pulls in a lot of questions about what the reboot behaviour needs to be, so I'd like to punt it out to the EBBR.1 (liking the EBBR.# terminology BTW)
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
I think this fits into the new list described above. If firmware uses uEnv.txt, then SetVariable() should only work if firmware is able to update that file. Otherwise return an error (again, proposing EFI_WRITE_PROTECTED as above, but open to suggestions).
g.
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.