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.