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 grant.likely@arm.com
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 Arm.ebbr-discuss@arm.com