[linux-sunxi] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support

[Icenowy Zheng]

This is an experimental support for the PSCI SMP bringup of the first
cluster of Allwinner A83T SoC.

It's based on some code by Timothy Pearson for A83T (already quite old)
and Chen-Yu Tsai (which are originally for A80).

In order to ensure the Linux kernel to work properly in SMP environment,
some GIC workarounds implemented in [1] is needed.

[1] https://github.com/wens/linux/commit/c48654c1f737116e7a7660183c8c74fa91970528

Chen-Yu Tsai (2):
sunxi: Add CPUCFG register definitions for A80/A83T SoCs
sunxi: Add basic PSCI implementation for multi-cluster SoCs

Icenowy Zheng (4):
sunxi: add configuration of secure SRAM for A83T
sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC
sunxi: add multi-cluster CPU PRCM register definition
sunxi: enable PSCI for A83T SoC

***@raptorengineering.com (2):
sun8i: Add TZPC setup for A83T
sun8i: Add a macro to read the silicon revision

arch/arm/cpu/armv7/sunxi/Makefile | 5 +
arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 258 +++++++++++++++++++++++++
arch/arm/cpu/armv7/sunxi/psci.c | 2 +-
arch/arm/cpu/armv7/sunxi/tzpc.c | 10 +
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 9 +
arch/arm/include/asm/arch-sunxi/cpucfg.h | 64 +-----
arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h | 68 +++++++
arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 60 ++++++
arch/arm/include/asm/arch-sunxi/prcm.h | 8 +-
arch/arm/include/asm/arch-sunxi/tzpc.h | 6 +
arch/arm/mach-sunxi/Kconfig | 4 +
arch/arm/mach-sunxi/board.c | 2 +-
arch/arm/mach-sunxi/cpu_info.c | 2 +-
include/configs/sun8i.h | 1 +
14 files changed, 434 insertions(+), 65 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h

[Icenowy Zheng]

From: "***@raptorengineering.com" <***@raptorengineering.com>

This patch enables non-secure access to all system peripherals
controlled by the STMA, and additionally sets the secure RAM
range to 64k in line with other sunxi devices.

Signed-off-by: Timothy Pearson <***@raptorengineering.com>
Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/tzpc.c | 10 ++++++++++
arch/arm/include/asm/arch-sunxi/tzpc.h | 6 ++++++
arch/arm/mach-sunxi/board.c | 2 +-
4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index b35b9df4a9..8c026ff052 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o

