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
