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:
1) A system that returns ERROR for Gets and Sets
2) A system that returns ERROR for Sets but Gets works
3) 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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
