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?
g.
Alex
[1] This is worth discussing, but if we were to support dynamic
creation of these, we need _very_ strict rules around it.
_______________________________________________
Arm.ebbr-discuss mailing list
arm.ebbr-disc...@arm.com
_______________________________________________
Arm.ebbr-discuss mailing list
arm.ebbr-disc...@arm.com
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