obj-$(CONFIG_MACH_SUN6I) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
+obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o

ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMV7_PSCI) += psci.o
diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
index 6c8a0fd9a2..50a5ff6b30 100644
--- a/arch/arm/cpu/armv7/sunxi/tzpc.c
+++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
@@ -18,6 +18,16 @@ void tzpc_init(void)
writel(SUN6I_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
#endif

+#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL
+ /* Set secure RAM size to defined value */
+ writel(SUN8I_A83T_TZPC_R0SIZE_64K, &tzpc->r0size);
+
+ /* Enable non-secure access to all peripherals */
+ writel(SUN8I_A83T_TZPC_DECPORT0_ALL, &tzpc->decport0_set);
+ writel(SUN8I_A83T_TZPC_DECPORT1_ALL, &tzpc->decport1_set);
+ writel(SUN8I_A83T_TZPC_DECPORT2_ALL, &tzpc->decport2_set);
+#endif
+
#ifdef CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to all peripherals */
writel(SUN8I_H3_TZPC_DECPORT0_ALL, &tzpc->decport0_set);
diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h b/arch/arm/include/asm/arch-sunxi/tzpc.h
index 95c55cd4d1..5b85ee86f9 100644
--- a/arch/arm/include/asm/arch-sunxi/tzpc.h
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -25,6 +25,12 @@ struct sunxi_tzpc {

#define SUN6I_TZPC_DECPORT0_RTC (1 << 1)

+#define SUN8I_A83T_TZPC_DECPORT0_ALL 0xbe
+#define SUN8I_A83T_TZPC_DECPORT1_ALL 0x7f
+#define SUN8I_A83T_TZPC_DECPORT2_ALL 0x10
+/* The Secure RAM size, 0x10 means 64KiB */
+#define SUN8I_A83T_TZPC_R0SIZE_64K 0x10
+
#define SUN8I_H3_TZPC_DECPORT0_ALL 0xbe
#define SUN8I_H3_TZPC_DECPORT1_ALL 0xff
#define SUN8I_H3_TZPC_DECPORT2_ALL 0x7f
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 65b1ebd837..269555e77c 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -196,7 +196,7 @@ void s_init(void)
"mcr p15, 0, r0, c1, c0, 1\n"
::: "r0");
#endif
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_A83T || defined CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to some peripherals */
tzpc_init();
#endif

[Chen-Yu Tsai]

You should fix his name here.

Post by Icenowy Zheng
This patch enables non-secure access to all system peripherals
controlled by the STMA, and additionally sets the secure RAM
range to 64k in line with other sunxi devices.
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/tzpc.c | 10 ++++++++++
arch/arm/include/asm/arch-sunxi/tzpc.h | 6 ++++++
arch/arm/mach-sunxi/board.c | 2 +-
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index b35b9df4a9..8c026ff052 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o
obj-$(CONFIG_MACH_SUN6I) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
+obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMV7_PSCI) += psci.o
diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
index 6c8a0fd9a2..50a5ff6b30 100644
--- a/arch/arm/cpu/armv7/sunxi/tzpc.c
+++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
@@ -18,6 +18,16 @@ void tzpc_init(void)
writel(SUN6I_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
#endif
+#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL
+ /* Set secure RAM size to defined value */
+ writel(SUN8I_A83T_TZPC_R0SIZE_64K, &tzpc->r0size);

As mentioned in the original review of this patch, this field is read only.
There is no need to write to this register.

Post by Icenowy Zheng
+
+ /* Enable non-secure access to all peripherals */
+ writel(SUN8I_A83T_TZPC_DECPORT0_ALL, &tzpc->decport0_set);
+ writel(SUN8I_A83T_TZPC_DECPORT1_ALL, &tzpc->decport1_set);
+ writel(SUN8I_A83T_TZPC_DECPORT2_ALL, &tzpc->decport2_set);
+#endif
+
#ifdef CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to all peripherals */
writel(SUN8I_H3_TZPC_DECPORT0_ALL, &tzpc->decport0_set);
diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h b/arch/arm/include/asm/arch-sunxi/tzpc.h
index 95c55cd4d1..5b85ee86f9 100644
--- a/arch/arm/include/asm/arch-sunxi/tzpc.h
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -25,6 +25,12 @@ struct sunxi_tzpc {
#define SUN6I_TZPC_DECPORT0_RTC (1 << 1)
+#define SUN8I_A83T_TZPC_DECPORT0_ALL 0xbe
+#define SUN8I_A83T_TZPC_DECPORT1_ALL 0x7f
+#define SUN8I_A83T_TZPC_DECPORT2_ALL 0x10
+/* The Secure RAM size, 0x10 means 64KiB */
+#define SUN8I_A83T_TZPC_R0SIZE_64K 0x10

So this last one is not needed.

ChenYu

Post by Icenowy Zheng
+
#define SUN8I_H3_TZPC_DECPORT0_ALL 0xbe
#define SUN8I_H3_TZPC_DECPORT1_ALL 0xff
#define SUN8I_H3_TZPC_DECPORT2_ALL 0x7f
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 65b1ebd837..269555e77c 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -196,7 +196,7 @@ void s_init(void)
"mcr p15, 0, r0, c1, c0, 1\n"
::: "r0");
#endif
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_A83T || defined CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to some peripherals */
tzpc_init();
#endif
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
For more options, visit https://groups.google.com/d/optout.

[Icenowy Zheng]

A83T has some secure SRAM that can be used to place the PSCI code.

Add the configuration of them.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
include/configs/sun8i.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index 47f2813240..c6ba2a0c87 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -21,6 +21,7 @@
#define CONFIG_SUNXI_USB_PHYS 4
#elif defined CONFIG_MACH_SUN8I_A83T
#define CONFIG_SUNXI_USB_PHYS 3
+ #define CONFIG_ARMV7_SECURE_BASE SUNXI_SRAM_B_BASE
#elif defined CONFIG_MACH_SUN8I_V3S
#define CONFIG_SUNXI_USB_PHYS 1
#else

[Chen-Yu Tsai]

Post by Icenowy Zheng
A83T has some secure SRAM that can be used to place the PSCI code.
Add the configuration of them.

Reviewed-by: Chen-Yu Tsai <***@csie.org>

[Icenowy Zheng]

From: "***@raptorengineering.com" <***@raptorengineering.com>

According to the user manuals released by Allwinner, the low 8-bit of
the 0x24 register in "System Control" (marked SRAMC in U-Boot source as
it controls some SRAMs' functionality since A10) is the silicon revision
of the chip.

This data is now important for A83T: according to the BSP source A83T
have two revisions: Revision A (with revision ID 0) and Revision B (with
revision ID 1); and revision B requires a SMP bringup workaround.

Print the revision number when the SoC is A83T, as it does matter there.

Signed-off-by: Timothy Pearson <***@raptorengineering.com>
[Icenowy: convert to macro so that it can be reused in PSCI code]
Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++++++
arch/arm/mach-sunxi/cpu_info.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 6aa5e91ada..a96680d8e8 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -205,6 +205,13 @@ void sunxi_board_init(void);
void sunxi_reset(void);
int sunxi_get_ss_bonding_id(void);
int sunxi_get_sid(unsigned int *sid);
+
+/*
+ * Implement it as a macro, because it's used both in PSCI source code
+ * and normal U-Boot source code.
+ */
+#define sunxi_get_revision() (readl(SUNXI_SRAMC_BASE + 0x24) & 0xff)
+
#endif /* __ASSEMBLY__ */

#endif /* _SUNXI_CPU_SUN4I_H */
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 25a5ec26a0..4236ab8f11 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -84,7 +84,7 @@ int print_cpuinfo(void)
#elif defined CONFIG_MACH_SUN8I_A33
printf("CPU: Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_A83T
- printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
+ printf("CPU: Allwinner A83T (SUN8I %04x rev. %x)\n", sunxi_get_sram_id(), sunxi_get_revision());
#elif defined CONFIG_MACH_SUN8I_H3
printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_R40

[Chen-Yu Tsai]

Same thing with the author name.

Post by Icenowy Zheng
According to the user manuals released by Allwinner, the low 8-bit of
the 0x24 register in "System Control" (marked SRAMC in U-Boot source as
it controls some SRAMs' functionality since A10) is the silicon revision
of the chip.
This data is now important for A83T: according to the BSP source A83T
have two revisions: Revision A (with revision ID 0) and Revision B (with
revision ID 1); and revision B requires a SMP bringup workaround.
Print the revision number when the SoC is A83T, as it does matter there.
[Icenowy: convert to macro so that it can be reused in PSCI code]
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++++++
arch/arm/mach-sunxi/cpu_info.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 6aa5e91ada..a96680d8e8 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -205,6 +205,13 @@ void sunxi_board_init(void);
void sunxi_reset(void);
int sunxi_get_ss_bonding_id(void);
int sunxi_get_sid(unsigned int *sid);
+
+/*
+ * Implement it as a macro, because it's used both in PSCI source code
+ * and normal U-Boot source code.
+ */
+#define sunxi_get_revision() (readl(SUNXI_SRAMC_BASE + 0x24) & 0xff)

Ideally, please add a macro for the register offset.

Post by Icenowy Zheng
+
#endif /* __ASSEMBLY__ */
#endif /* _SUNXI_CPU_SUN4I_H */
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 25a5ec26a0..4236ab8f11 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -84,7 +84,7 @@ int print_cpuinfo(void)
#elif defined CONFIG_MACH_SUN8I_A33
printf("CPU: Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_A83T
- printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
+ printf("CPU: Allwinner A83T (SUN8I %04x rev. %x)\n", sunxi_get_sram_id(), sunxi_get_revision());

Please wrap the line to under 80 characters.

Otherwise,

Post by Icenowy Zheng
#elif defined CONFIG_MACH_SUN8I_H3
printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_R40
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
For more options, visit https://groups.google.com/d/optout.

[Icenowy Zheng]

A83T SoC has two part of CPUCFG configurations -- one part is at
0x01700000, which contains most of the controls, and is like the one in
A80; the another part is at 0x01f01c00 (like other post-sun6i SoCs), but
contains now only a few registers.

Call it SUNXI_R_CPUCFG_BASE, like what the BSP Linux source code did.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index a96680d8e8..5c74714084 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -179,6 +179,8 @@ defined(CONFIG_MACH_SUN50I)
!defined CONFIG_MACH_SUN8I_A83T && \
!defined CONFIG_MACH_SUN8I_R40
#define SUNXI_CPUCFG_BASE 0x01f01c00
+#elif defined CONFIG_MACH_SUN8I_A83T
+#define SUNXI_R_CPUCFG_BASE 0x01f01c00
#endif

#define SUNXI_R_TWI_BASE 0x01f02400

[Chen-Yu Tsai]

Post by Icenowy Zheng
A83T SoC has two part of CPUCFG configurations -- one part is at
0x01700000, which contains most of the controls, and is like the one in
A80; the another part is at 0x01f01c00 (like other post-sun6i SoCs), but
contains now only a few registers.
Call it SUNXI_R_CPUCFG_BASE, like what the BSP Linux source code did.
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index a96680d8e8..5c74714084 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -179,6 +179,8 @@ defined(CONFIG_MACH_SUN50I)
!defined CONFIG_MACH_SUN8I_A83T && \
!defined CONFIG_MACH_SUN8I_R40
#define SUNXI_CPUCFG_BASE 0x01f01c00
+#elif defined CONFIG_MACH_SUN8I_A83T
+#define SUNXI_R_CPUCFG_BASE 0x01f01c00
#endif

Since this is unrelated to CPUCFG (which we might use later on),
Just put it in a separate #ifdef section, instead of with the
other CPUCFG ones.

ChenYu

Post by Icenowy Zheng
#define SUNXI_R_TWI_BASE 0x01f02400
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
For more options, visit https://groups.google.com/d/optout.

[Chen-Yu Tsai]

Post by Chen-Yu Tsai

Post by Icenowy Zheng
A83T SoC has two part of CPUCFG configurations -- one part is at
0x01700000, which contains most of the controls, and is like the one in
A80; the another part is at 0x01f01c00 (like other post-sun6i SoCs), but
contains now only a few registers.
Call it SUNXI_R_CPUCFG_BASE, like what the BSP Linux source code did.
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index a96680d8e8..5c74714084 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -179,6 +179,8 @@ defined(CONFIG_MACH_SUN50I)
!defined CONFIG_MACH_SUN8I_A83T && \
!defined CONFIG_MACH_SUN8I_R40
#define SUNXI_CPUCFG_BASE 0x01f01c00
+#elif defined CONFIG_MACH_SUN8I_A83T
+#define SUNXI_R_CPUCFG_BASE 0x01f01c00
#endif

Since this is unrelated to CPUCFG (which we might use later on),
Just put it in a separate #ifdef section, instead of with the
other CPUCFG ones.

Also this looks like you don't define CPUCFG, which you later use
in the implementation? Can you elaborate on that?

ChenYu

[Icenowy Zheng]

From: Chen-Yu Tsai <***@csie.org>

The A80/A83T SoCs has a different CPUCFG register layout, likely due to
having 2 clusters. The A83T SoC has also a small extra CPUCFG part
located at single cluster SoCs' CPUCFG address (in CPUs domain).

Add a cpucfg header file for it, rename the original cpucfg.h to
cpucfg_sun4i.h and add a new cpucfg.h to automatically switch between
the two cpucfg header file.

Signed-off-by: Chen-Yu Tsai <***@csie.org>
Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/include/asm/arch-sunxi/cpucfg.h | 64 +++---------------------
arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h | 68 ++++++++++++++++++++++++++
arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 60 +++++++++++++++++++++++
3 files changed, 134 insertions(+), 58 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h

diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg.h b/arch/arm/include/asm/arch-sunxi/cpucfg.h
index 297cdd28c0..cf60ff81b6 100644
--- a/arch/arm/include/asm/arch-sunxi/cpucfg.h
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg.h
@@ -1,7 +1,5 @@
/*
- * Sunxi A31 CPUCFG register definition.
- *
- * (C) Copyright 2014 Hans de Goede <***@redhat.com
+ * (C) Copyright 2017 Icenowy Zheng <***@aosc.io>
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -9,60 +7,10 @@
#ifndef _SUNXI_CPUCFG_H
#define _SUNXI_CPUCFG_H

-#include <linux/compiler.h>
-#include <linux/types.h>
-
-#ifndef __ASSEMBLY__
-
-struct __packed sunxi_cpucfg_cpu {
- u32 rst; /* base + 0x0 */
- u32 ctrl; /* base + 0x4 */
- u32 status; /* base + 0x8 */
- u8 res[0x34]; /* base + 0xc */
-};
-
-struct __packed sunxi_cpucfg_reg {
- u8 res0[0x40]; /* 0x000 */
- struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
- u8 res1[0x44]; /* 0x140 */
- u32 gen_ctrl; /* 0x184 */
- u32 l2_status; /* 0x188 */
- u8 res2[0x4]; /* 0x18c */
- u32 event_in; /* 0x190 */
- u8 res3[0xc]; /* 0x194 */
- u32 super_standy_flag; /* 0x1a0 */
- u32 priv0; /* 0x1a4 */
- u32 priv1; /* 0x1a8 */
- u8 res4[0x4]; /* 0x1ac */
- u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
- u32 cpu1_pwroff; /* 0x1b4 sun7i only */
- u8 res5[0x2c]; /* 0x1b8 */
- u32 dbg_ctrl1; /* 0x1e4 */
- u8 res6[0x18]; /* 0x1e8 */
- u32 idle_cnt0_low; /* 0x200 */
- u32 idle_cnt0_high; /* 0x204 */
- u32 idle_cnt0_ctrl; /* 0x208 */
- u8 res8[0x4]; /* 0x20c */
- u32 idle_cnt1_low; /* 0x210 */
- u32 idle_cnt1_high; /* 0x214 */
- u32 idle_cnt1_ctrl; /* 0x218 */
- u8 res9[0x4]; /* 0x21c */
- u32 idle_cnt2_low; /* 0x220 */
- u32 idle_cnt2_high; /* 0x224 */
- u32 idle_cnt2_ctrl; /* 0x228 */
- u8 res10[0x4]; /* 0x22c */
- u32 idle_cnt3_low; /* 0x230 */
- u32 idle_cnt3_high; /* 0x234 */
- u32 idle_cnt3_ctrl; /* 0x238 */
- u8 res11[0x4]; /* 0x23c */
- u32 idle_cnt4_low; /* 0x240 */
- u32 idle_cnt4_high; /* 0x244 */
- u32 idle_cnt4_ctrl; /* 0x248 */
- u8 res12[0x34]; /* 0x24c */
- u32 cnt64_ctrl; /* 0x280 */
- u32 cnt64_low; /* 0x284 */
- u32 cnt64_high; /* 0x288 */
-};
+#if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN9I)
+#include <asm/arch/cpucfg_sun9i.h>
+#else
+#include <asm/arch/cpucfg_sun4i.h>
+#endif

-#endif /* __ASSEMBLY__ */
#endif /* _SUNXI_CPUCFG_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.
+ *
+ * (C) Copyright 2014 Hans de Goede <***@redhat.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN4I_H
+#define _SUNXI_CPUCFG_SUN4I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cpu {
+ u32 rst; /* base + 0x0 */
+ u32 ctrl; /* base + 0x4 */
+ u32 status; /* base + 0x8 */
+ u8 res[0x34]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ u8 res0[0x40]; /* 0x000 */
+ struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
+ u8 res1[0x44]; /* 0x140 */
+ u32 gen_ctrl; /* 0x184 */
+ u32 l2_status; /* 0x188 */
+ u8 res2[0x4]; /* 0x18c */
+ u32 event_in; /* 0x190 */
+ u8 res3[0xc]; /* 0x194 */
+ u32 super_standy_flag; /* 0x1a0 */
+ u32 priv0; /* 0x1a4 */
+ u32 priv1; /* 0x1a8 */
+ u8 res4[0x4]; /* 0x1ac */
+ u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
+ u32 cpu1_pwroff; /* 0x1b4 sun7i only */
+ u8 res5[0x2c]; /* 0x1b8 */
+ u32 dbg_ctrl1; /* 0x1e4 */
+ u8 res6[0x18]; /* 0x1e8 */
+ u32 idle_cnt0_low; /* 0x200 */
+ u32 idle_cnt0_high; /* 0x204 */
+ u32 idle_cnt0_ctrl; /* 0x208 */
+ u8 res8[0x4]; /* 0x20c */
+ u32 idle_cnt1_low; /* 0x210 */
+ u32 idle_cnt1_high; /* 0x214 */
+ u32 idle_cnt1_ctrl; /* 0x218 */
+ u8 res9[0x4]; /* 0x21c */
+ u32 idle_cnt2_low; /* 0x220 */
+ u32 idle_cnt2_high; /* 0x224 */
+ u32 idle_cnt2_ctrl; /* 0x228 */
+ u8 res10[0x4]; /* 0x22c */
+ u32 idle_cnt3_low; /* 0x230 */
+ u32 idle_cnt3_high; /* 0x234 */
+ u32 idle_cnt3_ctrl; /* 0x238 */
+ u8 res11[0x4]; /* 0x23c */
+ u32 idle_cnt4_low; /* 0x240 */
+ u32 idle_cnt4_high; /* 0x244 */
+ u32 idle_cnt4_ctrl; /* 0x248 */
+ u8 res12[0x34]; /* 0x24c */
+ u32 cnt64_ctrl; /* 0x280 */
+ u32 cnt64_low; /* 0x284 */
+ u32 cnt64_high; /* 0x288 */
+};
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN4I_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
new file mode 100644
index 0000000000..2ce315736b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
@@ -0,0 +1,60 @@
+/*
+ * Sunxi A80 CPUCFG register definition.
+ *
+ * (C) Copyright 2016 Chen-Yu Tsai <***@csie.org>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN9I_H
+#define _SUNXI_CPUCFG_SUN9I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#define CPUCFG_CX_CTRL0_L1_RST_DISABLE(core) BIT(core)
+
+#define CPUCFG_CX_STATUS_STANDBYWFI(core) BIT(16 + core)
+
+#define CPUCFG_CX_RST_CORE(core) BIT(core)
+#define CPUCFG_CX_RST_NEON(core) BIT(4 + core) /* A15 only */
+#define CPUCFG_CX_RST_L2 BIT(8)
+#define CPUCFG_CX_RST_HRESET BIT(12)
+#define CPUCFG_CX_RST_DBG(core) BIT(16 + core)
+#define CPUCFG_CX_RST_ETM(core) BIT(20 + core)
+#define CPUCFG_CX_RST_SOC_DBG BIT(24)
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cluster {
+ u32 ctrl0; /* base + 0x0 */
+ u32 ctrl1; /* base + 0x4 */
+ u32 adb400_pwrdnreqn; /* base + 0x8 */
+ u8 res[0x4]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ struct sunxi_cpucfg_cluster cluster[2]; /* 0x00 */
+ u8 res0[0x8]; /* 0x20 */
+ u32 gen_ctrl0; /* 0x28 */
+ u32 gen_ctrl1; /* 0x2c */
+ u32 cluster_status[2]; /* 0x30 */
+ u8 res1[0x4]; /* 0x38 */
+ u32 irq_fiq_status; /* 0x3c */
+ u32 irq_fiq_mask; /* 0x40 */
+ u8 res2[0x3c]; /* 0x44 */
+ u32 cluster_reset[2]; /* 0x80 */
+ u32 gic_jtag_reset; /* 0x88 */
+};
+
+#ifdef CONFIG_MACH_SUN8I_A83T
+struct __packed sunxi_r_cpucfg_reg {
+ u8 res1[0x30]; /* 0x00 */
+ u32 cpu_rst[2]; /* 0x30 */
+ u8 res2[0x16c]; /* 0x38 */
+ u32 priv0; /* 0x1a4 */
+};
+#endif /* CONFIG_MACH_SUN8I_A83T */
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN9I_H */

[Chen-Yu Tsai]

Post by Icenowy Zheng
The A80/A83T SoCs has a different CPUCFG register layout, likely due to
having 2 clusters. The A83T SoC has also a small extra CPUCFG part
located at single cluster SoCs' CPUCFG address (in CPUs domain).
Add a cpucfg header file for it, rename the original cpucfg.h to
cpucfg_sun4i.h and add a new cpucfg.h to automatically switch between
the two cpucfg header file.
---
arch/arm/include/asm/arch-sunxi/cpucfg.h | 64 +++---------------------
arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h | 68 ++++++++++++++++++++++++++
arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 60 +++++++++++++++++++++++
3 files changed, 134 insertions(+), 58 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg.h b/arch/arm/include/asm/arch-sunxi/cpucfg.h
index 297cdd28c0..cf60ff81b6 100644
--- a/arch/arm/include/asm/arch-sunxi/cpucfg.h
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg.h
@@ -1,7 +1,5 @@
/*
- * Sunxi A31 CPUCFG register definition.
- *
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -9,60 +7,10 @@
#ifndef _SUNXI_CPUCFG_H
#define _SUNXI_CPUCFG_H
-#include <linux/compiler.h>
-#include <linux/types.h>
-
-#ifndef __ASSEMBLY__
-
-struct __packed sunxi_cpucfg_cpu {
- u32 rst; /* base + 0x0 */
- u32 ctrl; /* base + 0x4 */
- u32 status; /* base + 0x8 */
- u8 res[0x34]; /* base + 0xc */
-};
-
-struct __packed sunxi_cpucfg_reg {
- u8 res0[0x40]; /* 0x000 */
- struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
- u8 res1[0x44]; /* 0x140 */
- u32 gen_ctrl; /* 0x184 */
- u32 l2_status; /* 0x188 */
- u8 res2[0x4]; /* 0x18c */
- u32 event_in; /* 0x190 */
- u8 res3[0xc]; /* 0x194 */
- u32 super_standy_flag; /* 0x1a0 */
- u32 priv0; /* 0x1a4 */
- u32 priv1; /* 0x1a8 */
- u8 res4[0x4]; /* 0x1ac */
- u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
- u32 cpu1_pwroff; /* 0x1b4 sun7i only */
- u8 res5[0x2c]; /* 0x1b8 */
- u32 dbg_ctrl1; /* 0x1e4 */
- u8 res6[0x18]; /* 0x1e8 */
- u32 idle_cnt0_low; /* 0x200 */
- u32 idle_cnt0_high; /* 0x204 */
- u32 idle_cnt0_ctrl; /* 0x208 */
- u8 res8[0x4]; /* 0x20c */
- u32 idle_cnt1_low; /* 0x210 */
- u32 idle_cnt1_high; /* 0x214 */
- u32 idle_cnt1_ctrl; /* 0x218 */
- u8 res9[0x4]; /* 0x21c */
- u32 idle_cnt2_low; /* 0x220 */
- u32 idle_cnt2_high; /* 0x224 */
- u32 idle_cnt2_ctrl; /* 0x228 */
- u8 res10[0x4]; /* 0x22c */
- u32 idle_cnt3_low; /* 0x230 */
- u32 idle_cnt3_high; /* 0x234 */
- u32 idle_cnt3_ctrl; /* 0x238 */
- u8 res11[0x4]; /* 0x23c */
- u32 idle_cnt4_low; /* 0x240 */
- u32 idle_cnt4_high; /* 0x244 */
- u32 idle_cnt4_ctrl; /* 0x248 */
- u8 res12[0x34]; /* 0x24c */
- u32 cnt64_ctrl; /* 0x280 */
- u32 cnt64_low; /* 0x284 */
- u32 cnt64_high; /* 0x288 */
-};
+#if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN9I)
+#include <asm/arch/cpucfg_sun9i.h>
+#else
+#include <asm/arch/cpucfg_sun4i.h>
+#endif
-#endif /* __ASSEMBLY__ */
#endif /* _SUNXI_CPUCFG_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN4I_H
+#define _SUNXI_CPUCFG_SUN4I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cpu {
+ u32 rst; /* base + 0x0 */
+ u32 ctrl; /* base + 0x4 */
+ u32 status; /* base + 0x8 */
+ u8 res[0x34]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ u8 res0[0x40]; /* 0x000 */
+ struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
+ u8 res1[0x44]; /* 0x140 */
+ u32 gen_ctrl; /* 0x184 */
+ u32 l2_status; /* 0x188 */
+ u8 res2[0x4]; /* 0x18c */
+ u32 event_in; /* 0x190 */
+ u8 res3[0xc]; /* 0x194 */
+ u32 super_standy_flag; /* 0x1a0 */
+ u32 priv0; /* 0x1a4 */
+ u32 priv1; /* 0x1a8 */
+ u8 res4[0x4]; /* 0x1ac */
+ u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
+ u32 cpu1_pwroff; /* 0x1b4 sun7i only */
+ u8 res5[0x2c]; /* 0x1b8 */
+ u32 dbg_ctrl1; /* 0x1e4 */
+ u8 res6[0x18]; /* 0x1e8 */
+ u32 idle_cnt0_low; /* 0x200 */
+ u32 idle_cnt0_high; /* 0x204 */
+ u32 idle_cnt0_ctrl; /* 0x208 */
+ u8 res8[0x4]; /* 0x20c */
+ u32 idle_cnt1_low; /* 0x210 */
+ u32 idle_cnt1_high; /* 0x214 */
+ u32 idle_cnt1_ctrl; /* 0x218 */
+ u8 res9[0x4]; /* 0x21c */
+ u32 idle_cnt2_low; /* 0x220 */
+ u32 idle_cnt2_high; /* 0x224 */
+ u32 idle_cnt2_ctrl; /* 0x228 */
+ u8 res10[0x4]; /* 0x22c */
+ u32 idle_cnt3_low; /* 0x230 */
+ u32 idle_cnt3_high; /* 0x234 */
+ u32 idle_cnt3_ctrl; /* 0x238 */
+ u8 res11[0x4]; /* 0x23c */
+ u32 idle_cnt4_low; /* 0x240 */
+ u32 idle_cnt4_high; /* 0x244 */
+ u32 idle_cnt4_ctrl; /* 0x248 */
+ u8 res12[0x34]; /* 0x24c */
+ u32 cnt64_ctrl; /* 0x280 */
+ u32 cnt64_low; /* 0x284 */
+ u32 cnt64_high; /* 0x288 */
+};
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN4I_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
new file mode 100644
index 0000000000..2ce315736b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
@@ -0,0 +1,60 @@
+/*
+ * Sunxi A80 CPUCFG register definition.
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN9I_H
+#define _SUNXI_CPUCFG_SUN9I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#define CPUCFG_CX_CTRL0_L1_RST_DISABLE(core) BIT(core)
+
+#define CPUCFG_CX_STATUS_STANDBYWFI(core) BIT(16 + core)
+
+#define CPUCFG_CX_RST_CORE(core) BIT(core)
+#define CPUCFG_CX_RST_NEON(core) BIT(4 + core) /* A15 only */
+#define CPUCFG_CX_RST_L2 BIT(8)
+#define CPUCFG_CX_RST_HRESET BIT(12)
+#define CPUCFG_CX_RST_DBG(core) BIT(16 + core)
+#define CPUCFG_CX_RST_ETM(core) BIT(20 + core)
+#define CPUCFG_CX_RST_SOC_DBG BIT(24)
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cluster {
+ u32 ctrl0; /* base + 0x0 */
+ u32 ctrl1; /* base + 0x4 */
+ u32 adb400_pwrdnreqn; /* base + 0x8 */
+ u8 res[0x4]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ struct sunxi_cpucfg_cluster cluster[2]; /* 0x00 */
+ u8 res0[0x8]; /* 0x20 */
+ u32 gen_ctrl0; /* 0x28 */
+ u32 gen_ctrl1; /* 0x2c */
+ u32 cluster_status[2]; /* 0x30 */
+ u8 res1[0x4]; /* 0x38 */
+ u32 irq_fiq_status; /* 0x3c */
+ u32 irq_fiq_mask; /* 0x40 */
+ u8 res2[0x3c]; /* 0x44 */
+ u32 cluster_reset[2]; /* 0x80 */
+ u32 gic_jtag_reset; /* 0x88 */
+};
+
+#ifdef CONFIG_MACH_SUN8I_A83T
+struct __packed sunxi_r_cpucfg_reg {
+ u8 res1[0x30]; /* 0x00 */
+ u32 cpu_rst[2]; /* 0x30 */
+ u8 res2[0x16c]; /* 0x38 */
+ u32 priv0; /* 0x1a4 */
+};
+#endif /* CONFIG_MACH_SUN8I_A83T */
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN9I_H */
--
2.12.2

This patch looks a bit weird. Do you have --find-renames and --find-copies
set when you run `git format-patch`? It should help with renames.

ChenYu

[Icenowy Zheng]

Post by Icenowy Zheng

Post by Icenowy Zheng
The A80/A83T SoCs has a different CPUCFG register layout, likely due

to

Post by Icenowy Zheng
having 2 clusters. The A83T SoC has also a small extra CPUCFG part
located at single cluster SoCs' CPUCFG address (in CPUs domain).
Add a cpucfg header file for it, rename the original cpucfg.h to
cpucfg_sun4i.h and add a new cpucfg.h to automatically switch between
the two cpucfg header file.
---
arch/arm/include/asm/arch-sunxi/cpucfg.h | 64

+++---------------------

Post by Icenowy Zheng
arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h | 68

++++++++++++++++++++++++++

Post by Icenowy Zheng
arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 60

+++++++++++++++++++++++

Post by Icenowy Zheng
3 files changed, 134 insertions(+), 58 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg.h

b/arch/arm/include/asm/arch-sunxi/cpucfg.h

Post by Icenowy Zheng
index 297cdd28c0..cf60ff81b6 100644
--- a/arch/arm/include/asm/arch-sunxi/cpucfg.h
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg.h
@@ -1,7 +1,5 @@
/*
- * Sunxi A31 CPUCFG register definition.
- *
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -9,60 +7,10 @@
#ifndef _SUNXI_CPUCFG_H
#define _SUNXI_CPUCFG_H
-#include <linux/compiler.h>
-#include <linux/types.h>
-
-#ifndef __ASSEMBLY__
-
-struct __packed sunxi_cpucfg_cpu {
- u32 rst; /* base + 0x0 */
- u32 ctrl; /* base + 0x4 */
- u32 status; /* base + 0x8 */
- u8 res[0x34]; /* base + 0xc */
-};
-
-struct __packed sunxi_cpucfg_reg {
- u8 res0[0x40]; /* 0x000 */
- struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
- u8 res1[0x44]; /* 0x140 */
- u32 gen_ctrl; /* 0x184 */
- u32 l2_status; /* 0x188 */
- u8 res2[0x4]; /* 0x18c */
- u32 event_in; /* 0x190 */
- u8 res3[0xc]; /* 0x194 */
- u32 super_standy_flag; /* 0x1a0 */
- u32 priv0; /* 0x1a4 */
- u32 priv1; /* 0x1a8 */
- u8 res4[0x4]; /* 0x1ac */
- u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
- u32 cpu1_pwroff; /* 0x1b4 sun7i only */
- u8 res5[0x2c]; /* 0x1b8 */
- u32 dbg_ctrl1; /* 0x1e4 */
- u8 res6[0x18]; /* 0x1e8 */
- u32 idle_cnt0_low; /* 0x200 */
- u32 idle_cnt0_high; /* 0x204 */
- u32 idle_cnt0_ctrl; /* 0x208 */
- u8 res8[0x4]; /* 0x20c */
- u32 idle_cnt1_low; /* 0x210 */
- u32 idle_cnt1_high; /* 0x214 */
- u32 idle_cnt1_ctrl; /* 0x218 */
- u8 res9[0x4]; /* 0x21c */
- u32 idle_cnt2_low; /* 0x220 */
- u32 idle_cnt2_high; /* 0x224 */
- u32 idle_cnt2_ctrl; /* 0x228 */
- u8 res10[0x4]; /* 0x22c */
- u32 idle_cnt3_low; /* 0x230 */
- u32 idle_cnt3_high; /* 0x234 */
- u32 idle_cnt3_ctrl; /* 0x238 */
- u8 res11[0x4]; /* 0x23c */
- u32 idle_cnt4_low; /* 0x240 */
- u32 idle_cnt4_high; /* 0x244 */
- u32 idle_cnt4_ctrl; /* 0x248 */
- u8 res12[0x34]; /* 0x24c */
- u32 cnt64_ctrl; /* 0x280 */
- u32 cnt64_low; /* 0x284 */
- u32 cnt64_high; /* 0x288 */
-};
+#if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN9I)
+#include <asm/arch/cpucfg_sun9i.h>
+#else
+#include <asm/arch/cpucfg_sun4i.h>
+#endif
-#endif /* __ASSEMBLY__ */
#endif /* _SUNXI_CPUCFG_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

