On Fri, Apr 27, 2018 at 11:22:27AM +0100, Grant Likely wrote: > On 26/04/2018 17: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? > > 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 persisten > > I've had a bit more of a think about this, and I would like to propose a > different list. First, I think we should require that GetVariable() > always works, and it should match whatever was in the UEFI variables > during boot services. This should not be onerous to implement for anyone > as it only requires the variables to be preserved in a UEFI memory > region. > > I also think I too quickly discounted systems where SetVariable() never > works. HiKey for instance falls into that category. Maybe we still need > to support that for EBBR.0
That sounds rather close to circular logic. Boards that don't implement working SetVariable() today, do so because there was no really much compelling reason to support SetVariable() from UEFI apps; in other words there were no UEFI apps (that the vendor cared about) that actually needed it. Based on the what we were talking about a couple of weeks back we don't want EBBR to be aspirational. I agree with this but didn't we define "not aspirational", at least approximately, as only specifying features that: 1. Can be implemented in u-boot before we ship, and realized on a reference platform 2. Can be implemented in EDK2 before we ship, and realized on a reference platform 3. Are not known to be impossible to implement on existing hardware (we might not get this 100% correct... but across the current people involved we have a good deal of experience) Cataloguing current behaviour (of hikey or any other board) doesn't fit with they above. Looking at this a different way EBBR might be interested in formalizing de-facto standard approachs but IMHO its only a de-facto standard when it is common on firmware side *and* commonly exploited on the distro side. > > 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 think that's fair. non-persistant SetVariable() pulls in a lot of > questions about what the reboot behaviour needs to be, so I'd like to punt > it out to the EBBR.1 (liking the EBBR.# terminology BTW) I agree here, there simply is not much prior art w.r.t. firmware that carries volatile data across a reset, that makes it risky for level 0. > > 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? > > I think this fits into the new list described above. If firmware uses > uEnv.txt, then SetVariable() should only work if firmware is able to update > that file. Otherwise return an error (again, proposing EFI_WRITE_PROTECTED > as above, but open to suggestions). Going back to the numbered list above, there is a huge different between not-implemented and not-implementable. We should be careful reasoning from the former. Sure u-boot ports exist without comprehensive driver support... ironically these are likely to be more common for systems that rely heavily on the u-boot distro boot protocol since the protocol gets close to eliminating the need for persistent runtime-modifiable variables. Daniel. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
