[RFC PATCH 0/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[RFC PATCH 0/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

I am trying to add support in mainline for a tablet based on Exynos
5420 (Samsung Galaxy Tab S).  For this tablet, CCI has to be disabled,
and with that the device then hangs during

  exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0),

which is run in the cpu_boot secure-firmware function.  If the call is
skipped, then four out of eight CPUs are brought up, which is the same
as on exynos5420-arndale-octa [1] which also has disabled CCI.

Based on Samsung's kernel sources, it seems like the SMC_CMD_CPU1BOOT
call is only needed on Exynos4 and Exynos5250 devices [2], on other
SoC models the call is skipped.  To test if the call seem to do
anything, I booted exynos5422-odroid-xu4 with disabled CCI and with or
without the SMC_CMD_CPU1BOOT call.  The result in both cases were the
same: the first four CPUs were brought up.

To further investigate if the SMC_CMD_CPU1BOOT call is handled we need
to dig into the trustzone firmware.  The trustzone firmware used in
exynos5410-odroid-xu has been to a large part reverse engineered [3],
and by comparing with sboot/tzsw in mainline devices it can be seen
that similar trustzone firmware is used in several.  Out of those, the
SMC_CMD_CPU1BOOT call seem to be only handled in Exynos4 devices.

Here's a table summarising the findings for the mainline devices that
have a secure-firmware node (Exynos3 devices omitted).  An extra 4212
device has been included to get a datapoint for that SoC as well.

.----------------------.--------------.--------------.--------------.
| Device (exynos-)     | Similar tzsw | CPU1BOOT SMC | sboot/tzsw   |
|                      |   to 5410?   |   handled?   |   source     |
.----------------------.--------------.--------------.--------------.
  4212 galaxy tab 3    | yes          | yes          | T310XXSBQB2
  4412-i9300           | yes          | yes          | I9300XXUGPE1
  4412-i9305           | yes          | yes          | I9305XXUFPB1
  4412-itop-elite      | not checked  |              |
  4412-n710x           | not checked  |              |
  4412-odroid{x,x2,u3} | yes          | yes          | wiki.odroid.com/_media/en/boot.tar.gz
  4412-origen          | no           | don't know   | Linaro's origen hwpack 20130130
  4412-p4note-n8010    | not checked  |              |
  4412-trats2          | not checked  |              |
  5410-odroidxu        | yes          | no           | github.com/hsnaves/exynos5410-firmware
  5410-smdk5410        | not checked  |              |
  5420-arndale-octa    | yes          | no           | Linaro's arndale-octa hwpack 20140323
  5422-odroid-xu{3,4}  | yes          | no           | Hardkernel's u-boot 2020.01 branch

"Similar tzsw" above means that the secure monitor calls seem to be
handled in the same way as for exynos5410-odroid-xu, in a quite
easy-to-spot function (see patch for what it looks like).

For the tablet I am actually interested in, the trustzone firmware
looks very different, and I have not been able to locate where/how the
secure monitor calls are handled.

Nevertheless, since the call seem to only be handled in trustzone
firmware for Exynos4, and since exynos5422-odroid-xu4 behaves the same
with or without this secure monitor call, I *think* it should be safe
to only run it on the devices where we know that it is handled.

[1] https://krzk.eu/#/builders/32
[2] https://github.com/LineageOS/android_kernel_samsung_exynos5420/blob/cm-14.1/arch/arm/mach-exynos/platsmp.c#L225-L229
[3] https://github.com/hsnaves/exynos5410-firmware

Henrik Grimler (1):
  ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

 arch/arm/mach-exynos/firmware.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


base-commit: 3e4d9032d1a223488456f82d05cfe5519962f344
prerequisite-patch-id: f0f30752eb24b3515eee0a8d7bcf043e2cb084ad
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH 0/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

I am trying to add support in mainline for a tablet based on Exynos
5420 (Samsung Galaxy Tab S).  For this tablet, CCI has to be disabled,
and with that the device then hangs during

  exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0),

which is run in the cpu_boot secure-firmware function.  If the call is
skipped, then four out of eight CPUs are brought up, which is the same
as on exynos5420-arndale-octa [1] which also has disabled CCI.

Based on Samsung's kernel sources, it seems like the SMC_CMD_CPU1BOOT
call is only needed on Exynos4 and Exynos5250 devices [2], on other
SoC models the call is skipped.  To test if the call seem to do
anything, I booted exynos5422-odroid-xu4 with disabled CCI and with or
without the SMC_CMD_CPU1BOOT call.  The result in both cases were the
same: the first four CPUs were brought up.

