| Message ID | 20200709060820.121087-1-yamada.masahiro@socionext.com |
|---|---|
| State | Accepted |
| Commit | 1f8e6a670c6a6f64fb2060995650689f4fb20001 |
| Headers | show |
| Series | [01/10] Revert "ARM: uniphier: add weird workaround code for LD20" | expand |
On Thu, Jul 9, 2020 at 3:09 PM Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > 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 at 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 at 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 at socionext.com> > --- Series, applied to u-boot-uniphier.
diff --git a/arch/arm/mach-uniphier/arm64/Makefile b/arch/arm/mach-uniphier/arm64/Makefile index c569551120..750c4f756e 100644 --- a/arch/arm/mach-uniphier/arm64/Makefile +++ b/arch/arm/mach-uniphier/arm64/Makefile @@ -1,4 +1,3 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y += mem_map.o -obj-$(CONFIG_ARCH_UNIPHIER_LD20) += lowlevel_init.o diff --git a/arch/arm/mach-uniphier/arm64/lowlevel_init.S b/arch/arm/mach-uniphier/arm64/lowlevel_init.S deleted file mode 100644 index f4e5cbbbd1..0000000000 --- a/arch/arm/mach-uniphier/arm64/lowlevel_init.S +++ /dev/null @@ -1,13 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * Copyright (C) 2017 Socionext Inc. - */ - -#include <linux/linkage.h> - -ENTRY(lowlevel_init) - /* LD20 needs the following code to boot. I do not know why. */ - mrs x0, sctlr_el1 - msr sctlr_el1, x0 - ret -ENDPROC(lowlevel_init)
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 at 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 at 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 at socionext.com> --- arch/arm/mach-uniphier/arm64/Makefile | 1 - arch/arm/mach-uniphier/arm64/lowlevel_init.S | 13 ------------- 2 files changed, 14 deletions(-) delete mode 100644 arch/arm/mach-uniphier/arm64/lowlevel_init.S