On 12/10/2018 16:26, Udit Kumar wrote:
-----Original Message-----
From: Grant Likely <[email protected]>
Sent: Friday, October 12, 2018 6:19 PM
To: Udit Kumar <[email protected]>; [email protected];
arm.ebbr-discuss <[email protected]>
Cc: [email protected]
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.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