Post by Icenowy Zheng
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN4I_H
+#define _SUNXI_CPUCFG_SUN4I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cpu {
+ u32 rst; /* base + 0x0 */
+ u32 ctrl; /* base + 0x4 */
+ u32 status; /* base + 0x8 */
+ u8 res[0x34]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ u8 res0[0x40]; /* 0x000 */
+ struct sunxi_cpucfg_cpu cpu[4]; /* 0x040 */
+ u8 res1[0x44]; /* 0x140 */
+ u32 gen_ctrl; /* 0x184 */
+ u32 l2_status; /* 0x188 */
+ u8 res2[0x4]; /* 0x18c */
+ u32 event_in; /* 0x190 */
+ u8 res3[0xc]; /* 0x194 */
+ u32 super_standy_flag; /* 0x1a0 */
+ u32 priv0; /* 0x1a4 */
+ u32 priv1; /* 0x1a8 */
+ u8 res4[0x4]; /* 0x1ac */
+ u32 cpu1_pwr_clamp; /* 0x1b0 sun7i only */
+ u32 cpu1_pwroff; /* 0x1b4 sun7i only */
+ u8 res5[0x2c]; /* 0x1b8 */
+ u32 dbg_ctrl1; /* 0x1e4 */
+ u8 res6[0x18]; /* 0x1e8 */
+ u32 idle_cnt0_low; /* 0x200 */
+ u32 idle_cnt0_high; /* 0x204 */
+ u32 idle_cnt0_ctrl; /* 0x208 */
+ u8 res8[0x4]; /* 0x20c */
+ u32 idle_cnt1_low; /* 0x210 */
+ u32 idle_cnt1_high; /* 0x214 */
+ u32 idle_cnt1_ctrl; /* 0x218 */
+ u8 res9[0x4]; /* 0x21c */
+ u32 idle_cnt2_low; /* 0x220 */
+ u32 idle_cnt2_high; /* 0x224 */
+ u32 idle_cnt2_ctrl; /* 0x228 */
+ u8 res10[0x4]; /* 0x22c */
+ u32 idle_cnt3_low; /* 0x230 */
+ u32 idle_cnt3_high; /* 0x234 */
+ u32 idle_cnt3_ctrl; /* 0x238 */
+ u8 res11[0x4]; /* 0x23c */
+ u32 idle_cnt4_low; /* 0x240 */
+ u32 idle_cnt4_high; /* 0x244 */
+ u32 idle_cnt4_ctrl; /* 0x248 */
+ u8 res12[0x34]; /* 0x24c */
+ u32 cnt64_ctrl; /* 0x280 */
+ u32 cnt64_low; /* 0x284 */
+ u32 cnt64_high; /* 0x288 */
+};
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN4I_H */
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h

