[U-Boot] [PATCH] imx: mx7: psci: Add support for version command

This command should be supported for PSCI 1.0. Current code results in this message from the kernel: "PSCIv65535.65535 detected in firmware."
This will mess up a kernel check of the PSCI version. Currently the kernel only cares if the version is at least 1.0 so it doesn't break anything, as the incorrect version and correct version are both >= 1.0, but as soon as a check for > 1.0 goes in it will fail.
CC: Anson Huang Anson.Huang@nxp.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Signed-off-by: Trent Piepho tpiepho@impinj.com --- arch/arm/mach-imx/mx7/psci.S | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S index 89dcf880e8..7035f6093b 100644 --- a/arch/arm/mach-imx/mx7/psci.S +++ b/arch/arm/mach-imx/mx7/psci.S @@ -57,4 +57,14 @@ psci_system_off: 3: wfi b 3b
+.globl psci_version +psci_version: +#if defined(CONFIG_ARMV7_PSCI_1_0) + ldr r0, =ARM_PSCI_VER_1_0 +#else +#error "add support for your PSCI version" +#endif + + bx lr + .popsection

On 31.05.2018 20:13, Trent Piepho wrote:
This command should be supported for PSCI 1.0. Current code results in this message from the kernel: "PSCIv65535.65535 detected in firmware."
This will mess up a kernel check of the PSCI version. Currently the kernel only cares if the version is at least 1.0 so it doesn't break anything, as the incorrect version and correct version are both >= 1.0, but as soon as a check for > 1.0 goes in it will fail.
The right direction, it can also be done in C though:
unsigned int __secure psci_version(u32 function_id) { return ARM_PSCI_VER_1_0; }
But this is not complete though, since also other callbacks need to be supported for proper PSCI 1.0 support.
See also this discussion: https://www.spinics.net/lists/arm-kernel/msg640337.html
I try to come up with a proper fix for this.
-- Stefan
CC: Anson Huang Anson.Huang@nxp.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de Signed-off-by: Trent Piepho tpiepho@impinj.com
arch/arm/mach-imx/mx7/psci.S | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S index 89dcf880e8..7035f6093b 100644 --- a/arch/arm/mach-imx/mx7/psci.S +++ b/arch/arm/mach-imx/mx7/psci.S @@ -57,4 +57,14 @@ psci_system_off: 3: wfi b 3b
+.globl psci_version +psci_version: +#if defined(CONFIG_ARMV7_PSCI_1_0)
- ldr r0, =ARM_PSCI_VER_1_0
+#else +#error "add support for your PSCI version" +#endif
- bx lr
- .popsection

On Fri, 2018-06-22 at 11:09 +0200, Stefan Agner wrote:
On 31.05.2018 20:13, Trent Piepho wrote:
This command should be supported for PSCI 1.0. Current code results in this message from the kernel: "PSCIv65535.65535 detected in firmware."
This will mess up a kernel check of the PSCI version. Currently the kernel only cares if the version is at least 1.0 so it doesn't break anything, as the incorrect version and correct version are both >= 1.0, but as soon as a check for > 1.0 goes in it will fail.
The right direction, it can also be done in C though:
unsigned int __secure psci_version(u32 function_id) { return ARM_PSCI_VER_1_0; }
When the PSCI is left in RAM, does it consist of the entire u-boot image, or is somehow just the PSCI component left?
I'm curious how placing the code in another object file affects the PSCI binary.
But this is not complete though, since also other callbacks need to be supported for proper PSCI 1.0 support.
See also this discussion:
I see this problem was known before I found it. It would be nice if a fix could go in before others also find it and waste time investigating.
It is also the case the reset code in the PSCI does not work on imx7 for some time now, for boards with a reset design following NXP's recommendations. This is not hard to change, I've already done so locally for our product affected by this.
Must these problems remain unaddressed until some future redesign or major patch from NXP fixes them?
participants (2)
-
Stefan Agner
-
Trent Piepho