I am behind this topic and not familiar with embedded system with U-boot. Some dumb questions below. Why there is no persistent storage on platform? I thought at least EEPROM is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write. And what is the problem that U-boot can't support SetVariable invoked by OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the implementation in EDK2 EFI variable. In EDK2 variable design, another protocol "Firmware Volume Block Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform-specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer. My two cents. - Abner -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Thompson Sent: Friday, April 27, 2018 10:41 PM To: Grant Likely <[email protected]> Cc: Architecture Mailman List <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables 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. _______________________________________________ Arm.ebbr-discuss mailing list [email protected] _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