b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h

Post by Icenowy Zheng
new file mode 100644
index 0000000000..2ce315736b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
@@ -0,0 +1,60 @@
+/*
+ * Sunxi A80 CPUCFG register definition.
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN9I_H
+#define _SUNXI_CPUCFG_SUN9I_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+#define CPUCFG_CX_CTRL0_L1_RST_DISABLE(core) BIT(core)
+
+#define CPUCFG_CX_STATUS_STANDBYWFI(core) BIT(16 + core)
+
+#define CPUCFG_CX_RST_CORE(core) BIT(core)
+#define CPUCFG_CX_RST_NEON(core) BIT(4 + core) /* A15

only */

Post by Icenowy Zheng
+#define CPUCFG_CX_RST_L2 BIT(8)
+#define CPUCFG_CX_RST_HRESET BIT(12)
+#define CPUCFG_CX_RST_DBG(core) BIT(16 +

core)

Post by Icenowy Zheng
+#define CPUCFG_CX_RST_ETM(core) BIT(20 +

core)

Post by Icenowy Zheng
+#define CPUCFG_CX_RST_SOC_DBG BIT(24)
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cluster {
+ u32 ctrl0; /* base + 0x0 */
+ u32 ctrl1; /* base + 0x4 */
+ u32 adb400_pwrdnreqn; /* base + 0x8 */
+ u8 res[0x4]; /* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+ struct sunxi_cpucfg_cluster cluster[2]; /* 0x00 */
+ u8 res0[0x8]; /* 0x20 */
+ u32 gen_ctrl0; /* 0x28 */
+ u32 gen_ctrl1; /* 0x2c */
+ u32 cluster_status[2]; /* 0x30 */
+ u8 res1[0x4]; /* 0x38 */
+ u32 irq_fiq_status; /* 0x3c */
+ u32 irq_fiq_mask; /* 0x40 */
+ u8 res2[0x3c]; /* 0x44 */
+ u32 cluster_reset[2]; /* 0x80 */
+ u32 gic_jtag_reset; /* 0x88 */
+};
+
+#ifdef CONFIG_MACH_SUN8I_A83T
+struct __packed sunxi_r_cpucfg_reg {
+ u8 res1[0x30]; /* 0x00 */
+ u32 cpu_rst[2]; /* 0x30 */
+ u8 res2[0x16c]; /* 0x38 */
+ u32 priv0; /* 0x1a4 */
+};
+#endif /* CONFIG_MACH_SUN8I_A83T */
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN9I_H */
--
2.12.2

This patch looks a bit weird. Do you have --find-renames and
--find-copies
set when you run `git format-patch`? It should help with renames.

Oh forget it...

Sorry.

Post by Icenowy Zheng
ChenYu

[Maxime Ripard]

Post by Icenowy Zheng
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.

Calling that file sun4i doesn't make much sense, the A31 is part of
sun6i, and the cpucfg block wasn't there with sun4i.

Maxime

[Icenowy Zheng]

Post by Icenowy Zheng

Post by Icenowy Zheng
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

Post by Icenowy Zheng
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.

Calling that file sun4i doesn't make much sense, the A31 is part of
sun6i, and the cpucfg block wasn't there with sun4i.

So... call it sun6i?

Post by Icenowy Zheng
Maxime

[Chen-Yu Tsai]

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h

