* [U-Boot] [RFC PATCH 1/8] sun8i: Add TZPC setup for A83T
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:24 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 2/8] sunxi: add configuration of secure SRAM " Icenowy Zheng
` (6 subsequent siblings)
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
From: "tpearson@raptorengineering.com" <tpearson@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 <tpearson@raptorengineering.com>
Signed-off-by: Icenowy Zheng <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 1/8] sun8i: Add TZPC setup for A83T
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 1/8] sun8i: Add TZPC setup for A83T Icenowy Zheng
@ 2017-06-07 3:24 ` Chen-Yu Tsai
0 siblings, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:24 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: "tpearson at raptorengineering.com" <tpearson@raptorengineering.com>
You should fix his name here.
>
> 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 <tpearson@raptorengineering.com>
> Signed-off-by: Icenowy Zheng <icenowy@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);
As mentioned in the original review of this patch, this field is read only.
There is no need to write to this register.
> +
> + /* 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
> +
> #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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 2/8] sunxi: add configuration of secure SRAM for A83T
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 1/8] sun8i: Add TZPC setup for A83T Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:25 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 3/8] sun8i: Add a macro to read the silicon revision Icenowy Zheng
` (5 subsequent siblings)
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
A83T has some secure SRAM that can be used to place the PSCI code.
Add the configuration of them.
Signed-off-by: Icenowy Zheng <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [RFC PATCH 3/8] sun8i: Add a macro to read the silicon revision
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 1/8] sun8i: Add TZPC setup for A83T Icenowy Zheng
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 2/8] sunxi: add configuration of secure SRAM " Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:27 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC Icenowy Zheng
` (4 subsequent siblings)
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
From: "tpearson@raptorengineering.com" <tpearson@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 <tpearson@raptorengineering.com>
[Icenowy: convert to macro so that it can be reused in PSCI code]
Signed-off-by: Icenowy Zheng <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 3/8] sun8i: Add a macro to read the silicon revision
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 3/8] sun8i: Add a macro to read the silicon revision Icenowy Zheng
@ 2017-06-07 3:27 ` Chen-Yu Tsai
0 siblings, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:27 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: "tpearson at raptorengineering.com" <tpearson@raptorengineering.com>
Same thing with the author name.
>
> 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 <tpearson@raptorengineering.com>
> [Icenowy: convert to macro so that it can be reused in PSCI code]
> Signed-off-by: Icenowy Zheng <icenowy@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)
Ideally, please add a macro for the register offset.
> +
> #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,
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> #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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
` (2 preceding siblings ...)
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 3/8] sun8i: Add a macro to read the silicon revision Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:48 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs Icenowy Zheng
` (3 subsequent siblings)
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
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 <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC Icenowy Zheng
@ 2017-06-07 3:48 ` Chen-Yu Tsai
2017-06-07 4:13 ` Chen-Yu Tsai
0 siblings, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:48 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> 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 <icenowy@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
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
>
> #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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC
2017-06-07 3:48 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2017-06-07 4:13 ` Chen-Yu Tsai
0 siblings, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 4:13 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 11:48 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> 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 <icenowy@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
>
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
` (3 preceding siblings ...)
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 4/8] sunxi: add SUNXI_R_CPUCFG_BASE for A83T SoC Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:43 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 6:44 ` [U-Boot] " Maxime Ripard
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 6/8] sunxi: add multi-cluster CPU PRCM register definition Icenowy Zheng
` (2 subsequent siblings)
7 siblings, 2 replies; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
From: Chen-Yu Tsai <wens@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 <wens@csie.org>
Signed-off-by: Icenowy Zheng <icenowy@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 <hdegoede at redhat.com
+ * (C) Copyright 2017 Icenowy Zheng <icenowy@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 <hdegoede@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 <wens@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs Icenowy Zheng
@ 2017-06-07 3:43 ` Chen-Yu Tsai
2017-06-07 3:44 ` Icenowy Zheng
2017-06-07 6:44 ` [U-Boot] " Maxime Ripard
1 sibling, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:43 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
> Signed-off-by: Icenowy Zheng <icenowy@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 <hdegoede@redhat.com
> + * (C) Copyright 2017 Icenowy Zheng <icenowy@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 <hdegoede@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 <wens@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
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
^ permalink raw reply [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 3:43 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2017-06-07 3:44 ` Icenowy Zheng
0 siblings, 0 replies; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 3:44 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 上午11:43:40, Chen-Yu Tsai <wens@csie.org> 写到:
>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
>> Signed-off-by: Icenowy Zheng <icenowy@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 <hdegoede@redhat.com
>> + * (C) Copyright 2017 Icenowy Zheng <icenowy@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 <hdegoede@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 <wens@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
>
>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.
>
>ChenYu
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs Icenowy Zheng
2017-06-07 3:43 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2017-06-07 6:44 ` Maxime Ripard
2017-06-07 6:58 ` Icenowy Zheng
1 sibling, 1 reply; 47+ messages in thread
From: Maxime Ripard @ 2017-06-07 6:44 UTC (permalink / raw)
To: u-boot
On Wed, Jun 07, 2017 at 08:47:18AM +0800, Icenowy Zheng wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170607/9f6844c0/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 6:44 ` [U-Boot] " Maxime Ripard
@ 2017-06-07 6:58 ` Icenowy Zheng
2017-06-07 7:06 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
0 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 6:58 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 下午2:44:21, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>On Wed, Jun 07, 2017 at 08:47:18AM +0800, Icenowy Zheng wrote:
>> 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.
So... call it sun6i?
>
>Maxime
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] Re: [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs
2017-06-07 6:58 ` Icenowy Zheng
@ 2017-06-07 7:06 ` Chen-Yu Tsai
0 siblings, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 7:06 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 2:58 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年6月7日 GMT+08:00 下午2:44:21, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>>On Wed, Jun 07, 2017 at 08:47:18AM +0800, Icenowy Zheng wrote:
>>> 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.
>
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 6/8] sunxi: add multi-cluster CPU PRCM register definition
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
` (4 preceding siblings ...)
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 5/8] sunxi: Add CPUCFG register definitions for A80/A83T SoCs Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:40 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs Icenowy Zheng
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC Icenowy Zheng
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
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 <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 6/8] sunxi: add multi-cluster CPU PRCM register definition
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 6/8] sunxi: add multi-cluster CPU PRCM register definition Icenowy Zheng
@ 2017-06-07 3:40 ` Chen-Yu Tsai
0 siblings, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:40 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> 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 <icenowy@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 */
The comment needs to be fixed. It only applies to the single cluster SoCs.
Otherwise,
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> + 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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
` (5 preceding siblings ...)
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 6/8] sunxi: add multi-cluster CPU PRCM register definition Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 4:53 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2017-06-07 6:48 ` [U-Boot] " Maxime Ripard
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC Icenowy Zheng
7 siblings, 2 replies; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
From: Chen-Yu Tsai <wens@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 <wens@csie.org>
[Icenowy: adapt for A83T]
Signed-off-by: Icenowy Zheng <icenowy@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 <wens@csie.org>
+ *
+ * Based on assembly code by Marc Zyngier <marc.zyngier@arm.com>,
+ * which was based on code by Carl van Schaik <carl@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs Icenowy Zheng
@ 2017-06-07 4:53 ` Chen-Yu Tsai
2017-06-07 6:48 ` [U-Boot] " Maxime Ripard
1 sibling, 0 replies; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 4:53 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
> [Icenowy: adapt for A83T]
> Signed-off-by: Icenowy Zheng <icenowy@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
>
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.
> 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 <wens@csie.org>
> + *
> + * Based on assembly code by Marc Zyngier <marc.zyngier@arm.com>,
> + * which was based on code by Carl van Schaik <carl@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
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
> +
> + /* 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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 47+ messages in thread* [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs Icenowy Zheng
2017-06-07 4:53 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2017-06-07 6:48 ` Maxime Ripard
2017-06-07 6:59 ` [U-Boot] [linux-sunxi] " Icenowy Zheng
1 sibling, 1 reply; 47+ messages in thread
From: Maxime Ripard @ 2017-06-07 6:48 UTC (permalink / raw)
To: u-boot
Hi,
On Wed, Jun 07, 2017 at 08:47:20AM +0800, Icenowy Zheng wrote:
> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
> [Icenowy: adapt for A83T]
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Ideally, Marc should be in Cc in order to review this.
> ---
> 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 <wens@csie.org>
> + *
> + * Based on assembly code by Marc Zyngier <marc.zyngier@arm.com>,
> + * which was based on code by Carl van Schaik <carl@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);
This doesn't compile.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170607/df040545/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] Re: [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs
2017-06-07 6:48 ` [U-Boot] " Maxime Ripard
@ 2017-06-07 6:59 ` Icenowy Zheng
2017-06-07 7:54 ` Marc Zyngier
0 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 6:59 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 下午2:48:55, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>Hi,
>
>On Wed, Jun 07, 2017 at 08:47:20AM +0800, Icenowy Zheng wrote:
>> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
>> [Icenowy: adapt for A83T]
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
>Ideally, Marc should be in Cc in order to review this.
Who?
>
>> ---
>> 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 <wens@csie.org>
>> + *
>> + * Based on assembly code by Marc Zyngier <marc.zyngier@arm.com>,
>> + * which was based on code by Carl van Schaik <carl@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);
>
>This doesn't compile.
>
>
>Maxime
^ permalink raw reply [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] Re: [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs
2017-06-07 6:59 ` [U-Boot] [linux-sunxi] " Icenowy Zheng
@ 2017-06-07 7:54 ` Marc Zyngier
0 siblings, 0 replies; 47+ messages in thread
From: Marc Zyngier @ 2017-06-07 7:54 UTC (permalink / raw)
To: u-boot
On 07/06/17 07:59, Icenowy Zheng wrote:
>
>
> 于 2017年6月7日 GMT+08:00 下午2:48:55, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>> Hi,
>>
>> On Wed, Jun 07, 2017 at 08:47:20AM +0800, Icenowy Zheng wrote:
>>> From: Chen-Yu Tsai <wens@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 <wens@csie.org>
>>> [Icenowy: adapt for A83T]
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>
>> Ideally, Marc should be in Cc in order to review this.
>
> Who?
Nobody.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 0:47 [U-Boot] [RFC PATCH 0/8] Allwinner A83T PSCI SMP support Icenowy Zheng
` (6 preceding siblings ...)
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 7/8] sunxi: Add basic PSCI implementation for multi-cluster SoCs Icenowy Zheng
@ 2017-06-07 0:47 ` Icenowy Zheng
2017-06-07 3:36 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
7 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 0:47 UTC (permalink / raw)
To: u-boot
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 <icenowy@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
^ permalink raw reply related [flat|nested] 47+ messages in thread* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 0:47 ` [U-Boot] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC Icenowy Zheng
@ 2017-06-07 3:36 ` Chen-Yu Tsai
2017-06-07 3:40 ` Icenowy Zheng
0 siblings, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:36 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> 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 <icenowy@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
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 3:36 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2017-06-07 3:40 ` Icenowy Zheng
2017-06-07 3:47 ` Chen-Yu Tsai
0 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 3:40 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> 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 <icenowy@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
>
>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.
>
>ChenYu
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 3:40 ` Icenowy Zheng
@ 2017-06-07 3:47 ` Chen-Yu Tsai
2017-06-07 6:50 ` Maxime Ripard
0 siblings, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 3:47 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> 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 <icenowy@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
>>
>>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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 3:47 ` Chen-Yu Tsai
@ 2017-06-07 6:50 ` Maxime Ripard
2017-06-07 6:58 ` Icenowy Zheng
2017-06-07 7:00 ` Chen-Yu Tsai
0 siblings, 2 replies; 47+ messages in thread
From: Maxime Ripard @ 2017-06-07 6:50 UTC (permalink / raw)
To: u-boot
On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> >
> >
> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> >>> 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 <icenowy@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
> >>
> >>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170607/df611681/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 6:50 ` Maxime Ripard
@ 2017-06-07 6:58 ` Icenowy Zheng
2017-06-07 7:00 ` Chen-Yu Tsai
1 sibling, 0 replies; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 6:58 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 下午2:50:36, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>> >
>> >
>> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>> >>> 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 <icenowy@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
>> >>
>> >>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 ?
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.
>
>Maxime
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 6:50 ` Maxime Ripard
2017-06-07 6:58 ` Icenowy Zheng
@ 2017-06-07 7:00 ` Chen-Yu Tsai
2017-06-07 12:11 ` Marc Zyngier
1 sibling, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-07 7:00 UTC (permalink / raw)
To: u-boot
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> >
>> >
>> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> >>> 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 <icenowy@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
>> >>
>> >>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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 7:00 ` Chen-Yu Tsai
@ 2017-06-07 12:11 ` Marc Zyngier
2017-06-07 12:12 ` Icenowy Zheng
0 siblings, 1 reply; 47+ messages in thread
From: Marc Zyngier @ 2017-06-07 12:11 UTC (permalink / raw)
To: u-boot
On 07/06/17 08:00, Chen-Yu Tsai wrote:
> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>>
>>>>
>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>>>>> 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 <icenowy@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
>>>>>
>>>>> 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...
>> 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?
> 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...
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 12:11 ` Marc Zyngier
@ 2017-06-07 12:12 ` Icenowy Zheng
2017-06-07 12:51 ` Marc Zyngier
0 siblings, 1 reply; 47+ messages in thread
From: Icenowy Zheng @ 2017-06-07 12:12 UTC (permalink / raw)
To: u-boot
于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyngier@arm.com> 写到:
>On 07/06/17 08:00, Chen-Yu Tsai wrote:
>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>>>
>>>>>
>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>>>>> 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 <icenowy@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
>>>>>>
>>>>>> 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...
>
>>> 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?
Write Secure Boot eFUSE, which will break *all* existing softwares.
>
>> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 12:12 ` Icenowy Zheng
@ 2017-06-07 12:51 ` Marc Zyngier
2017-06-07 13:04 ` Maxime Ripard
2017-06-23 13:24 ` icenowy at aosc.io
0 siblings, 2 replies; 47+ messages in thread
From: Marc Zyngier @ 2017-06-07 12:51 UTC (permalink / raw)
To: u-boot
On 07/06/17 13:12, Icenowy Zheng wrote:
>
>
> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyngier@arm.com> 写到:
>> On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>> <maxime.ripard@free-electrons.com> wrote:
>>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>> wrote:
>>>>>>
>>>>>>
>>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>> wrote:
>>>>>>>> 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 <icenowy@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
>>>>>>>
>>>>>>> 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...
>>
>>>> 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?
>
> 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...
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 12:51 ` Marc Zyngier
@ 2017-06-07 13:04 ` Maxime Ripard
2017-06-07 14:06 ` Marc Zyngier
2017-06-23 13:24 ` icenowy at aosc.io
1 sibling, 1 reply; 47+ messages in thread
From: Maxime Ripard @ 2017-06-07 13:04 UTC (permalink / raw)
To: u-boot
On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote:
> On 07/06/17 13:12, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyngier@arm.com> 写到:
> >> On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>> <maxime.ripard@free-electrons.com> wrote:
> >>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> >>>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
> >> wrote:
> >>>>>>
> >>>>>>
> >>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
> >>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
> >> wrote:
> >>>>>>>> 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 <icenowy@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
> >>>>>>>
> >>>>>>> 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...
> >>
> >>>> 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?
> >
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170607/491f81a3/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 13:04 ` Maxime Ripard
@ 2017-06-07 14:06 ` Marc Zyngier
2017-07-02 14:17 ` Maxime Ripard
0 siblings, 1 reply; 47+ messages in thread
From: Marc Zyngier @ 2017-06-07 14:06 UTC (permalink / raw)
To: u-boot
On 07/06/17 14:04, Maxime Ripard wrote:
> On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote:
>> On 07/06/17 13:12, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyngier@arm.com> 写到:
>>>> On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>>>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>>>> <maxime.ripard@free-electrons.com> wrote:
>>>>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>>>>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org> 写到:
>>>>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>>>> wrote:
>>>>>>>>>> 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 <icenowy@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
>>>>>>>>>
>>>>>>>>> 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...
>>>>
>>>>>> 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?
>>>
>>> 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).
> 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...
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 14:06 ` Marc Zyngier
@ 2017-07-02 14:17 ` Maxime Ripard
2017-07-02 15:40 ` André Przywara
0 siblings, 1 reply; 47+ messages in thread
From: Maxime Ripard @ 2017-07-02 14:17 UTC (permalink / raw)
To: u-boot
On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170702/1244f509/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 14:17 ` Maxime Ripard
@ 2017-07-02 15:40 ` André Przywara
2017-07-03 8:21 ` Maxime Ripard
0 siblings, 1 reply; 47+ messages in thread
From: André Przywara @ 2017-07-02 15:40 UTC (permalink / raw)
To: u-boot
On 02/07/17 15:17, Maxime Ripard wrote:
Hi,
> On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
>>> 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
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)
>
> 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
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 15:40 ` André Przywara
@ 2017-07-03 8:21 ` Maxime Ripard
0 siblings, 0 replies; 47+ messages in thread
From: Maxime Ripard @ 2017-07-03 8:21 UTC (permalink / raw)
To: u-boot
Hi,
On Sun, Jul 02, 2017 at 04:40:20PM +0100, André Przywara wrote:
> On 02/07/17 15:17, Maxime Ripard wrote:
> > On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> >>> 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
>
> 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.
> 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.
> 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"
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170703/f2fd6daf/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-07 12:51 ` Marc Zyngier
2017-06-07 13:04 ` Maxime Ripard
@ 2017-06-23 13:24 ` icenowy at aosc.io
2017-06-23 13:35 ` Maxime Ripard
1 sibling, 1 reply; 47+ messages in thread
From: icenowy at aosc.io @ 2017-06-23 13:24 UTC (permalink / raw)
To: u-boot
在 2017-06-07 20:51，Marc Zyngier 写道：
> On 07/06/17 13:12, Icenowy Zheng wrote:
>>
>>
>> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyngier@arm.com>
>> 写到:
>>> On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>>> <maxime.ripard@free-electrons.com> wrote:
>>>>> On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>>>>> On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens@csie.org>
>>>>>>> 写到:
>>>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>>> wrote:
>>>>>>>>> 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 <icenowy@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
>>>>>>>>
>>>>>>>> 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...
>>>
>>>>> 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?
>>
>> 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?
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-23 13:24 ` icenowy at aosc.io
@ 2017-06-23 13:35 ` Maxime Ripard
2017-06-23 13:39 ` icenowy at aosc.io
0 siblings, 1 reply; 47+ messages in thread
From: Maxime Ripard @ 2017-06-23 13:35 UTC (permalink / raw)
To: u-boot
On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
> 在 2017-06-07 20:51，Marc Zyngier 写道：
> > On 07/06/17 13:12, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> > > <marc.zyngier@arm.com> 写到:
> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> > > > > <maxime.ripard@free-electrons.com> wrote:
> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
> > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> > > > > > > > Tsai <wens@csie.org> 写到:
> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
> > > > wrote:
> > > > > > > > > > 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 <icenowy@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
> > > > > > > > >
> > > > > > > > > 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...
> > > >
> > > > > > 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?
> > >
> > > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170623/2d4d1521/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-23 13:35 ` Maxime Ripard
@ 2017-06-23 13:39 ` icenowy at aosc.io
2017-06-23 13:50 ` Chen-Yu Tsai
0 siblings, 1 reply; 47+ messages in thread
From: icenowy at aosc.io @ 2017-06-23 13:39 UTC (permalink / raw)
To: u-boot
在 2017-06-23 21:35，Maxime Ripard 写道：
> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
>> 在 2017-06-07 20:51，Marc Zyngier 写道：
>> > On 07/06/17 13:12, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
>> > > <marc.zyngier@arm.com> 写到:
>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>> > > > > <maxime.ripard@free-electrons.com> wrote:
>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng <icenowy@aosc.io>
>> > > > wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>> > > > > > > > Tsai <wens@csie.org> 写到:
>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy@aosc.io>
>> > > > wrote:
>> > > > > > > > > > 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 <icenowy@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
>> > > > > > > > >
>> > > > > > > > > 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...
>> > > >
>> > > > > > 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?
>> > >
>> > > 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.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-23 13:39 ` icenowy at aosc.io
@ 2017-06-23 13:50 ` Chen-Yu Tsai
2017-07-02 7:08 ` icenowy at aosc.io
0 siblings, 1 reply; 47+ messages in thread
From: Chen-Yu Tsai @ 2017-06-23 13:50 UTC (permalink / raw)
To: u-boot
On Fri, Jun 23, 2017 at 9:39 PM, <icenowy@aosc.io> wrote:
> 在 2017-06-23 21:35，Maxime Ripard 写道：
>>
>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
>>>
>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
>>> > >
>>> > >
>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
>>> > > <marc.zyngier@arm.com> 写到:
>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>> > > > > <maxime.ripard@free-electrons.com> wrote:
>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
>>> > > > > > > <icenowy@aosc.io>
>>> > > > wrote:
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>>> > > > > > > > Tsai <wens@csie.org> 写到:
>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>>> > > > > > > > > <icenowy@aosc.io>
>>> > > > wrote:
>>> > > > > > > > > > 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 <icenowy@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
>>> > > > > > > > >
>>> > > > > > > > > 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...
>>> > > >
>>> > > > > > 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?
>>> > >
>>> > > 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-06-23 13:50 ` Chen-Yu Tsai
@ 2017-07-02 7:08 ` icenowy at aosc.io
2017-07-02 11:22 ` Marc Zyngier
0 siblings, 1 reply; 47+ messages in thread
From: icenowy at aosc.io @ 2017-07-02 7:08 UTC (permalink / raw)
To: u-boot
在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> On Fri, Jun 23, 2017 at 9:39 PM, <icenowy@aosc.io> wrote:
>> 在 2017-06-23 21:35，Maxime Ripard 写道：
>>>
>>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
>>>>
>>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
>>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
>>>> > >
>>>> > >
>>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
>>>> > > <marc.zyngier@arm.com> 写到:
>>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>>> > > > > <maxime.ripard@free-electrons.com> wrote:
>>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
>>>> > > > > > > <icenowy@aosc.io>
>>>> > > > wrote:
>>>> > > > > > > >
>>>> > > > > > > >
>>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>>>> > > > > > > > Tsai <wens@csie.org> 写到:
>>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>>>> > > > > > > > > <icenowy@aosc.io>
>>>> > > > wrote:
>>>> > > > > > > > > > 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 <icenowy@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
>>>> > > > > > > > >
>>>> > > > > > > > > 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...
>>>> > > >
>>>> > > > > > 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?
>>>> > >
>>>> > > 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.
>
> ChenYu
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 7:08 ` icenowy at aosc.io
@ 2017-07-02 11:22 ` Marc Zyngier
2017-07-02 12:36 ` icenowy at aosc.io
0 siblings, 1 reply; 47+ messages in thread
From: Marc Zyngier @ 2017-07-02 11:22 UTC (permalink / raw)
To: u-boot
On Sun, 2 Jul 2017 15:08:12 +0800
<icenowy@aosc.io> wrote:
> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> > On Fri, Jun 23, 2017 at 9:39 PM, <icenowy@aosc.io> wrote:
> >> 在 2017-06-23 21:35，Maxime Ripard 写道：
> >>>
> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
> >>>>
> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
> >>>> > >
> >>>> > >
> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> >>>> > > <marc.zyngier@arm.com> 写到:
> >>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>>> > > > > <maxime.ripard@free-electrons.com> wrote:
> >>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> >>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
> >>>> > > > > > > <icenowy@aosc.io>
> >>>> > > > wrote:
> >>>> > > > > > > >
> >>>> > > > > > > >
> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> >>>> > > > > > > > Tsai <wens@csie.org> 写到:
> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> >>>> > > > > > > > > <icenowy@aosc.io>
> >>>> > > > wrote:
> >>>> > > > > > > > > > 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 <icenowy@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
> >>>> > > > > > > > >
> >>>> > > > > > > > > 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...
> >>>> > > >
> >>>> > > > > > 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?
> >>>> > >
> >>>> > > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 11:22 ` Marc Zyngier
@ 2017-07-02 12:36 ` icenowy at aosc.io
2017-07-02 15:27 ` Marc Zyngier
0 siblings, 1 reply; 47+ messages in thread
From: icenowy at aosc.io @ 2017-07-02 12:36 UTC (permalink / raw)
To: u-boot
在 2017-07-02 19:22，Marc Zyngier 写道：
> On Sun, 2 Jul 2017 15:08:12 +0800
> <icenowy@aosc.io> wrote:
>
>> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
>> > On Fri, Jun 23, 2017 at 9:39 PM, <icenowy@aosc.io> wrote:
>> >> 在 2017-06-23 21:35，Maxime Ripard 写道：
>> >>>
>> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
>> >>>>
>> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
>> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
>> >>>> > >
>> >>>> > >
>> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
>> >>>> > > <marc.zyngier@arm.com> 写到:
>> >>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
>> >>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>> >>>> > > > > <maxime.ripard@free-electrons.com> wrote:
>> >>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
>> >>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
>> >>>> > > > > > > <icenowy@aosc.io>
>> >>>> > > > wrote:
>> >>>> > > > > > > >
>> >>>> > > > > > > >
>> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>> >>>> > > > > > > > Tsai <wens@csie.org> 写到:
>> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>> >>>> > > > > > > > > <icenowy@aosc.io>
>> >>>> > > > wrote:
>> >>>> > > > > > > > > > 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 <icenowy@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
>> >>>> > > > > > > > >
>> >>>> > > > > > > > > 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...
>> >>>> > > >
>> >>>> > > > > > 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?
>> >>>> > >
>> >>>> > > 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?
>
> Thanks,
>
> M.
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 12:36 ` icenowy at aosc.io
@ 2017-07-02 15:27 ` Marc Zyngier
2017-07-03 20:37 ` Maxime Ripard
0 siblings, 1 reply; 47+ messages in thread
From: Marc Zyngier @ 2017-07-02 15:27 UTC (permalink / raw)
To: u-boot
On Sun, 2 Jul 2017 20:36:04 +0800
<icenowy@aosc.io> wrote:
> 在 2017-07-02 19:22，Marc Zyngier 写道：
> > On Sun, 2 Jul 2017 15:08:12 +0800
> > <icenowy@aosc.io> wrote:
> >
> >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> >> > On Fri, Jun 23, 2017 at 9:39 PM, <icenowy@aosc.io> wrote:
> >> >> 在 2017-06-23 21:35，Maxime Ripard 写道：
> >> >>>
> >> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote:
> >> >>>>
> >> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道：
> >> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote:
> >> >>>> > >
> >> >>>> > >
> >> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier
> >> >>>> > > <marc.zyngier@arm.com> 写到:
> >> >>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >> >>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >> >>>> > > > > <maxime.ripard@free-electrons.com> wrote:
> >> >>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote:
> >> >>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng
> >> >>>> > > > > > > <icenowy@aosc.io>
> >> >>>> > > > wrote:
> >> >>>> > > > > > > >
> >> >>>> > > > > > > >
> >> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> >> >>>> > > > > > > > Tsai <wens@csie.org> 写到:
> >> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> >> >>>> > > > > > > > > <icenowy@aosc.io>
> >> >>>> > > > wrote:
> >> >>>> > > > > > > > > > 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 <icenowy@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
> >> >>>> > > > > > > > >
> >> >>>> > > > > > > > > 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...
> >> >>>> > > >
> >> >>>> > > > > > 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?
> >> >>>> > >
> >> >>>> > > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
2017-07-02 15:27 ` Marc Zyngier
@ 2017-07-03 20:37 ` Maxime Ripard
0 siblings, 0 replies; 47+ messages in thread
From: Maxime Ripard @ 2017-07-03 20:37 UTC (permalink / raw)
To: u-boot
On Sun, Jul 02, 2017 at 04:27:52PM +0100, Marc Zyngier wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170703/129214a5/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread