Revert "ARM: uniphier: add weird workaround code for LD20"
authorMasahiro Yamada <yamada.masahiro@socionext.com>
Thu, 9 Jul 2020 06:08:11 +0000 (15:08 +0900)
committerMasahiro Yamada <yamada.masahiro@socionext.com>
Sat, 11 Jul 2020 12:30:21 +0000 (21:30 +0900)
commit1f8e6a670c6a6f64fb2060995650689f4fb20001
treeaf1c685be9f18de27d3e1304b5cbbc8873da3c5d
parent3113c84ba25ec3ceae072cc5ad450c4238425939
Revert "ARM: uniphier: add weird workaround code for LD20"

This reverts commit 45f41c134baf5ff1bbf59d33027f6c79884fa4d9.

This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.

I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.

Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.

|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date:   Thu Jul 25 10:57:38 2019 +0900
|
|    uniphier: run BL33 at EL2
|
|    All the SoCs in 64-bit UniPhier SoC family support EL2.
|
|    Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
|    Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
|    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.

Now that commit f8ddd8cbb513 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
arch/arm/mach-uniphier/arm64/Makefile
arch/arm/mach-uniphier/arm64/lowlevel_init.S [deleted file]