Post by Icenowy Zheng
new file mode 100644
index 0000000000..af1a1d56c9
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun4i.h
@@ -0,0 +1,68 @@
+/*
+ * Sunxi A31 CPUCFG register definition.

Calling that file sun4i doesn't make much sense, the A31 is part of
sun6i, and the cpucfg block wasn't there with sun4i.

So... call it sun6i?

No. The original cpucfg.h is for the A20 and the A31, and all the single
cluster SoC that followed.

The A83T's CPUCFG has more in common with the A80. You can just keep
cpucfg.h unchanged, and rename the new one cpucfg-mcpm.h. You don't
even need the generic cpucfg.h stub header you added.

Regards
ChenYu

[Icenowy Zheng]

A83T come with two clusters of CPU, for each cluster 1 the new registers
are in the reserved spaces after the original cluster 0.

Make the registers to have an array with length 2 (2 clusters), and
change the current code to reference only cluster 0 registers.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/cpu/armv7/sunxi/psci.c | 2 +-
arch/arm/include/asm/arch-sunxi/prcm.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index b3a34de1aa..8caef6a85f 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -144,7 +144,7 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
struct sunxi_prcm_reg *prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;

- sunxi_power_switch(&prcm->cpu_pwr_clamp[cpu], &prcm->cpu_pwroff,
+ sunxi_power_switch(&prcm->cpu_pwr_clamp[0][cpu], &prcm->cpu_pwroff[0],
on, cpu);
}
#endif /* CONFIG_MACH_SUN7I */
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h b/arch/arm/include/asm/arch-sunxi/prcm.h
index ae3880b13b..c2a6e39ffc 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -220,16 +220,16 @@ struct __packed sunxi_prcm_reg {
u8 res5[0x3c]; /* 0x0b4 */
u32 clk_outd; /* 0x0f0 */
u8 res6[0xc]; /* 0x0f4 */
- u32 cpu_pwroff; /* 0x100 */
- u8 res7[0xc]; /* 0x104 */
+ u32 cpu_pwroff[2]; /* 0x100 */
+ u8 res7[0x8]; /* 0x108 */
u32 vdd_sys_pwroff; /* 0x110 */
u8 res8[0x4]; /* 0x114 */
u32 gpu_pwroff; /* 0x118 */
u8 res9[0x4]; /* 0x11c */
u32 vdd_pwr_reset; /* 0x120 */
u8 res10[0x1c]; /* 0x124 */
- u32 cpu_pwr_clamp[4]; /* 0x140 but first one is actually unused */
- u8 res11[0x30]; /* 0x150 */
+ u32 cpu_pwr_clamp[2][4];/* 0x140 but first one is actually unused */
+ u8 res11[0x20]; /* 0x160 */
u32 dram_pwr; /* 0x180 */
u8 res12[0xc]; /* 0x184 */
u32 dram_tst; /* 0x190 */

[Chen-Yu Tsai]

Post by Icenowy Zheng
A83T come with two clusters of CPU, for each cluster 1 the new registers
are in the reserved spaces after the original cluster 0.
Make the registers to have an array with length 2 (2 clusters), and
change the current code to reference only cluster 0 registers.
---
arch/arm/cpu/armv7/sunxi/psci.c | 2 +-
arch/arm/include/asm/arch-sunxi/prcm.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index b3a34de1aa..8caef6a85f 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -144,7 +144,7 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
struct sunxi_prcm_reg *prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
- sunxi_power_switch(&prcm->cpu_pwr_clamp[cpu], &prcm->cpu_pwroff,
+ sunxi_power_switch(&prcm->cpu_pwr_clamp[0][cpu], &prcm->cpu_pwroff[0],
on, cpu);
}
#endif /* CONFIG_MACH_SUN7I */
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h b/arch/arm/include/asm/arch-sunxi/prcm.h
index ae3880b13b..c2a6e39ffc 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -220,16 +220,16 @@ struct __packed sunxi_prcm_reg {
u8 res5[0x3c]; /* 0x0b4 */
u32 clk_outd; /* 0x0f0 */
u8 res6[0xc]; /* 0x0f4 */
- u32 cpu_pwroff; /* 0x100 */
- u8 res7[0xc]; /* 0x104 */
+ u32 cpu_pwroff[2]; /* 0x100 */
+ u8 res7[0x8]; /* 0x108 */
u32 vdd_sys_pwroff; /* 0x110 */
u8 res8[0x4]; /* 0x114 */
u32 gpu_pwroff; /* 0x118 */
u8 res9[0x4]; /* 0x11c */
u32 vdd_pwr_reset; /* 0x120 */
u8 res10[0x1c]; /* 0x124 */
- u32 cpu_pwr_clamp[4]; /* 0x140 but first one is actually unused */
- u8 res11[0x30]; /* 0x150 */
+ u32 cpu_pwr_clamp[2][4];/* 0x140 but first one is actually unused */

The comment needs to be fixed. It only applies to the single cluster SoCs.

Otherwise,

Post by Icenowy Zheng
+ u8 res11[0x20]; /* 0x160 */
u32 dram_pwr; /* 0x180 */
u8 res12[0xc]; /* 0x184 */
u32 dram_tst; /* 0x190 */
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
For more options, visit https://groups.google.com/d/optout.

[Icenowy Zheng]

From: Chen-Yu Tsai <***@csie.org>

Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
contains 4 cores. A80 is Cortex-A15 + Cortex-A7 configuration, while
A83T has two clusters of Cortex-A7.

This patch adds a basic version that allows bringing up the four cores
in the first cluster. The structure is based on existing sunxi PSCI code.

Signed-off-by: Chen-Yu Tsai <***@csie.org>
[Icenowy: adapt for A83T]
Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +
arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 258 +++++++++++++++++++++++++++++++++++
2 files changed, 262 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index 8c026ff052..c789f686fd 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,8 +14,12 @@ obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o

ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_MACH_SUN8I_A83T
+obj-$(CONFIG_ARMV7_PSCI) += psci-mcpm.o
+else
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
+endif

ifdef CONFIG_SPL_BUILD
obj-y += fel_utils.o
diff --git a/arch/arm/cpu/armv7/sunxi/psci-mcpm.c b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
new file mode 100644
index 0000000000..ba8d669c7e
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2016
+ * Author: Chen-Yu Tsai <***@csie.org>
+ *
+ * Based on assembly code by Marc Zyngier <***@arm.com>,
+ * which was based on code by Carl van Schaik <***@ok-labs.com>.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include <config.h>
+#include <common.h>
+
+#include <asm/arch/cpu.h>
+#include <asm/arch/cpucfg.h>
+#include <asm/arch/prcm.h>
+#include <asm/armv7.h>
+#include <asm/io.h>
+#include <asm/psci.h>
+#include <asm/secure.h>
+
+#include <linux/bitops.h>
+
+/*
+ * NOTE dense CPU IDs (0~3 for first cluster of 4 cores, 4~7 for the
+ * second cluster) are used throughout the PSCI code. Any MPIDR style
+ * values must be converted.
+ */
+
+/*
+ * Provide a dense CPU ID for 2-cluster systems. This must be coded in
+ * assembly as it gets called from psci_stack_setup, when the stack isn't
+ * available yet.
+ *
+ * Only r0 and r3 is usable. r8 - r12 are available if this function is
+ * only called from psci_stack_setup, which we cannot guarantee.
+ */
+u32 __secure __naked psci_get_cpu_id(void)
+{
+ asm volatile (
+ "mrc p15, 0, r3, c0, c0, 5 @ Get MPIDR\n"
+ "lsr r0, r3, #6\n"
+ "and r3, r3, #3\n"
+ "and r0, r0, #4\n"
+ "orr r0, r0, r3\n"
+ "bx lr\n"
+ );
+
+ /*
+ * The last five lines are the compiler generated assembly code for
+ *
+ * return (reg & 0x3) | (((reg >> 8) & 0x1) << 2);
+ *
+ * We can't guarantee that all compilers correctly use only r0 and
+ * r3, so we use inline assembly here.
+ */
+}
+
+static void __secure cp15_write_cntp_tval(u32 tval)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
+}
+
+static void __secure cp15_write_cntp_ctl(u32 val)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 1" : : "r" (val));
+}
+
+static u32 __secure cp15_read_cntp_ctl(void)
+{
+ u32 val;
+
+ asm volatile ("mrc p15, 0, %0, c14, c2, 1" : "=r" (val));
+
+ return val;
+}
+
+#define ONE_US (COUNTER_FREQUENCY / 1000000)
+
+/* Use a different name to avoid clashing with the non-secure function */
+static void __secure __udelay_sec(unsigned long us)
+{
+ u32 reg = ONE_US * us;
+
+ cp15_write_cntp_tval(reg);
+ isb();
+ cp15_write_cntp_ctl(3);
+
+ do {
+ isb();
+ reg = cp15_read_cntp_ctl();
+ } while (!(reg & BIT(2)));
+
+ cp15_write_cntp_ctl(0);
+ isb();
+}
+
+static void __secure clamp_release(u32 *clamp)
+{
+ writel(0xff, clamp);
+ __udelay_sec(10);
+ writel(0xfe, clamp);
+ __udelay_sec(10);
+ writel(0xf8, clamp);
+ __udelay_sec(10);
+ writel(0xf0, clamp);
+ __udelay_sec(10);
+ writel(0x00, clamp);
+}
+
+static void __secure clamp_set(u32 *clamp)
+{
+ writel(0xff, clamp);
+}
+
+static void __secure sunxi_core_power_switch(u32 *clamp, u32 *pwroff,
+ bool on, int cpu)
+{
+ if (on) {
+ /* Release power clamp */
+ clamp_release(clamp);
+
+ __udelay_sec(20);
+
+ /* Clear power gating */
+ clrbits_le32(pwroff, BIT(cpu));
+ } else {
+ /* Set power gating */
+ setbits_le32(pwroff, BIT(cpu));
+
+ __udelay_sec(20);
+
+ /* Activate power clamp */
+ clamp_set(clamp);
+ }
+}
+
+static int __secure sunxi_cluster_is_a7(int cluster)
+{
+#ifdef CONFIG_MACH_SUN8I_A83T
+ return 1;
+#else
+ return (clustter == 0);
+#endif
+}
+
+static void __secure sunxi_cpu_set_power(int cluster, int cpu, bool on)
+{
+ struct sunxi_prcm_reg *prcm =
+ (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+
+ sunxi_core_power_switch(&prcm->cpu_pwr_clamp[cluster][cpu],
+ &prcm->cpu_pwroff[cluster], on, cpu);
+}
+
+static u32 __secure cp15_read_scr(void)
+{
+ u32 scr;
+
+ asm volatile ("mrc p15, 0, %0, c1, c1, 0" : "=r" (scr));
+
+ return scr;
+}
+
+static void __secure cp15_write_scr(u32 scr)
+{
+ asm volatile ("mcr p15, 0, %0, c1, c1, 0" : : "r" (scr));
+ isb();
+}
+
+int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr, u32 pc)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+#ifdef CONFIG_MACH_SUN8I_A83T
+ struct sunxi_r_cpucfg_reg *r_cpucfg =
+ (struct sunxi_r_cpucfg_reg *)SUNXI_R_CPUCFG_BASE;
+#else
+ struct sunxi_prcm_reg *prcm =
+ (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+#endif
+ u32 cluster = (mpidr >> 8) & 0x1;
+ u32 cpu = mpidr & 0x3;
+ u32 cpuid = cpu | (cluster << 2);
+
+ /* TODO We don't support multi-cluster yet */
+ if (cluster > 0)
+ return ARM_PSCI_RET_INVAL;
+
+ /* store target PC */
+ psci_save_target_pc(cpuid, pc);
+
+ /* Set secondary core power on PC */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ writel((u32)&psci_cpu_entry, &r_cpucfg->priv0);
+#else
+ writel((u32)&psci_cpu_entry, &prcm->cpu_soft_entry);
+#endif
+
+ /* Assert power-on reset on target CPU */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ clrbits_le32(&r_cpucfg->cpu_rst[cluster], BIT(cpu));
+#else
+ clrbits_le32(&prcm->cpu_rst[cluster], BIT(cpu));
+#endif
+
+ /* Cortex-A7: hold L1 cache reset disable signal low */
+ if (sunxi_cluster_is_a7(cluster))
+ clrbits_le32(&cpucfg->cluster[cluster].ctrl0,
+ CPUCFG_CX_CTRL0_L1_RST_DISABLE(cpu));
+
+ /* Lock CPU (Disable external debug access) */
+ clrbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_DBG(cpu));
+
+ /* Cortex-A7: Assert ETM reset */
+ if (sunxi_cluster_is_a7(cluster))
+ clrbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_ETM(cpu));
+
+ /*
+ * Allwinner code also asserts resets for NEON on A15. According
+ * to ARM manuals, asserting power-on reset is sufficient.
+ */
+
+ /* Power up target CPU */
+ sunxi_cpu_set_power(cluster, cpu, true);
+
+ /* De-assert power-on reset on target CPU */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ setbits_le32(&r_cpucfg->cpu_rst[cluster], BIT(cpu));
+#else
+ setbits_le32(&prcm->cpu_rst[cluster], BIT(cpu));
+#endif
+
+ /* De-assert core reset on target CPU */
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_CORE(cpu));
+
+ /* Cortex-A7: De-assert ETM reset */
+ if (sunxi_cluster_is_a7(cluster))
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_ETM(cpu));
+
+ /* Unlock CPU (Disable external debug access) */
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_DBG(cpu));
+
+ return ARM_PSCI_RET_SUCCESS;
+}
+
+void __secure psci_arch_init(void)
+{
+ u32 reg;
+
+ reg = cp15_read_scr();
+ reg &= ~BIT(0); /* Secure mode */
+ cp15_write_scr(reg);
+}

[Chen-Yu Tsai]

Post by Icenowy Zheng
Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
contains 4 cores. A80 is Cortex-A15 + Cortex-A7 configuration, while
A83T has two clusters of Cortex-A7.
This patch adds a basic version that allows bringing up the four cores
in the first cluster. The structure is based on existing sunxi PSCI code.
[Icenowy: adapt for A83T]
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +
arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 258 +++++++++++++++++++++++++++++++++++
2 files changed, 262 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c

I suggest using --find-copies and --find-copies-harder when you
generate the patch.
It should limit the patch to differences between psci.c and psci-mcpm.c.

Post by Icenowy Zheng
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index 8c026ff052..c789f686fd 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,8 +14,12 @@ obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o
ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_MACH_SUN8I_A83T
+obj-$(CONFIG_ARMV7_PSCI) += psci-mcpm.o
+else
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
+endif
ifdef CONFIG_SPL_BUILD
obj-y += fel_utils.o
diff --git a/arch/arm/cpu/armv7/sunxi/psci-mcpm.c b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
new file mode 100644
index 0000000000..ba8d669c7e
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2016
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include <config.h>
+#include <common.h>
+
+#include <asm/arch/cpu.h>
+#include <asm/arch/cpucfg.h>
+#include <asm/arch/prcm.h>
+#include <asm/armv7.h>
+#include <asm/io.h>
+#include <asm/psci.h>
+#include <asm/secure.h>
+
+#include <linux/bitops.h>
+
+/*
+ * NOTE dense CPU IDs (0~3 for first cluster of 4 cores, 4~7 for the
+ * second cluster) are used throughout the PSCI code. Any MPIDR style
+ * values must be converted.
+ */
+
+/*
+ * Provide a dense CPU ID for 2-cluster systems. This must be coded in
+ * assembly as it gets called from psci_stack_setup, when the stack isn't
+ * available yet.
+ *
+ * Only r0 and r3 is usable. r8 - r12 are available if this function is
+ * only called from psci_stack_setup, which we cannot guarantee.
+ */
+u32 __secure __naked psci_get_cpu_id(void)
+{
+ asm volatile (
+ "lsr r0, r3, #6\n"
+ "and r3, r3, #3\n"
+ "and r0, r0, #4\n"
+ "orr r0, r0, r3\n"
+ "bx lr\n"
+ );
+
+ /*
+ * The last five lines are the compiler generated assembly code for
+ *
+ * return (reg & 0x3) | (((reg >> 8) & 0x1) << 2);
+ *
+ * We can't guarantee that all compilers correctly use only r0 and
+ * r3, so we use inline assembly here.
+ */
+}
+
+static void __secure cp15_write_cntp_tval(u32 tval)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
+}
+
+static void __secure cp15_write_cntp_ctl(u32 val)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 1" : : "r" (val));
+}
+
+static u32 __secure cp15_read_cntp_ctl(void)
+{
+ u32 val;
+
+ asm volatile ("mrc p15, 0, %0, c14, c2, 1" : "=r" (val));
+
+ return val;
+}
+
+#define ONE_US (COUNTER_FREQUENCY / 1000000)
+
+/* Use a different name to avoid clashing with the non-secure function */
+static void __secure __udelay_sec(unsigned long us)
+{
+ u32 reg = ONE_US * us;
+
+ cp15_write_cntp_tval(reg);
+ isb();
+ cp15_write_cntp_ctl(3);
+
+ do {
+ isb();
+ reg = cp15_read_cntp_ctl();
+ } while (!(reg & BIT(2)));
+
+ cp15_write_cntp_ctl(0);
+ isb();
+}
+
+static void __secure clamp_release(u32 *clamp)
+{
+ writel(0xff, clamp);
+ __udelay_sec(10);
+ writel(0xfe, clamp);
+ __udelay_sec(10);
+ writel(0xf8, clamp);
+ __udelay_sec(10);
+ writel(0xf0, clamp);
+ __udelay_sec(10);
+ writel(0x00, clamp);
+}
+
+static void __secure clamp_set(u32 *clamp)
+{
+ writel(0xff, clamp);
+}
+
+static void __secure sunxi_core_power_switch(u32 *clamp, u32 *pwroff,
+ bool on, int cpu)
+{
+ if (on) {
+ /* Release power clamp */
+ clamp_release(clamp);
+
+ __udelay_sec(20);
+
+ /* Clear power gating */
+ clrbits_le32(pwroff, BIT(cpu));
+ } else {
+ /* Set power gating */
+ setbits_le32(pwroff, BIT(cpu));
+
+ __udelay_sec(20);
+
+ /* Activate power clamp */
+ clamp_set(clamp);
+ }
+}
+
+static int __secure sunxi_cluster_is_a7(int cluster)
+{
+#ifdef CONFIG_MACH_SUN8I_A83T
+ return 1;
+#else
+ return (clustter == 0);
+#endif
+}
+
+static void __secure sunxi_cpu_set_power(int cluster, int cpu, bool on)
+{
+ struct sunxi_prcm_reg *prcm =
+ (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+
+ sunxi_core_power_switch(&prcm->cpu_pwr_clamp[cluster][cpu],
+ &prcm->cpu_pwroff[cluster], on, cpu);
+}
+
+static u32 __secure cp15_read_scr(void)
+{
+ u32 scr;
+
+ asm volatile ("mrc p15, 0, %0, c1, c1, 0" : "=r" (scr));
+
+ return scr;
+}
+
+static void __secure cp15_write_scr(u32 scr)
+{
+ asm volatile ("mcr p15, 0, %0, c1, c1, 0" : : "r" (scr));
+ isb();
+}
+
+int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr, u32 pc)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+#ifdef CONFIG_MACH_SUN8I_A83T
+ struct sunxi_r_cpucfg_reg *r_cpucfg =
+ (struct sunxi_r_cpucfg_reg *)SUNXI_R_CPUCFG_BASE;
+#else
+ struct sunxi_prcm_reg *prcm =
+ (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+#endif
+ u32 cluster = (mpidr >> 8) & 0x1;
+ u32 cpu = mpidr & 0x3;
+ u32 cpuid = cpu | (cluster << 2);
+
+ /* TODO We don't support multi-cluster yet */
+ if (cluster > 0)
+ return ARM_PSCI_RET_INVAL;
+
+ /* store target PC */
+ psci_save_target_pc(cpuid, pc);
+
+ /* Set secondary core power on PC */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ writel((u32)&psci_cpu_entry, &r_cpucfg->priv0);
+#else
+ writel((u32)&psci_cpu_entry, &prcm->cpu_soft_entry);
+#endif

Could you take a look at the non-MCPM version and move the #ifdefs
into separate functions? Basically we want the main functions to
be as clean and descriptive as possible. You could also structure
it as two patches: the first adding the original A80 version, and
the second modifying it to support the A83T as well.

I'll send a fix for the non-MCPM version fixing the entry address.

Regards
ChenYu

Post by Icenowy Zheng
+
+ /* Assert power-on reset on target CPU */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ clrbits_le32(&r_cpucfg->cpu_rst[cluster], BIT(cpu));
+#else
+ clrbits_le32(&prcm->cpu_rst[cluster], BIT(cpu));
+#endif
+
+ /* Cortex-A7: hold L1 cache reset disable signal low */
+ if (sunxi_cluster_is_a7(cluster))
+ clrbits_le32(&cpucfg->cluster[cluster].ctrl0,
+ CPUCFG_CX_CTRL0_L1_RST_DISABLE(cpu));
+
+ /* Lock CPU (Disable external debug access) */
+ clrbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_DBG(cpu));
+
+ /* Cortex-A7: Assert ETM reset */
+ if (sunxi_cluster_is_a7(cluster))
+ clrbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_ETM(cpu));
+
+ /*
+ * Allwinner code also asserts resets for NEON on A15. According
+ * to ARM manuals, asserting power-on reset is sufficient.
+ */
+
+ /* Power up target CPU */
+ sunxi_cpu_set_power(cluster, cpu, true);
+
+ /* De-assert power-on reset on target CPU */
+#ifdef CONFIG_MACH_SUN8I_A83T
+ setbits_le32(&r_cpucfg->cpu_rst[cluster], BIT(cpu));
+#else
+ setbits_le32(&prcm->cpu_rst[cluster], BIT(cpu));
+#endif
+
+ /* De-assert core reset on target CPU */
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_CORE(cpu));
+
+ /* Cortex-A7: De-assert ETM reset */
+ if (sunxi_cluster_is_a7(cluster))
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_ETM(cpu));
+
+ /* Unlock CPU (Disable external debug access) */
+ setbits_le32(&cpucfg->cluster_reset[cluster],
+ CPUCFG_CX_RST_DBG(cpu));
+
+ return ARM_PSCI_RET_SUCCESS;
+}
+
+void __secure psci_arch_init(void)
+{
+ u32 reg;
+
+ reg = cp15_read_scr();
+ reg &= ~BIT(0); /* Secure mode */
+ cp15_write_scr(reg);
+}
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
For more options, visit https://groups.google.com/d/optout.

[Maxime Ripard]

Hi,

Post by Icenowy Zheng
Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
contains 4 cores. A80 is Cortex-A15 + Cortex-A7 configuration, while
A83T has two clusters of Cortex-A7.
This patch adds a basic version that allows bringing up the four cores
in the first cluster. The structure is based on existing sunxi PSCI code.
[Icenowy: adapt for A83T]

Ideally, Marc should be in Cc in order to review this.

Post by Icenowy Zheng
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +
arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 258 +++++++++++++++++++++++++++++++++++
2 files changed, 262 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index 8c026ff052..c789f686fd 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,8 +14,12 @@ obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o
ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_MACH_SUN8I_A83T
+obj-$(CONFIG_ARMV7_PSCI) += psci-mcpm.o
+else
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
+endif
ifdef CONFIG_SPL_BUILD
obj-y += fel_utils.o
diff --git a/arch/arm/cpu/armv7/sunxi/psci-mcpm.c b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
new file mode 100644
index 0000000000..ba8d669c7e
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2016
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include <config.h>
+#include <common.h>
+
+#include <asm/arch/cpu.h>
+#include <asm/arch/cpucfg.h>
+#include <asm/arch/prcm.h>
+#include <asm/armv7.h>
+#include <asm/io.h>
+#include <asm/psci.h>
+#include <asm/secure.h>
+
+#include <linux/bitops.h>
+
+/*
+ * NOTE dense CPU IDs (0~3 for first cluster of 4 cores, 4~7 for the
+ * second cluster) are used throughout the PSCI code. Any MPIDR style
+ * values must be converted.
+ */
+
+/*
+ * Provide a dense CPU ID for 2-cluster systems. This must be coded in
+ * assembly as it gets called from psci_stack_setup, when the stack isn't
+ * available yet.
+ *
+ * Only r0 and r3 is usable. r8 - r12 are available if this function is
+ * only called from psci_stack_setup, which we cannot guarantee.
+ */
+u32 __secure __naked psci_get_cpu_id(void)
+{
+ asm volatile (
+ "lsr r0, r3, #6\n"
+ "and r3, r3, #3\n"
+ "and r0, r0, #4\n"
+ "orr r0, r0, r3\n"
+ "bx lr\n"
+ );
+
+ /*
+ * The last five lines are the compiler generated assembly code for
+ *
+ * return (reg & 0x3) | (((reg >> 8) & 0x1) << 2);
+ *
+ * We can't guarantee that all compilers correctly use only r0 and
+ * r3, so we use inline assembly here.
+ */
+}
+
+static void __secure cp15_write_cntp_tval(u32 tval)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
+}
+
+static void __secure cp15_write_cntp_ctl(u32 val)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 1" : : "r" (val));
+}
+
+static u32 __secure cp15_read_cntp_ctl(void)
+{
+ u32 val;
+
+ asm volatile ("mrc p15, 0, %0, c14, c2, 1" : "=r" (val));
+
+ return val;
+}
+
+#define ONE_US (COUNTER_FREQUENCY / 1000000)
+
+/* Use a different name to avoid clashing with the non-secure function */
+static void __secure __udelay_sec(unsigned long us)
+{
+ u32 reg = ONE_US * us;
+
+ cp15_write_cntp_tval(reg);
+ isb();
+ cp15_write_cntp_ctl(3);
+
+ do {
+ isb();
+ reg = cp15_read_cntp_ctl();
+ } while (!(reg & BIT(2)));
+
+ cp15_write_cntp_ctl(0);
+ isb();
+}
+
+static void __secure clamp_release(u32 *clamp)
+{
+ writel(0xff, clamp);
+ __udelay_sec(10);
+ writel(0xfe, clamp);
+ __udelay_sec(10);
+ writel(0xf8, clamp);
+ __udelay_sec(10);
+ writel(0xf0, clamp);
+ __udelay_sec(10);
+ writel(0x00, clamp);
+}
+
+static void __secure clamp_set(u32 *clamp)
+{
+ writel(0xff, clamp);
+}
+
+static void __secure sunxi_core_power_switch(u32 *clamp, u32 *pwroff,
+ bool on, int cpu)
+{
+ if (on) {
+ /* Release power clamp */
+ clamp_release(clamp);
+
+ __udelay_sec(20);
+
+ /* Clear power gating */
+ clrbits_le32(pwroff, BIT(cpu));
+ } else {
+ /* Set power gating */
+ setbits_le32(pwroff, BIT(cpu));
+
+ __udelay_sec(20);
+
+ /* Activate power clamp */
+ clamp_set(clamp);
+ }
+}
+
+static int __secure sunxi_cluster_is_a7(int cluster)
+{
+#ifdef CONFIG_MACH_SUN8I_A83T
+ return 1;
+#else
+ return (clustter == 0);

This doesn't compile.


Maxime

[Icenowy Zheng]

Post by Maxime Ripard
Hi,

Post by Icenowy Zheng
Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
contains 4 cores. A80 is Cortex-A15 + Cortex-A7 configuration, while
A83T has two clusters of Cortex-A7.
This patch adds a basic version that allows bringing up the four

cores

Post by Icenowy Zheng
in the first cluster. The structure is based on existing sunxi PSCI

code.

Post by Icenowy Zheng
[Icenowy: adapt for A83T]

Ideally, Marc should be in Cc in order to review this.

Who?

Post by Maxime Ripard

Post by Icenowy Zheng
---
arch/arm/cpu/armv7/sunxi/Makefile | 4 +
arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 258

+++++++++++++++++++++++++++++++++++

Post by Icenowy Zheng
2 files changed, 262 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile

b/arch/arm/cpu/armv7/sunxi/Makefile

Post by Icenowy Zheng
index 8c026ff052..c789f686fd 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,8 +14,12 @@ obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o
ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_MACH_SUN8I_A83T
+obj-$(CONFIG_ARMV7_PSCI) += psci-mcpm.o
+else
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
+endif
ifdef CONFIG_SPL_BUILD
obj-y += fel_utils.o
diff --git a/arch/arm/cpu/armv7/sunxi/psci-mcpm.c

b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c

Post by Icenowy Zheng
new file mode 100644
index 0000000000..ba8d669c7e
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2016
+ *
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include <config.h>
+#include <common.h>
+
+#include <asm/arch/cpu.h>
+#include <asm/arch/cpucfg.h>
+#include <asm/arch/prcm.h>
+#include <asm/armv7.h>
+#include <asm/io.h>
+#include <asm/psci.h>
+#include <asm/secure.h>
+
+#include <linux/bitops.h>
+
+/*
+ * NOTE dense CPU IDs (0~3 for first cluster of 4 cores, 4~7 for the
+ * second cluster) are used throughout the PSCI code. Any MPIDR

style

Post by Icenowy Zheng
+ * values must be converted.
+ */
+
+/*
+ * Provide a dense CPU ID for 2-cluster systems. This must be coded

in

Post by Icenowy Zheng
+ * assembly as it gets called from psci_stack_setup, when the stack

isn't

Post by Icenowy Zheng
+ * available yet.
+ *
+ * Only r0 and r3 is usable. r8 - r12 are available if this function

is

Post by Icenowy Zheng
+ * only called from psci_stack_setup, which we cannot guarantee.
+ */
+u32 __secure __naked psci_get_cpu_id(void)
+{
+ asm volatile (
+ "lsr r0, r3, #6\n"
+ "and r3, r3, #3\n"
+ "and r0, r0, #4\n"
+ "orr r0, r0, r3\n"
+ "bx lr\n"
+ );
+
+ /*
+ * The last five lines are the compiler generated assembly code for
+ *
+ * return (reg & 0x3) | (((reg >> 8) & 0x1) << 2);
+ *
+ * We can't guarantee that all compilers correctly use only r0 and
+ * r3, so we use inline assembly here.
+ */
+}
+
+static void __secure cp15_write_cntp_tval(u32 tval)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
+}
+
+static void __secure cp15_write_cntp_ctl(u32 val)
+{
+ asm volatile ("mcr p15, 0, %0, c14, c2, 1" : : "r" (val));
+}
+
+static u32 __secure cp15_read_cntp_ctl(void)
+{
+ u32 val;
+
+ asm volatile ("mrc p15, 0, %0, c14, c2, 1" : "=r" (val));
+
+ return val;
+}
+
+#define ONE_US (COUNTER_FREQUENCY / 1000000)
+
+/* Use a different name to avoid clashing with the non-secure

function */

Post by Icenowy Zheng
+static void __secure __udelay_sec(unsigned long us)
+{
+ u32 reg = ONE_US * us;
+
+ cp15_write_cntp_tval(reg);
+ isb();
+ cp15_write_cntp_ctl(3);
+
+ do {
+ isb();
+ reg = cp15_read_cntp_ctl();
+ } while (!(reg & BIT(2)));
+
+ cp15_write_cntp_ctl(0);
+ isb();
+}
+
+static void __secure clamp_release(u32 *clamp)
+{
+ writel(0xff, clamp);
+ __udelay_sec(10);
+ writel(0xfe, clamp);
+ __udelay_sec(10);
+ writel(0xf8, clamp);
+ __udelay_sec(10);
+ writel(0xf0, clamp);
+ __udelay_sec(10);
+ writel(0x00, clamp);
+}
+
+static void __secure clamp_set(u32 *clamp)
+{
+ writel(0xff, clamp);
+}
+
+static void __secure sunxi_core_power_switch(u32 *clamp, u32

*pwroff,

Post by Icenowy Zheng
+ bool on, int cpu)
+{
+ if (on) {
+ /* Release power clamp */
+ clamp_release(clamp);
+
+ __udelay_sec(20);
+
+ /* Clear power gating */
+ clrbits_le32(pwroff, BIT(cpu));
+ } else {
+ /* Set power gating */
+ setbits_le32(pwroff, BIT(cpu));
+
+ __udelay_sec(20);
+
+ /* Activate power clamp */
+ clamp_set(clamp);
+ }
+}
+
+static int __secure sunxi_cluster_is_a7(int cluster)
+{
+#ifdef CONFIG_MACH_SUN8I_A83T
+ return 1;
+#else
+ return (clustter == 0);

This doesn't compile.
Maxime

[Marc Zyngier]

Post by Maxime Ripard
Hi,

Post by Icenowy Zheng
Allwinner A80 and A83T SoCs have two clusters of CPU, each cluster
contains 4 cores. A80 is Cortex-A15 + Cortex-A7 configuration, while
A83T has two clusters of Cortex-A7.
This patch adds a basic version that allows bringing up the four

cores

Post by Icenowy Zheng
in the first cluster. The structure is based on existing sunxi PSCI

code.

Post by Icenowy Zheng
[Icenowy: adapt for A83T]

Ideally, Marc should be in Cc in order to review this.

Who?

Nobody.

M.

[Icenowy Zheng]

As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.

Signed-off-by: Icenowy Zheng <***@aosc.io>
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

config MACH_SUN8I_H3
bool "sun8i (Allwinner H3)"

[Chen-Yu Tsai]

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.

I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

ChenYu

[Icenowy Zheng]

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.

GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

Post by Icenowy Zheng
ChenYu

[Chen-Yu Tsai]

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I believe
the GIC is working exactly as it is supposed to with regards to its
input signals.

Allwinner's security extensions implementation simply does not properly
forward the AXI secure bit when the e-fuse's secure bit isn't burned.

ChenYu

[Maxime Ripard]

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I believe
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not properly
forward the AXI secure bit when the e-fuse's secure bit isn't burned.

Is that on all revisions, or just the revB ?

Maxime

[Icenowy Zheng]

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't burned.

Is that on all revisions, or just the revB ?

All revisions, and even all SoCs after sun8iw6 that we
know, although the GIC issue seems to only show on
multi-cluster SoCs.

The A83T RevA/RevB difference is about CPU0/CPU4 (the first
CPUs in both clusters) bring up.

Post by Chen-Yu Tsai
Maxime

[Chen-Yu Tsai]

On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I believe
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not properly
forward the AXI secure bit when the e-fuse's secure bit isn't burned.

Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's more
of a guess really, but I think it's a logical one. If the e-fuse isn't
programmed, the TZPC doesn't work, and access to all secure peripherals
still work, even from non-secure mode. The only one that does work is
the secure SRAM.

The GIC still has the banked secure/non-secure registers, just that all
cores access the secure bank, even when in non-secure mode. The workaround
is to use the alias set of non-secure registers in Linux.

I'm not about to waste one of my boards programming the e-fuse to find
out the hard way though. The CCU doesn't have a security setting. It
might as well be secure-only. If one sets the e-fuse and the SoC's
security extensions work as they're supposed to, then it will no longer
work with mainline Linux. Or any software we have for that matter.

Regards
ChenYu

[Marc Zyngier]

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by default
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly stopped
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I believe
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not properly
forward the AXI secure bit when the e-fuse's secure bit isn't burned.

Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's more
of a guess really, but I think it's a logical one. If the e-fuse isn't
programmed, the TZPC doesn't work, and access to all secure peripherals
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that all
cores access the secure bank, even when in non-secure mode. The workaround
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Post by Chen-Yu Tsai
I'm not about to waste one of my boards programming the e-fuse to find
out the hard way though. The CCU doesn't have a security setting. It
might as well be secure-only. If one sets the e-fuse and the SoC's
security extensions work as they're supposed to, then it will no longer
work with mainline Linux. Or any software we have for that matter.

Fair enough.

Thanks,

M.

[Icenowy Zheng]

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
I'm not about to waste one of my boards programming the e-fuse to

find

Post by Chen-Yu Tsai
out the hard way though. The CCU doesn't have a security setting. It
might as well be secure-only. If one sets the e-fuse and the SoC's
security extensions work as they're supposed to, then it will no

longer

Post by Chen-Yu Tsai
work with mainline Linux. Or any software we have for that matter.

Fair enough.
Thanks,
M.

[Marc Zyngier]

Post by Icenowy Zheng

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.

Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

M.

[Maxime Ripard]

Post by Marc Zyngier

Post by Icenowy Zheng

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

The initial idea was to use PSCI for the core bringup, which afaik
requires Linux to run non-secure, right?

If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Maxime

[Marc Zyngier]

Post by Maxime Ripard

Post by Marc Zyngier

Post by Icenowy Zheng

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once the kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

The initial idea was to use PSCI for the core bringup, which afaik
requires Linux to run non-secure, right?

The SMC instruction is available from both PL1 exception levels, so
calling into PSCI from secure should be possible (assuming your PSCI
code is driven from Monitor mode).

Post by Maxime Ripard
If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.

Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

Thanks,

M.

[Maxime Ripard]

Post by Marc Zyngier

Post by Maxime Ripard
If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.
Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.

It fails at boot, and stops with:
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0

It looks like it won't be easy to support. I guess we could just go
for smp_ops, and if someone really cares one day about it, we'll
always have the option to support it then.

Maxime

[André Przywara]

On 02/07/17 15:17, Maxime Ripard wrote:

Hi,

Post by Maxime Ripard

Post by Marc Zyngier

Post by Maxime Ripard
If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.
Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0

Those messages are normal and happen on every machine. The Xen VGIC
implementation cannot clear the active flag [1] (for more complex
reasons), and fortunately Linux and other OSes actually don't need it,
so we get away with it. What the kernel does here is to make sure that
no IRQ is active, which is basically a NOP on a pristine and just
initialized (V)GIC.

But you said that it stopped at boot? Are you sure that your Xen setup
works in the first place? Xen on A20 seems to be somewhat supported, by
maybe there is some other A83T speciality that gets in the way?

A more reliable and easier to debug test would be KVM, I guess.
You can use kvmtool[2] instead of QEMU if that is too complex to setup:
$ lkvm run -k zImage -p console=ttyS0
gives you a shell in a guest, if you want to have a proper rootfs:
$ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

Cheers,
Andre.

[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/vgic-v2.c;hb=HEAD#l487
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
(just checkout and "make" on the target)

Post by Maxime Ripard
It looks like it won't be easy to support. I guess we could just go
for smp_ops, and if someone really cares one day about it, we'll
always have the option to support it then.
Maxime

[Maxime Ripard]

Hi,

Post by André Przywara

Post by Maxime Ripard

Post by Marc Zyngier

Post by Maxime Ripard
If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.
Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0

Those messages are normal and happen on every machine. The Xen VGIC
implementation cannot clear the active flag [1] (for more complex
reasons), and fortunately Linux and other OSes actually don't need it,
so we get away with it. What the kernel does here is to make sure that
no IRQ is active, which is basically a NOP on a pristine and just
initialized (V)GIC.

Ok.

Post by André Przywara
But you said that it stopped at boot? Are you sure that your Xen setup
works in the first place? Xen on A20 seems to be somewhat supported, by
maybe there is some other A83T speciality that gets in the way?

It's basically stalled, yes, and didn't start dom0. I tested Xen in
the past on an A33, and it worked like a charm, but it might very well
be a PEBKAC.

Post by André Przywara
A more reliable and easier to debug test would be KVM, I guess.
$ lkvm run -k zImage -p console=ttyS0
$ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

I didn't know kvmtool, thanks for the tip.

Icenowy seems to had it running, so I guess we can just focus on KVM
for now.

Maxime

[Mr. Fülöp]

Hello!

First of all I would like to thank you all for your amazing contribution! More I dive into understanding the kernel, more I appreciate your work and more I learn.

As Marc Zyngier said:
"Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side. "

I am that "someone" who wants to run Xen on a A83T chipset. I managed to build the latest kernel 4.15, the Xen hypervisor and got stuck on compiling the u-boot kernel with virtualization, HYP enabled and boot non secure:

bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

Not knowing if A83T supports virtualization and the above mentioned features, I tried to enable these in Kconfig and build the latest u-boot kernel. Unfortunatelly even if it compiled, I have a strange loop at boot...I think it is related to the CPU allocation...


As you can see I am a noob in terms of kernel hacking, but I want, with your help, to achieve this implementation of Xen.

In this regard I would appreciate your help and guidance.

Can you provide the files/patches and/or a tutorial on how I could accomplish my goal?


Many thanks!


Alex

[Mr. Fülöp]

This is the loop I was talking about:

U-Boot 2018.03-rc1-00078-gb215307-dirty (Feb 05 2018 - 12:50:50 +0000)

Loading Environment from FAT... Unable to use mmc 1:0... Failed (-5)
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
In: serial
Out: serial
Err: serial
Net: No ethernet found.
starting USB...
USB0: data abort
pc : [<bff8ca3a>] lr : [<bff8ca1d>]
reloc pc : [<4a01ba3a>] lr : [<4a01ba1d>]
sp : bbf4ec40 ip : bbf584ec fp : 00000002
r10: bffb577c r9 : bbf50ee8 r8 : 00000000
r7 : ffffffff r6 : bbf5773c r5 : bffb39a4 r4 : bbf57550
r3 : ffffffff r2 : 01c00004 r1 : ffff3f8f r0 : 00000000
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...



Any hints? Thank you!

[Jagan Teki]

Post by Mr. Fülöp
U-Boot 2018.03-rc1-00078-gb215307-dirty (Feb 05 2018 - 12:50:50 +0000)
Loading Environment from FAT... Unable to use mmc 1:0... Failed (-5)
Loading Environment from MMC... *** Warning - bad CRC, using default environment
Failed (-5)
In: serial
Out: serial
Err: serial
Net: No ethernet found.
starting USB...
USB0: data abort

Check with this patch [1]

[1] https://patchwork.ozlabs.org/patch/869304/

[Mr. Fülöp]

Thank you all for your help! I really appreciate your feedback!

Following your advice I booted XEN ... Yeeeyyy
BUT got stuck here:

Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705) debug=y Fri Feb 2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1

I am trying to recompile Xen and see if I can get further...
I will keep you updated with my progress... :)

Please let me know your opinion on this!
Is it feasible?

Thank you guys!

Alex

[Jagan Teki]

Post by Mr. Fülöp
Thank you all for your help! I really appreciate your feedback!
Following your advice I booted XEN ... Yeeeyyy
Xen 4.11-unstable
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1
I am trying to recompile Xen and see if I can get further...
I will keep you updated with my progress... :)
Please let me know your opinion on this!
Is it feasible?

Is OTG cable connected on board? can you try to unplug it and use DCIN.

[Mr. Fülöp]

Hi Guys,

I think I reached a dead end...
Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
I compiled many xen version, but my feeling is that in the u-boot is sth. that makes Xen hang...

Any suggestions?

Thank you in advance!

=========================================

Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705) debug=y Fri Feb 2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1 ----- HERE IT HANGS -----

[Icenowy Zheng]

Post by Mr. Fülöp
Hi Guys,
I think I reached a dead end...
Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
I compiled many xen version, but my feeling is that in the u-boot is
sth. that makes Xen hang...
Any suggestions?
Thank you in advance!
=========================================
Xen 4.11-unstable
6.1.1-9) 6.1.1 20160705) debug=y Fri Feb 2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1 ----- HERE IT HANGS -----

I think you just met the bug we mentioned in this thread.
With this patchset applied a Linux kernel will also hang
here without ugly hack.

[Mr. Fülöp]

Hi Icenowy,

Thank you for your reply!
I worked much and got this close, so I really want to make this thing work
:)
Do you have any suggestions/patches/directions? This "ugly hack" is there
somewhere? :)

I think the issue resides on the "switching" to the next cpu...

Thank you in advance!

Alex

Post by Icenowy Zheng

Post by Mr. Fülöp
Hi Guys,
I think I reached a dead end...
Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
I compiled many xen version, but my feeling is that in the u-boot is
sth. that makes Xen hang...
Any suggestions?
Thank you in advance!
=========================================
Xen 4.11-unstable
6.1.1-9) 6.1.1 20160705) debug=y Fri Feb 2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1 ----- HERE IT HANGS -----

I think you just met the bug we mentioned in this thread.
With this patchset applied a Linux kernel will also hang
here without ugly hack.

[Icenowy Zheng]

Post by Mr. Fülöp
Hi Icenowy,
Thank you for your reply!
I worked much and got this close, so I really want to make this thing work
:)
Do you have any suggestions/patches/directions? This "ugly hack" is there
somewhere? :)

The Linux version of this hack is at [1].

[1] https://github.com/wens/linux/tree/gic-secure-workaround

Post by Mr. Fülöp
I think the issue resides on the "switching" to the next cpu...
Thank you in advance!
Alex

Post by Icenowy Zheng

Post by Mr. Fülöp
Hi Guys,
I think I reached a dead end...
Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
I compiled many xen version, but my feeling is that in the u-boot is
sth. that makes Xen hang...
Any suggestions?
Thank you in advance!
=========================================
Xen 4.11-unstable
6.1.1-9) 6.1.1 20160705) debug=y Fri Feb 2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 +0000 git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07,

rev

Post by Icenowy Zheng

Post by Mr. Fülöp
0x5
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE

Jazelle

Post by Icenowy Zheng

Post by Mr. Fülöp
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev

0x5

Post by Icenowy Zheng

Post by Mr. Fülöp
(XEN) Bringing up CPU1 ----- HERE IT HANGS -----

I think you just met the bug we mentioned in this thread.
With this patchset applied a Linux kernel will also hang
here without ugly hack.

[Mr. Fülöp]

Thanks! I will try it out and let you know the result!

[i***@aosc.io]

在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

Post by Icenowy Zheng

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
regardless of the kernel. We can have it boot non-secure once
the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

Post by Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...

[Maxime Ripard]

圚 2017-06-07 20:51Marc Zyngier 写道

Post by Marc Zyngier

于 2017幎6月7日 GMT+08:00 䞋午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

于 2017幎6月7日 GMT+08:00 䞊午11:36:27, Chen-Yu

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng
regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

Maxime

[i***@aosc.io]

在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

Post by Chen-Yu Tsai

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

Post by Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng
regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai

Post by Icenowy Zheng
working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

Post by Chen-Yu Tsai
forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).

So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

Post by Maxime Ripard
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Chen-Yu Tsai]

Post by i***@aosc.io
在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to
secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it
suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also
apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken. I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

I think you got it the other way around.

If virtualization doesn't work, despite the workaround, then there's
no need for it, and we can just do legacy SMP.

ChenYu

[i***@aosc.io]

在 2017-06-23 21:50，Chen-Yu Tsai 写道：

Post by Chen-Yu Tsai

Post by i***@aosc.io
在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to
secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it
suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also
apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken.
I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does
not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

I think you got it the other way around.
If virtualization doesn't work, despite the workaround, then there's
no need for it, and we can just do legacy SMP.

I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and
Chen-Yu's GIC workaround patchset, and *FAILED*.

The workaround patchset in fact slightly broke vGIC code by changing
a macro name -- it's easy to fix.

However, it seems that with this fixed the KVM cannot still work --
I tried to start a virtual machine, but it silently fails (no kernel
log are shown when the VM starting fails).

So, at least this workaround cannot let virtualization work.

Post by Chen-Yu Tsai
ChenYu

[Marc Zyngier]

On Sun, 2 Jul 2017 15:08:12 +0800

Post by i***@aosc.io
在 2017-06-23 21:50，Chen-Yu Tsai 写道：

Post by Chen-Yu Tsai

Post by i***@aosc.io
在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to
secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it
suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also
apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken.
I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does
not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that
does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just
that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

I think you got it the other way around.
If virtualization doesn't work, despite the workaround, then there's
no need for it, and we can just do legacy SMP.

I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and
Chen-Yu's GIC workaround patchset, and *FAILED*.
The workaround patchset in fact slightly broke vGIC code by changing
a macro name -- it's easy to fix.
However, it seems that with this fixed the KVM cannot still work --
I tried to start a virtual machine, but it silently fails (no kernel
log are shown when the VM starting fails).
So, at least this workaround cannot let virtualization work.

Before discounting it altogether, it'd be interesting to find out what
breaks exactly. How did you start the guest? What is the failure mode?

Thanks,

M.

[i***@aosc.io]

在 2017-07-02 19:22，Marc Zyngier 写道：

Post by Marc Zyngier
On Sun, 2 Jul 2017 15:08:12 +0800

Post by i***@aosc.io
在 2017-06-23 21:50，Chen-Yu Tsai 写道：

Post by Chen-Yu Tsai

Post by i***@aosc.io
在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to
secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it
suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also
apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken.
I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does
not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that
does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just
that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes
to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

I think you got it the other way around.
If virtualization doesn't work, despite the workaround, then there's
no need for it, and we can just do legacy SMP.

I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and
Chen-Yu's GIC workaround patchset, and *FAILED*.
The workaround patchset in fact slightly broke vGIC code by changing
a macro name -- it's easy to fix.
However, it seems that with this fixed the KVM cannot still work --
I tried to start a virtual machine, but it silently fails (no kernel
log are shown when the VM starting fails).
So, at least this workaround cannot let virtualization work.

Before discounting it altogether, it'd be interesting to find out what
breaks exactly. How did you start the guest? What is the failure mode?

Oh, I'm sorry. I used wrong command for it... (forgot -cpu host
parameter)

Now it works.

Virtual machine boot log is available at [1].

[1] https://pastebin.anthonos.org/view/66a9ca54

So it may be valuable to apply the workaround now?

Post by Marc Zyngier
Thanks,
M.
--
Without deviation from the norm, progress is not possible.

[Marc Zyngier]

On Sun, 2 Jul 2017 20:36:04 +0800

Post by i***@aosc.io
在 2017-07-02 19:22，Marc Zyngier 写道：

Post by Marc Zyngier
On Sun, 2 Jul 2017 15:08:12 +0800

Post by i***@aosc.io
在 2017-06-23 21:50，Chen-Yu Tsai 写道：

Post by Chen-Yu Tsai

Post by i***@aosc.io
在 2017-06-23 21:35，Maxime Ripard 写道：

Post by Maxime Ripard

Post by i***@aosc.io
在 2017-06-07 20:51，Marc Zyngier 写道：

Post by Marc Zyngier

于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier

Post by Chen-Yu Tsai

Post by Chen-Yu Tsai
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard

Post by Maxime Ripard

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng

Post by Icenowy Zheng
As we have now a basical implementation
of PSCI for A83T, enable
non-secure boot support and PSCI on A83T now.
---
arch/arm/mach-sunxi/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig

b/arch/arm/mach-sunxi/Kconfig

Post by Icenowy Zheng
index 7ced838d6a..31d29de428 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -98,8 +98,12 @@ config MACH_SUN8I_A33
config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+ select ARMV7_BOOT_SEC_DEFAULT if
OLD_SUNXI_KERNEL_COMPAT

The kernel does not work yet. Please have it boot to
secure by

default

Post by Chen-Yu Tsai

Post by Maxime Ripard

regardless of the kernel. We can have it
boot non-secure once the
kernel
has been working for a reasonable amount of time.
I don't want clueless users coming and asking why it
suddenly

stopped

Post by Chen-Yu Tsai

Post by Maxime Ripard

working. This should be an experimental feature.

Maybe you should send out the fix, and tag them to also
apply to
stable tree.
GIC is really broken, UP systems only work by chance. We
shouldn't depend on this behavior.

As I previously explained, it is not the GIC that is broken.
I

believe

Post by Chen-Yu Tsai

Post by Maxime Ripard

the GIC is working exactly as it is supposed to with
regards to its
input signals.
Allwinner's security extensions implementation simply does
not

properly

Post by Chen-Yu Tsai

Post by Maxime Ripard

forward the AXI secure bit when the e-fuse's secure bit isn't

burned.
Arghh. Puke. Now I remember this, and I wish I didn't...

Post by Chen-Yu Tsai

Post by Maxime Ripard
Is that on all revisions, or just the revB ?

It's the A80, but I'm guessing the same applies to the A83T. It's

more

Post by Chen-Yu Tsai
of a guess really, but I think it's a logical one. If the e-fuse

isn't

Post by Chen-Yu Tsai
programmed, the TZPC doesn't work, and access to all secure

peripherals

Post by Chen-Yu Tsai
still work, even from non-secure mode. The only one that
does work is
the secure SRAM.
The GIC still has the banked secure/non-secure registers, just
that

all

Post by Chen-Yu Tsai
cores access the secure bank, even when in non-secure mode. The

workaround

Post by Chen-Yu Tsai
is to use the alias set of non-secure registers in Linux.

That's a pretty dire workaround. Also, I expect that secure writes
to
GICV/GICH will not do the right thing. At this point, what is the
requirement for running non-secure?

Write Secure Boot eFUSE, which will break *all* existing softwares.

Don't do it, then.
Any other *real* use case for running non-secure? As in "Stuff that
would benefit to a user"? Because if the answer is "none" as I suspect
it is, you might as well keep the system in secure mode.

Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?

I guess it all depends on the answer to Marc's question. If
virtualization doesn't work, then we don't have any incentive anymore
to use PSCI and that would be a sensible option, yes.

I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable
non-secure, then we won't have HYP mode, then we can drop PSCI.

I think you got it the other way around.
If virtualization doesn't work, despite the workaround, then there's
no need for it, and we can just do legacy SMP.

I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and
Chen-Yu's GIC workaround patchset, and *FAILED*.
The workaround patchset in fact slightly broke vGIC code by changing
a macro name -- it's easy to fix.
However, it seems that with this fixed the KVM cannot still work --
I tried to start a virtual machine, but it silently fails (no kernel
log are shown when the VM starting fails).
So, at least this workaround cannot let virtualization work.

Before discounting it altogether, it'd be interesting to find out what
breaks exactly. How did you start the guest? What is the failure mode?

Oh, I'm sorry. I used wrong command for it... (forgot -cpu host
parameter)
Now it works.
Virtual machine boot log is available at [1].
[1] https://pastebin.anthonos.org/view/66a9ca54
So it may be valuable to apply the workaround now?

It definitely requires extra testing (booting the kernel hardly shakes
the GIC), but that's certainly encouraging. Can you run some
significant workload in a guest (kernel compilation, hackbench) and
report the results?

If the above shows that nothing bad happens, I'd like to see a full
picture of the required changes on the host kernel side and see how we
can support this in a non-invasive way.

Thanks,

M.

[Maxime Ripard]

Post by Marc Zyngier
It definitely requires extra testing (booting the kernel hardly shakes
the GIC), but that's certainly encouraging. Can you run some
significant workload in a guest (kernel compilation, hackbench) and
report the results?

Also, enabling the various IPs we have pending (like ethernet) would
be helpful I guess. So far, we just have the UARTs enabled, which are
not really going to stress the system either :)

Maxime