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. +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 -----------------------
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Grant Likely Sent: Thursday, October 11, 2018 8:36 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss <arm.ebbr- discuss@arm.com> Cc: nd nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements
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. +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.
IMHO, if reset is implemented using some registers then platform may choose to return error, if platform does not convert pointer etc. But for psci, method,. why, we want to return error from ResetSystem(). I believe, similar to edk2 even in u-boot supporting reset using psci should be any platform specific effort.
Runtime Variable Access
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 12/10/2018 07:01, Udit Kumar wrote:
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Grant Likely Sent: Thursday, October 11, 2018 8:36 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss <arm.ebbr- discuss@arm.com> Cc: nd nd@arm.com Subject: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements
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. +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.
IMHO, if reset is implemented using some registers then platform may choose to return error, if platform does not convert pointer etc. But for psci, method,. why, we want to return error from ResetSystem(). I believe, similar to edk2 even in u-boot supporting reset using psci should be any platform specific effort.
Hi Udit,
I'm having trouble understanding what you mean. What would you like the spec to say in this case?
g.
-----Original Message----- From: Grant Likely grant.likely@arm.com Sent: Friday, October 12, 2018 6:19 PM To: Udit Kumar udit.kumar@nxp.com; boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Cc: nd@arm.com Subject: Re: [PATCH v2] Refactor ResetSystem() requirements
On 12/10/2018 07:01, Udit Kumar wrote:
+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 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.
IMHO, if reset is implemented using some registers then platform may choose to return error, if platform does not convert pointer etc. But for psci, method,. why, we want to return error from ResetSystem(). I believe, similar to edk2 even in u-boot supporting reset using psci should be
any platform specific effort.
Hi Udit,
I'm having trouble understanding what you mean. What would you like the spec to say in this case?
Hi Grant Sorry I was not clear in my previous email. I haven't seen platforms, which has _psci in place and reset is implemented by means of some configuration registers. With this, reset call anyway is going to _psci implementation weather direct OS call or through runtime interface. In this case, supporting reset through runtime service will be easy one and does not require any change in platform specific software.
Therefore I prefer to have like +On AArch64 platforms implementing [PSCI]_, ResetSystem() must be implemented through runtime service.
You may have different opinion
Regards Udit
On 12/10/2018 16:26, Udit Kumar wrote:
-----Original Message----- From: Grant Likely grant.likely@arm.com Sent: Friday, October 12, 2018 6:19 PM To: Udit Kumar udit.kumar@nxp.com; boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Cc: nd@arm.com Subject: Re: [PATCH v2] Refactor ResetSystem() requirements
On 12/10/2018 07:01, Udit Kumar wrote:
+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 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.
IMHO, if reset is implemented using some registers then platform may choose to return error, if platform does not convert pointer etc. But for psci, method,. why, we want to return error from ResetSystem(). I believe, similar to edk2 even in u-boot supporting reset using psci should be
any platform specific effort.
Hi Udit,
I'm having trouble understanding what you mean. What would you like the spec to say in this case?
Hi Grant Sorry I was not clear in my previous email. I haven't seen platforms, which has _psci in place and reset is implemented by means of some configuration registers. With this, reset call anyway is going to _psci implementation weather direct OS call or through runtime interface. In this case, supporting reset through runtime service will be easy one and does not require any change in platform specific software.
Therefore I prefer to have like +On AArch64 platforms implementing [PSCI]_, ResetSystem() must be implemented through runtime service. You may have different opinion
I've had feedback from one major OS that they don't trust UEFI RuntimeServices(), and they call PSCI directly. On the other side I've had feedback that putting reset into PSCI requires the board vendor to modify EL3 firmware, where if the shutdown GPIO (for example) could be toggled from EL2, then EL3 could be common and signed for all SoCs.
Basically we've got competing requirements, and I think this is the best option presented so far at a compromise.
g.
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)
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
Hi Daniel
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com <arm.ebbr-discuss- bounces@arm.com> On Behalf Of Daniel Thompson Sent: Tuesday, October 16, 2018 9:43 PM To: Grant Likely Grant.Likely@arm.com Cc: boot-architecture@lists.linaro.org; nd nd@arm.com; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements
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.
IMO, this variable is applicable for all services, not for just reset, right ? I am not sure, if this is bit mask in this variable to specify each runtime service availability,
fyi, I am not able to find such variable in Table 10. Global Variables (spec 2.7) Please help, where this is defined
It's a bit tricky to word since there are three cases rather than two (implemented, not-implemented and os-didn't-check)
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
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On Thu, Oct 18, 2018 at 03:53:17AM +0000, Udit Kumar wrote:
Hi Daniel
+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.
IMO, this variable is applicable for all services, not for just reset, right ? I am not sure, if this is bit mask in this variable to specify each runtime service availability,
Assuming that Peter J's ECR gets accepted in something like its current form then... yes, it is a bitmask and it does specifically identify ResetSystem().
fyi, I am not able to find such variable in Table 10. Global Variables (spec 2.7) Please help, where this is defined
It is currently an ECR so you won't find it in the standard. AFAIK the latest version is: https://pjones.fedorapeople.org/rt-unsupported-ecr-1.txt
Daniel.
Thanks Daniel, that really helped me understand both sides of this discussion... had to write some pseudo-code to think it through though... David
On Thu, 18 Oct 2018, 10:32 Daniel Thompson, daniel.thompson@linaro.org wrote:
On Thu, Oct 18, 2018 at 03:53:17AM +0000, Udit Kumar wrote:
Hi Daniel
+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.
IMO, this variable is applicable for all services, not for just reset,
right ?
I am not sure, if this is bit mask in this variable to specify each
runtime
service availability,
Assuming that Peter J's ECR gets accepted in something like its current form then... yes, it is a bitmask and it does specifically identify ResetSystem().
fyi, I am not able to find such variable in Table 10. Global Variables (spec
2.7)
Please help, where this is defined
It is currently an ECR so you won't find it in the standard. AFAIK the latest version is: https://pjones.fedorapeople.org/rt-unsupported-ecr-1.txt
Daniel. _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
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. 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
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
boot-architecture@lists.linaro.org
-
Daniel Thompson -
David Rusling -
Grant Likely -
Grant Likely
-
Udit Kumar