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 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.

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?

Thanks,
Bill
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to