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

Message

Henrik Grimler Jan. 8, 2022, 9:57 p.m. UTC

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