On Thu, Oct 18, 2018 at 04:26:34PM +0100, Grant Likely wrote: > On 16/10/2018 17:12, Daniel Thompson wrote: > > On Thu, Oct 11, 2018 at 03:05:33PM +0000, Grant Likely wrote: > > > ResetSystem() was over-specified in the document. UEFI already documents > > > the behaviour of ResetSystem() sufficiently. Add notes on expected > > > behaviour when platform specific or standard interface methods are > > > available. > > > > > > Resolves: #29 > > > Signed-off-by: Grant Likely <[email protected]> > > > --- > > > source/chapter2-uefi.rst | 27 ++++++++++----------------- > > > 1 file changed, 10 insertions(+), 17 deletions(-) > > > > > > diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst > > > index 0cbddff..8a3ff1a 100644 > > > --- a/source/chapter2-uefi.rst > > > +++ b/source/chapter2-uefi.rst > > > @@ -175,23 +175,16 @@ and the OS must use a device driver to control the > > > RTC. > > > UEFI Reset and Shutdown > > > ----------------------- > > > -The UEFI Runtime service ResetSystem() must implement the following > > > commands, > > > -for purposes of power management and system control. > > > - > > > -- EfiResetCold() > > > -- EfiResetShutdown() > > > - * EfiResetShutdown must not reboot the system. > > > - > > > -If firmware updates are supported through the Runtime Service of > > > -UpdateCapsule(), then ResetSystem() might need to support the following > > > -command: > > > - > > > -- EfiWarmReset() > > > - > > > -.. note:: On platforms implementing the Power State Coordination > > > Interface > > > - specification [PSCI]_, it is still required that EBBR compliant > > > - Operating Systems calls to reset the system will go via Runtime > > > Services > > > - and not directly to PSCI. > > > +ResetSystem() is required to be implemented in boot services, but it is > > > +optional for runtime services. > > > +During runtime services, the operating system should first attempt to > > > +use ResetSystem() to reset the system. > > > > This doesn't fit together quite as it should alongside the > > RuntimeServicesSupported variable. Read naively it appears to recommend > > that an OS call ResetSystem() even in cases where it knows that it > > doesn't work. > > > > It's a bit tricky to word since there are three cases rather than two > > (implemented, not-implemented and os-didn't-check) > > I prefer to say the OS should try ResetSystem() unconditionally.
This strikes me as a slightly odd preference for *EBBR* to have (why do we want to constrain OS freedom here?). Having said that this is only a "should" requirement so I can live with it ;-) Daniel. > If firmware > doesn't implement ResetSystem() during runtime services, then the call will > immediately return EFI_UNSUPPORTED. That's a faster and easier path than > first checking to see if it is advertized in RuntimeServicesSupported. > > I've reworded to the following: > > ResetSystem() is required to be implemented in boot services, but it is > optional for runtime services. > During runtime services, the operating system should first attempt to > use ResetSystem() to reset the system. > If firmware doesn't support ResetSystem() during runtime services, > then the call will immediately return EFI_UNSUPPORTED, and the OS should > fall back to an architecture or platform specific reset mechanism. > > g. > > > > > Maybe: > > : ... unless the operating system has already discovered > > : from the "RuntimeServicesSupported" variable that ResetSystem() > > : is not implemented. > > > > > > > > > +If ResetSystem() returns EFI_UNSUPPORTED, then the OS may fall back to > > > +an architecture or platform specific mechanism. > > > + > > > +On AArch64 platforms implementing [PSCI]_, > > > +if ResetSystem() is not implemented then the Operating System should fall > > > +back to making a PSCI call to reset or shutdown the system. > > > Runtime Variable Access > > > ----------------------- > > > -- > > > 2.13.0 > > > > > > > > > _______________________________________________ > > > Arm.ebbr-discuss mailing list > > > [email protected] > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
