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.

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-discuss@arm.com