On Thu, Apr 26, 2018 at 12:52:04PM -0400, William Mills wrote:
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.)
Yes. This statement was based on my incorrect assumption that we were permitting systems without any persistent variable storage in the first revision of the spec. (As opposed to only systems that did not provide persistent variable storage at runtime.)
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 persistent
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.
Well, I was arguing for supporting that in EBBR.0 (since that matches the behaviour of some EDK2 ports), but I don't think that is something we would like to _add_ to EBBR.1 if it is not supported by EBBR.0.
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?
Yes, this was the reason for my last request for clarification. And the view was that such systems will not be compliant with any version of the spec.
/ Leif