On Thu, Apr 26, 2018 at 12:52:04PM -0400, William Mills wrote:
> >>>> 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.)
Yes. This statement was based on my incorrect assumption that we were
permitting systems without any persistent variable storage in the first
revision of the spec. (As opposed to only systems that did not provide
persistent variable storage at runtime.)
> >>>> 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.
Well, I was arguing for supporting that in EBBR.0 (since that matches
the behaviour of some EDK2 ports), but I don't think that is something
we would like to _add_ to EBBR.1 if it is not supported by EBBR.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?
Yes, this was the reason for my last request for clarification. And
the view was that such systems will not be compliant with any version
of the spec.
/
Leif
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
