On 26.04.18 18: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?
Depends on what your definition of persist is :). U-Boot can run an EFI application that can register protocols. These protocols do not disappear after the application closed. > If yes, Can it persist just until ExitBootServices or can it persit to > runtime time as well? An application can register memory as runtime memory and install something there. I'm not sure what the best way would be to actually make it callable though. > >>>> >>>>> >>>>> 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 In this case you also want to have an indication to the OS that while variables exist, writes do not work. > 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? U-Boot supports storing its environment in a file on a partition. And since the UEFI environment is part of the U-Boot environment, persistence works the same way. Keep in mind that the persisting code path does not exist yet today though. U-Boot only knows how to save *all* of its current environment. To persist UEFI variables we would need to add functionality to only save the UEFI variables in the environment, but not the U-Boot ones. Alex _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