To further investigate if the SMC_CMD_CPU1BOOT call is handled we need
to dig into the trustzone firmware.  The trustzone firmware used in
exynos5410-odroid-xu has been to a large part reverse engineered [3],
and by comparing with sboot/tzsw in mainline devices it can be seen
that similar trustzone firmware is used in several.  Out of those, the
SMC_CMD_CPU1BOOT call seem to be only handled in Exynos4 devices.

Here's a table summarising the findings for the mainline devices that
have a secure-firmware node (Exynos3 devices omitted).  An extra 4212
device has been included to get a datapoint for that SoC as well.

.----------------------.--------------.--------------.--------------.
| Device (exynos-)     | Similar tzsw | CPU1BOOT SMC | sboot/tzsw   |
|                      |   to 5410?   |   handled?   |   source     |
.----------------------.--------------.--------------.--------------.
  4212 galaxy tab 3    | yes          | yes          | T310XXSBQB2
  4412-i9300           | yes          | yes          | I9300XXUGPE1
  4412-i9305           | yes          | yes          | I9305XXUFPB1
  4412-itop-elite      | not checked  |              |
  4412-n710x           | not checked  |              |
  4412-odroid{x,x2,u3} | yes          | yes          | wiki.odroid.com/_media/en/boot.tar.gz
  4412-origen          | no           | don't know   | Linaro's origen hwpack 20130130
  4412-p4note-n8010    | not checked  |              |
  4412-trats2          | not checked  |              |
  5410-odroidxu        | yes          | no           | github.com/hsnaves/exynos5410-firmware
  5410-smdk5410        | not checked  |              |
  5420-arndale-octa    | yes          | no           | Linaro's arndale-octa hwpack 20140323
  5422-odroid-xu{3,4}  | yes          | no           | Hardkernel's u-boot 2020.01 branch

"Similar tzsw" above means that the secure monitor calls seem to be
handled in the same way as for exynos5410-odroid-xu, in a quite
easy-to-spot function (see patch for what it looks like).

For the tablet I am actually interested in, the trustzone firmware
looks very different, and I have not been able to locate where/how the
secure monitor calls are handled.

Nevertheless, since the call seem to only be handled in trustzone
firmware for Exynos4, and since exynos5422-odroid-xu4 behaves the same
with or without this secure monitor call, I *think* it should be safe
to only run it on the devices where we know that it is handled.

[1] https://krzk.eu/#/builders/32
[2] https://github.com/LineageOS/android_kernel_samsung_exynos5420/blob/cm-14.1/arch/arm/mach-exynos/platsmp.c#L225-L229
[3] https://github.com/hsnaves/exynos5410-firmware

Henrik Grimler (1):
  ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

 arch/arm/mach-exynos/firmware.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


base-commit: 3e4d9032d1a223488456f82d05cfe5519962f344
prerequisite-patch-id: f0f30752eb24b3515eee0a8d7bcf043e2cb084ad
-- 
2.34.1

[RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

On Exynos5 the call is simply ignored by most variants of the
trustzone firmware.  However, on some devices it instead causes the
device to hang, so let's avoid the call for the SoCs where it should
not be needed.

To see that the call is ignored, we can look into sboot/tzsw.  On most
of the Exynos{4,5} devices the part of sboot/tzsw that seem to handle
the secure monitor calls is quite easy to recognise, the SMC number is
compared to known ones, and if equal it branches to the relevant
function.  In assembly this looks something like:

;-- handle_smc:
0x00000514      650070e3       cmn r0, 0x65
0x00000518      0a00000a       beq loc.smc_cmd_reg
0x0000051c      010070e3       cmn r0, 1
0x00000520      6c00000a       beq loc.smc_cmd_init
0x00000524      020070e3       cmn r0, 2
0x00000528      6b00000a       beq loc.smc_cmd_info
0x0000052c      030070e3       cmn r0, 3
0x00000530      6e00000a       beq loc.smc_cmd_sleep
0x00000534      060070e3       cmn r0, 6
0x00000538      ae00000a       beq loc.smc_cmd_save_state
0x0000053c      070070e3       cmn r0, 7
0x00000540      b400000a       beq loc.smc_cmd_standby
0x00000544      2b01001a       bne loc.smc_return_minus1

where above example is from exynos5420-arndale-octa.  As can be seen
the case where r0 is 4 (i.e. SMC_CMD_CPU1BOOT) is not handled.  The
annotations are taken from github.com/hsnaves/exynos5410-firmware,
where a large part of the exynos5410 trustzone firmware has been
reverse-engineered.

Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
 arch/arm/mach-exynos/firmware.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 2eaf2dbb8e81..2da5b60b59e2 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -60,8 +60,10 @@ static int exynos_cpu_boot(int cpu)
 	/*
 	 * Exynos3250 doesn't need to send smc command for secondary CPU boot
 	 * because Exynos3250 removes WFE in secure mode.
+	 *
+	 * On Exynos5 devices the call is ignored by trustzone firmware.
 	 */
-	if (soc_is_exynos3250())
+	if (!soc_is_exynos4210() && !soc_is_exynos4412())
 		return 0;
 
 	/*
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

On Exynos5 the call is simply ignored by most variants of the
trustzone firmware.  However, on some devices it instead causes the
device to hang, so let's avoid the call for the SoCs where it should
not be needed.

To see that the call is ignored, we can look into sboot/tzsw.  On most
of the Exynos{4,5} devices the part of sboot/tzsw that seem to handle
the secure monitor calls is quite easy to recognise, the SMC number is
compared to known ones, and if equal it branches to the relevant
function.  In assembly this looks something like:

;-- handle_smc:
0x00000514      650070e3       cmn r0, 0x65
0x00000518      0a00000a       beq loc.smc_cmd_reg
0x0000051c      010070e3       cmn r0, 1
0x00000520      6c00000a       beq loc.smc_cmd_init
0x00000524      020070e3       cmn r0, 2
0x00000528      6b00000a       beq loc.smc_cmd_info
0x0000052c      030070e3       cmn r0, 3
0x00000530      6e00000a       beq loc.smc_cmd_sleep
0x00000534      060070e3       cmn r0, 6
0x00000538      ae00000a       beq loc.smc_cmd_save_state
0x0000053c      070070e3       cmn r0, 7
0x00000540      b400000a       beq loc.smc_cmd_standby
0x00000544      2b01001a       bne loc.smc_return_minus1

where above example is from exynos5420-arndale-octa.  As can be seen
the case where r0 is 4 (i.e. SMC_CMD_CPU1BOOT) is not handled.  The
annotations are taken from github.com/hsnaves/exynos5410-firmware,
where a large part of the exynos5410 trustzone firmware has been
reverse-engineered.

Signed-off-by: Henrik Grimler <henrik@grimler.se>
---
 arch/arm/mach-exynos/firmware.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 2eaf2dbb8e81..2da5b60b59e2 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -60,8 +60,10 @@ static int exynos_cpu_boot(int cpu)
 	/*
 	 * Exynos3250 doesn't need to send smc command for secondary CPU boot
 	 * because Exynos3250 removes WFE in secure mode.
+	 *
+	 * On Exynos5 devices the call is ignored by trustzone firmware.
 	 */
-	if (soc_is_exynos3250())
+	if (!soc_is_exynos4210() && !soc_is_exynos4412())
 		return 0;
 
 	/*
-- 
2.34.1

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Marek Szyprowski]

On 08.01.2022 22:57, Henrik Grimler wrote:
> On Exynos5 the call is simply ignored by most variants of the
> trustzone firmware.  However, on some devices it instead causes the
> device to hang, so let's avoid the call for the SoCs where it should
> not be needed.
>
> To see that the call is ignored, we can look into sboot/tzsw.  On most
> of the Exynos{4,5} devices the part of sboot/tzsw that seem to handle
> the secure monitor calls is quite easy to recognise, the SMC number is
> compared to known ones, and if equal it branches to the relevant
> function.  In assembly this looks something like:
>
> ;-- handle_smc:
> 0x00000514      650070e3       cmn r0, 0x65
> 0x00000518      0a00000a       beq loc.smc_cmd_reg
> 0x0000051c      010070e3       cmn r0, 1
> 0x00000520      6c00000a       beq loc.smc_cmd_init
> 0x00000524      020070e3       cmn r0, 2
> 0x00000528      6b00000a       beq loc.smc_cmd_info
> 0x0000052c      030070e3       cmn r0, 3
> 0x00000530      6e00000a       beq loc.smc_cmd_sleep
> 0x00000534      060070e3       cmn r0, 6
> 0x00000538      ae00000a       beq loc.smc_cmd_save_state
> 0x0000053c      070070e3       cmn r0, 7
> 0x00000540      b400000a       beq loc.smc_cmd_standby
> 0x00000544      2b01001a       bne loc.smc_return_minus1
>
> where above example is from exynos5420-arndale-octa.  As can be seen
> the case where r0 is 4 (i.e. SMC_CMD_CPU1BOOT) is not handled.  The
> annotations are taken from github.com/hsnaves/exynos5410-firmware,
> where a large part of the exynos5410 trustzone firmware has been
> reverse-engineered.
>
> Signed-off-by: Henrik Grimler <henrik@grimler.se>

Works fine on all ARM 32bit Exynos-based boards I have for tests.

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

> ---
>   arch/arm/mach-exynos/firmware.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index 2eaf2dbb8e81..2da5b60b59e2 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -60,8 +60,10 @@ static int exynos_cpu_boot(int cpu)
>   	/*
>   	 * Exynos3250 doesn't need to send smc command for secondary CPU boot
>   	 * because Exynos3250 removes WFE in secure mode.
> +	 *
> +	 * On Exynos5 devices the call is ignored by trustzone firmware.
>   	 */
> -	if (soc_is_exynos3250())
> +	if (!soc_is_exynos4210() && !soc_is_exynos4412())
>   		return 0;
>   
>   	/*

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Marek Szyprowski]

On 08.01.2022 22:57, Henrik Grimler wrote:
> On Exynos5 the call is simply ignored by most variants of the
> trustzone firmware.  However, on some devices it instead causes the
> device to hang, so let's avoid the call for the SoCs where it should
> not be needed.
>
> To see that the call is ignored, we can look into sboot/tzsw.  On most
> of the Exynos{4,5} devices the part of sboot/tzsw that seem to handle
> the secure monitor calls is quite easy to recognise, the SMC number is
> compared to known ones, and if equal it branches to the relevant
> function.  In assembly this looks something like:
>
> ;-- handle_smc:
> 0x00000514      650070e3       cmn r0, 0x65
> 0x00000518      0a00000a       beq loc.smc_cmd_reg
> 0x0000051c      010070e3       cmn r0, 1
> 0x00000520      6c00000a       beq loc.smc_cmd_init
> 0x00000524      020070e3       cmn r0, 2
> 0x00000528      6b00000a       beq loc.smc_cmd_info
> 0x0000052c      030070e3       cmn r0, 3
> 0x00000530      6e00000a       beq loc.smc_cmd_sleep
> 0x00000534      060070e3       cmn r0, 6
> 0x00000538      ae00000a       beq loc.smc_cmd_save_state
> 0x0000053c      070070e3       cmn r0, 7
> 0x00000540      b400000a       beq loc.smc_cmd_standby
> 0x00000544      2b01001a       bne loc.smc_return_minus1
>
> where above example is from exynos5420-arndale-octa.  As can be seen
> the case where r0 is 4 (i.e. SMC_CMD_CPU1BOOT) is not handled.  The
> annotations are taken from github.com/hsnaves/exynos5410-firmware,
> where a large part of the exynos5410 trustzone firmware has been
> reverse-engineered.
>
> Signed-off-by: Henrik Grimler <henrik@grimler.se>

Works fine on all ARM 32bit Exynos-based boards I have for tests.

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

> ---
>   arch/arm/mach-exynos/firmware.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index 2eaf2dbb8e81..2da5b60b59e2 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -60,8 +60,10 @@ static int exynos_cpu_boot(int cpu)
>   	/*
>   	 * Exynos3250 doesn't need to send smc command for secondary CPU boot
>   	 * because Exynos3250 removes WFE in secure mode.
> +	 *
> +	 * On Exynos5 devices the call is ignored by trustzone firmware.
>   	 */
> -	if (soc_is_exynos3250())
> +	if (!soc_is_exynos4210() && !soc_is_exynos4412())
>   		return 0;
>   
>   	/*

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

Hi Marek,

> Works fine on all ARM 32bit Exynos-based boards I have for tests.
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Thanks for testing!  Would you mind telling me which Exynos boards you
have in your test-setup?

Best regards,
Henrik Grimler

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Henrik Grimler]

Hi Marek,

> Works fine on all ARM 32bit Exynos-based boards I have for tests.
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Thanks for testing!  Would you mind telling me which Exynos boards you
have in your test-setup?

Best regards,
Henrik Grimler

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Marek Szyprowski]

On 10.01.2022 20:16, Henrik Grimler wrote:
> Hi Marek,
>> Works fine on all ARM 32bit Exynos-based boards I have for tests.
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Thanks for testing!  Would you mind telling me which Exynos boards you
> have in your test-setup?

Sure:

Exynos3250: Rinato
Exynos4210: Trats
Exynos4412: Trats2, Odroid X2/U3
Exynos5250: Snow Chromebook, Arndale5250
Exynos5410: Odroid XU
Exynos5420: Pit Chromebook
Exynos5422: Odroud Xu3/Xu3-lite/Xu4/HC1
Exynos5800: Pi Chromebook


Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [RFC PATCH 1/1] ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

[Marek Szyprowski]

On 10.01.2022 20:16, Henrik Grimler wrote:
> Hi Marek,
>> Works fine on all ARM 32bit Exynos-based boards I have for tests.
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Thanks for testing!  Would you mind telling me which Exynos boards you
> have in your test-setup?

Sure:

Exynos3250: Rinato
Exynos4210: Trats
Exynos4412: Trats2, Odroid X2/U3
Exynos5250: Snow Chromebook, Arndale5250
Exynos5410: Odroid XU
Exynos5420: Pit Chromebook
Exynos5422: Odroud Xu3/Xu3-lite/Xu4/HC1
Exynos5800: Pi Chromebook


Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel