Discussion:
[RFC PATCH 0/8] Allwinner A83T PSCI SMP support
(too old to reply)
Icenowy Zheng
2017-06-07 00:47:13 UTC
Permalink
Raw Message
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
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:14 UTC
Permalink
Raw Message
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
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:24:40 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:15 UTC
Permalink
Raw Message
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
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:25:18 UTC
Permalink
Raw Message
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>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:16 UTC
Permalink
Raw Message
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
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:27:40 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:17 UTC
Permalink
Raw Message
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
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:48:38 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 04:13:51 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:18 UTC
Permalink
Raw Message
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 */
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:43:40 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 03:44:58 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-06-07 06:44:21 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 06:58:58 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 07:06:25 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:19 UTC
Permalink
Raw Message
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 */
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:40:47 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:20 UTC
Permalink
Raw Message
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);
+}
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 04:53:34 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-06-07 06:48:55 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 06:59:52 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-06-07 07:54:07 UTC
Permalink
Raw Message
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.
--
Jazz is not dead. It just smells funny...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 00:47:21 UTC
Permalink
Raw Message
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)"
--
2.12.2
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:36:27 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 03:40:43 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 03:47:24 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-06-07 06:50:36 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 06:58:27 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-07 07:00:31 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-06-07 12:11:12 UTC
Permalink
Raw Message
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.
--
Jazz is not dead. It just smells funny...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Icenowy Zheng
2017-06-07 12:12:21 UTC
Permalink
Raw Message
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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-06-07 12:51:48 UTC
Permalink
Raw Message
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.
--
Jazz is not dead. It just smells funny...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-06-07 13:04:27 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-06-07 14:06:55 UTC
Permalink
Raw Message
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.
--
Jazz is not dead. It just smells funny...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-07-02 14:17:33 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
André Przywara
2017-07-02 15:40:20 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-07-03 08:21:16 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
i***@aosc.io
2017-06-23 13:24:25 UTC
Permalink
Raw Message
在 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...
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-06-23 13:35:52 UTC
Permalink
Raw Message
圚 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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
i***@aosc.io
2017-06-23 13:39:05 UTC
Permalink
Raw Message
在 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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chen-Yu Tsai
2017-06-23 13:50:42 UTC
Permalink
Raw Message
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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
i***@aosc.io
2017-07-02 07:08:12 UTC
Permalink
Raw Message
在 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
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-07-02 11:22:15 UTC
Permalink
Raw Message
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.
--
Without deviation from the norm, progress is not possible.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
i***@aosc.io
2017-07-02 12:36:04 UTC
Permalink
Raw Message
在 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.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Zyngier
2017-07-02 15:27:52 UTC
Permalink
Raw Message
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.
--
Without deviation from the norm, progress is not possible.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maxime Ripard
2017-07-03 20:37:00 UTC
Permalink
Raw Message
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
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...