[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Alison Wang]

The ARMv8 architecture supports:
1. 64-bit execution state, AArch64.
2. 32-bit execution state, AArch32, that is compatible with previous
versions of the ARM architecture.

LayerScape platforms are compliant with ARMv8 architecture. This patch
is to support running 32-bit Linux kernel for LayerScape platforms.

Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.

Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
Signed-off-by: Alison Wang <alison.wang@nxp.com>
---
 arch/arm/Kconfig                    |  9 +++++++++
 arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
 arch/arm/mach-imx/Makefile          |  4 +++-
 arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
 4 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/mach-layerscape.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f0c8068..e8d470e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -294,6 +294,15 @@ config PGTABLE_LEVELS
 	default 3 if ARM_LPAE
 	default 2
 
+config ARCH_AARCH32_ES_SUPPORT
+	def_bool n
+	help
+	 The ARMv8 architecture supports 64-bit execution state, AArch64
+	 and 32-bit execution state, AArch32, that is compatible with
+	 previous versions of the ARM architecture.
+
+	 Enable AArch32 execution state support for ARMv8 architecture.
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 0ac05a0..fda4f5f 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -549,6 +549,20 @@ config SOC_LS1021A
 	help
 	  This enables support for Freescale LS1021A processor.
 
+config ARCH_LAYERSCAPE_AARCH32
+	bool "Freescale Layerscape SoC AArch32 ES support"
+	select ARCH_AARCH32_ES_SUPPORT
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_ARCH_TIMER
+	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+	select PCI_LAYERSCAPE if PCI
+	select PCI_DOMAINS if PCI
+
+	help
+	  This enables support for Freescale Layerscape SoC family in
+	  in AArch32 execution state.
+
 endif
 
 comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 737450f..7ded4fa 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -69,7 +69,7 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
 obj-$(CONFIG_HAVE_IMX_SRC) += src.o
-ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
+ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A)$(CONFIG_ARCH_LAYERSCAPE_AARCH32),)
 AFLAGS_headsmp.o :=-Wa,-march=armv7-a
 obj-$(CONFIG_SMP) += headsmp.o platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
@@ -96,4 +96,6 @@ obj-$(CONFIG_SOC_VF610) += mach-vf610.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
 
+obj-$(CONFIG_ARCH_LAYERSCAPE_AARCH32) += mach-layerscape.o
+
 obj-y += devices/
diff --git a/arch/arm/mach-imx/mach-layerscape.c b/arch/arm/mach-imx/mach-layerscape.c
new file mode 100644
index 0000000..acfb2a2
--- /dev/null
+++ b/arch/arm/mach-imx/mach-layerscape.c
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+
+static const char * const layerscape_dt_compat[] __initconst = {
+	"fsl,ls1012a",
+	"fsl,ls1043a",
+	"fsl,ls1046a",
+	NULL,
+};
+
+DT_MACHINE_START(LAYERSCAPE_AARCH32, "Freescale LAYERSCAPE")
+	.dt_compat	= layerscape_dt_compat,
+MACHINE_END
-- 
2.1.0.27.g96db324

[PATCH 2/2] armv8: aarch32: Add SMP support for 32-bit Linux kernel

[Alison Wang]

The patch adds SMP support for running 32-bit Linux kernel for
Layerscape platforms. Spin-table method is used for SMP support.

Signed-off-by: Alison Wang <alison.wang@nxp.com>
Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
---
 arch/arm/mach-imx/common.h          |  1 +
 arch/arm/mach-imx/mach-layerscape.c |  1 +
 arch/arm/mach-imx/platsmp.c         | 49 +++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c4436d9..6362790 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -152,5 +152,6 @@ static inline void imx_init_l2cache(void) {}
 
 extern const struct smp_operations imx_smp_ops;
 extern const struct smp_operations ls1021a_smp_ops;
+extern const struct smp_operations layerscape_smp_ops;
 
 #endif
diff --git a/arch/arm/mach-imx/mach-layerscape.c b/arch/arm/mach-imx/mach-layerscape.c
index acfb2a2..109d488 100644
--- a/arch/arm/mach-imx/mach-layerscape.c
+++ b/arch/arm/mach-imx/mach-layerscape.c
@@ -19,5 +19,6 @@ static const char * const layerscape_dt_compat[] __initconst = {
 };
 
 DT_MACHINE_START(LAYERSCAPE_AARCH32, "Freescale LAYERSCAPE")
+	.smp		= smp_ops(layerscape_smp_ops),
 	.dt_compat	= layerscape_dt_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 711dbbd..e2fc7a2 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -14,6 +14,7 @@
 #include <linux/of_address.h>
 #include <linux/of.h>
 #include <linux/smp.h>
+#include <linux/types.h>
 
 #include <asm/cacheflush.h>
 #include <asm/page.h>
@@ -26,6 +27,8 @@
 u32 g_diag_reg;
 static void __iomem *scu_base;
 
+static u64 cpu_release_addr[NR_CPUS];
+
 static struct map_desc scu_io_desc __initdata = {
 	/* .virtual and .pfn are run-time assigned */
 	.length		= SZ_4K,
@@ -127,3 +130,49 @@ const struct smp_operations ls1021a_smp_ops __initconst = {
 	.smp_prepare_cpus	= ls1021a_smp_prepare_cpus,
 	.smp_boot_secondary	= ls1021a_boot_secondary,
 };
+
+static int layerscape_smp_boot_secondary(unsigned int cpu,
+					 struct task_struct *idle)
+{
+	u32 secondary_startup_phys;
+	__le32 __iomem *release_addr;
+
+	secondary_startup_phys = virt_to_phys(secondary_startup);
+
+	release_addr = memremap((u32)cpu_release_addr[cpu], sizeof(u64),
+				MEMREMAP_WB);
+	if (!release_addr)
+		return -ENOMEM;
+
+	writel_relaxed(secondary_startup_phys, release_addr);
+	writel_relaxed(0, release_addr + 1);
+	__cpuc_flush_dcache_area((__force void *)release_addr,
+				 sizeof(u64));
+
+	sev();
+
+	iounmap(release_addr);
+
+	return 0;
+}
+
+static void layerscape_smp_init_cpus(void)
+{
+	struct device_node *dnt = NULL;
+	unsigned int cpu = 0;
+
+	while ((dnt = of_find_node_by_type(dnt, "cpu"))) {
+		if (of_property_read_u64(dnt, "cpu-release-addr",
+		    &cpu_release_addr[cpu])) {
+			pr_err("CPU %d: missing or invalid cpu-release-addr property\n",
+			cpu);
+		}
+
+		cpu++;
+	}
+}
+
+const struct smp_operations layerscape_smp_ops __initconst = {
+	.smp_init_cpus		= layerscape_smp_init_cpus,
+	.smp_boot_secondary	= layerscape_smp_boot_secondary,
+};
-- 
2.1.0.27.g96db324

[PATCH 2/2] armv8: aarch32: Add SMP support for 32-bit Linux kernel

[Arnd Bergmann]

On Friday, September 23, 2016 10:19:06 AM CEST Alison Wang wrote:
> The patch adds SMP support for running 32-bit Linux kernel for
> Layerscape platforms. Spin-table method is used for SMP support.
> 
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
> ---
>  arch/arm/mach-imx/common.h          |  1 +
>  arch/arm/mach-imx/mach-layerscape.c |  1 +
>  arch/arm/mach-imx/platsmp.c         | 49 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 51 insertions(+)
> 

This really shouldn't be needed: if it works on a 64-bit kernel
without platform specific SMP operations, why do you need it on 32-bit
kernels?

	Arnd

[PATCH 2/2] armv8: aarch32: Add SMP support for 32-bit Linux kernel

[Mark Rutland]

On Fri, Sep 23, 2016 at 10:19:06AM +0800, Alison Wang wrote:
> The patch adds SMP support for running 32-bit Linux kernel for
> Layerscape platforms. Spin-table method is used for SMP support.

So far, spin-table has not been defined for 32-bit, and the code below,
while mostly a copy of the 64-bit code, is somewhat different.

If you want a common enable method, I would strongly advise that you use
PSCI, which is well-defined for both 32-bit and 64-bit. There are a
number of problems with spin-table, and I would not recommend extending
it to 32-bit ARM.

Thanks,
Mark.

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Arnd Bergmann]

On Friday, September 23, 2016 10:19:05 AM CEST Alison Wang wrote:
> The ARMv8 architecture supports:
> 1. 64-bit execution state, AArch64.
> 2. 32-bit execution state, AArch32, that is compatible with previous
> versions of the ARM architecture.
> 
> LayerScape platforms are compliant with ARMv8 architecture. This patch
> is to support running 32-bit Linux kernel for LayerScape platforms.
> 
> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> 
> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>

I'm not too happy about adding random 64-bit platforms in arch/arm/.
We have done this twice already (ARCH_VIRT and ARCH_BCM2835), which
are both platforms that can come with ARMv6, ARMv7 or ARMv8 cores
and are otherwise almost identical. However, there are two problem
I see with the general approach:

a) We don't actually support ARMv8 as a target architecture, in fact
   we don't even support ARMv7VE (Cortex-A7/A12/A15/A17, Krait-400,
   PJ4B-MP and Brahma-B15) properly. For an ARMv8-only kernel
   we should pass the correct compiler flags. We should also have
   this for any upcoming Cortex-A32 and Cortex-R52 platforms.

b) Generally speaking it's a bad idea to run an platform that
   supports aarch64 in aarch32 mode, you should use a native kernel
   with syscall emulation for 32-bit user space unless you have a
   very strong reason not to do that. If you have a strong reason
   why your platform is different from all the others, please at
   least explain it in the changelog.
   On the other hand, any platform support both aarch64 and aarch32
   mode should in theory run with a 32-bit kernel, and it might be
   nice to allow that for *all* platforms that we support on a 64-bit
   kernel. If we decide to do this, we should come up with a way to
   include the platform configuration from arch/arm64 in the arm
   Kconfig file.

	Arnd

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Robin Murphy]

Hi Alison,

On 23/09/16 03:19, Alison Wang wrote:
> The ARMv8 architecture supports:
> 1. 64-bit execution state, AArch64.
> 2. 32-bit execution state, AArch32, that is compatible with previous
> versions of the ARM architecture.
> 
> LayerScape platforms are compliant with ARMv8 architecture. This patch
> is to support running 32-bit Linux kernel for LayerScape platforms.
> 
> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> 
> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> ---
>  arch/arm/Kconfig                    |  9 +++++++++
>  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
>  arch/arm/mach-imx/Makefile          |  4 +++-
>  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>  4 files changed, 49 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f0c8068..e8d470e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>  	default 3 if ARM_LPAE
>  	default 2
>  
> +config ARCH_AARCH32_ES_SUPPORT
> +	def_bool n
> +	help
> +	 The ARMv8 architecture supports 64-bit execution state, AArch64
> +	 and 32-bit execution state, AArch32, that is compatible with
> +	 previous versions of the ARM architecture.
> +
> +	 Enable AArch32 execution state support for ARMv8 architecture.

What's this supposed to do, exactly? I've been running 32-bit kernels on
my Juno with very little issue (beyond a couple of DT tweaks, and some
firmware hacks with a corresponding bit of A64 assembly tacked on the
front of the zImage to switch into AArch32 state).

Robin.

> +
>  source "init/Kconfig"
>  
>  source "kernel/Kconfig.freezer"
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0ac05a0..fda4f5f 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -549,6 +549,20 @@ config SOC_LS1021A
>  	help
>  	  This enables support for Freescale LS1021A processor.
>  
> +config ARCH_LAYERSCAPE_AARCH32
> +	bool "Freescale Layerscape SoC AArch32 ES support"
> +	select ARCH_AARCH32_ES_SUPPORT
> +	select ARM_AMBA
> +	select ARM_GIC
> +	select ARM_ARCH_TIMER
> +	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
> +	select PCI_LAYERSCAPE if PCI
> +	select PCI_DOMAINS if PCI
> +
> +	help
> +	  This enables support for Freescale Layerscape SoC family in
> +	  in AArch32 execution state.
> +
>  endif
>  
>  comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 737450f..7ded4fa 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -69,7 +69,7 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
>  obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
>  obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
>  obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> -ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
> +ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A)$(CONFIG_ARCH_LAYERSCAPE_AARCH32),)
>  AFLAGS_headsmp.o :=-Wa,-march=armv7-a
>  obj-$(CONFIG_SMP) += headsmp.o platsmp.o
>  obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> @@ -96,4 +96,6 @@ obj-$(CONFIG_SOC_VF610) += mach-vf610.o
>  
>  obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
>  
> +obj-$(CONFIG_ARCH_LAYERSCAPE_AARCH32) += mach-layerscape.o
> +
>  obj-y += devices/
> diff --git a/arch/arm/mach-imx/mach-layerscape.c b/arch/arm/mach-imx/mach-layerscape.c
> new file mode 100644
> index 0000000..acfb2a2
> --- /dev/null
> +++ b/arch/arm/mach-imx/mach-layerscape.c
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <asm/mach/arch.h>
> +
> +#include "common.h"
> +
> +static const char * const layerscape_dt_compat[] __initconst = {
> +	"fsl,ls1012a",
> +	"fsl,ls1043a",
> +	"fsl,ls1046a",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(LAYERSCAPE_AARCH32, "Freescale LAYERSCAPE")
> +	.dt_compat	= layerscape_dt_compat,
> +MACHINE_END
> 

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Stuart Yoder]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 7:17 AM
> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
> 
> Hi Alison,
> 
> On 23/09/16 03:19, Alison Wang wrote:
> > The ARMv8 architecture supports:
> > 1. 64-bit execution state, AArch64.
> > 2. 32-bit execution state, AArch32, that is compatible with previous
> > versions of the ARM architecture.
> >
> > LayerScape platforms are compliant with ARMv8 architecture. This patch
> > is to support running 32-bit Linux kernel for LayerScape platforms.
> >
> > Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> >
> > Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> > Signed-off-by: Alison Wang <alison.wang@nxp.com>
> > ---
> >  arch/arm/Kconfig                    |  9 +++++++++
> >  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
> >  arch/arm/mach-imx/Makefile          |  4 +++-
> >  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> >  4 files changed, 49 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f0c8068..e8d470e 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> >  	default 3 if ARM_LPAE
> >  	default 2
> >
> > +config ARCH_AARCH32_ES_SUPPORT
> > +	def_bool n
> > +	help
> > +	 The ARMv8 architecture supports 64-bit execution state, AArch64
> > +	 and 32-bit execution state, AArch32, that is compatible with
> > +	 previous versions of the ARM architecture.
> > +
> > +	 Enable AArch32 execution state support for ARMv8 architecture.
> 
> What's this supposed to do, exactly? I've been running 32-bit kernels on
> my Juno with very little issue (beyond a couple of DT tweaks, and some
> firmware hacks with a corresponding bit of A64 assembly tacked on the
> front of the zImage to switch into AArch32 state).

Which arch/arm/mach-* platform are you using for Juno?

Thanks,
Stuart

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Robin Murphy]

On 23/09/16 14:13, Stuart Yoder wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 7:17 AM
>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>> <leoyang.li@nxp.com>
>> Cc: Jason Jin <jason.jin@nxp.com>
>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>
>> Hi Alison,
>>
>> On 23/09/16 03:19, Alison Wang wrote:
>>> The ARMv8 architecture supports:
>>> 1. 64-bit execution state, AArch64.
>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>> versions of the ARM architecture.
>>>
>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>
>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>
>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>> ---
>>>  arch/arm/Kconfig                    |  9 +++++++++
>>>  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
>>>  arch/arm/mach-imx/Makefile          |  4 +++-
>>>  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>>  4 files changed, 49 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index f0c8068..e8d470e 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>>  	default 3 if ARM_LPAE
>>>  	default 2
>>>
>>> +config ARCH_AARCH32_ES_SUPPORT
>>> +	def_bool n
>>> +	help
>>> +	 The ARMv8 architecture supports 64-bit execution state, AArch64
>>> +	 and 32-bit execution state, AArch32, that is compatible with
>>> +	 previous versions of the ARM architecture.
>>> +
>>> +	 Enable AArch32 execution state support for ARMv8 architecture.
>>
>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>> front of the zImage to switch into AArch32 state).
> 
> Which arch/arm/mach-* platform are you using for Juno?

I don't even know! :) I just start with a multi_v7_defconfig plus a few
extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
combination of mach-vexpress and mach-virt.

Robin.

> 
> Thanks,
> Stuart
> 

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Rob Herring]

On Fri, Sep 23, 2016 at 8:18 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 23/09/16 14:13, Stuart Yoder wrote:
>>
>>
>>> -----Original Message-----
>>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>>> Sent: Friday, September 23, 2016 7:17 AM
>>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>>> <leoyang.li@nxp.com>
>>> Cc: Jason Jin <jason.jin@nxp.com>
>>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>>
>>> Hi Alison,
>>>
>>> On 23/09/16 03:19, Alison Wang wrote:
>>>> The ARMv8 architecture supports:
>>>> 1. 64-bit execution state, AArch64.
>>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>>> versions of the ARM architecture.
>>>>
>>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>>
>>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>>
>>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>>> ---
>>>>  arch/arm/Kconfig                    |  9 +++++++++
>>>>  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
>>>>  arch/arm/mach-imx/Makefile          |  4 +++-
>>>>  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>>>  4 files changed, 49 insertions(+), 1 deletion(-)
>>>>  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>>
>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>> index f0c8068..e8d470e 100644
>>>> --- a/arch/arm/Kconfig
>>>> +++ b/arch/arm/Kconfig
>>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>>>     default 3 if ARM_LPAE
>>>>     default 2
>>>>
>>>> +config ARCH_AARCH32_ES_SUPPORT
>>>> +   def_bool n
>>>> +   help
>>>> +    The ARMv8 architecture supports 64-bit execution state, AArch64
>>>> +    and 32-bit execution state, AArch32, that is compatible with
>>>> +    previous versions of the ARM architecture.
>>>> +
>>>> +    Enable AArch32 execution state support for ARMv8 architecture.
>>>
>>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>>> front of the zImage to switch into AArch32 state).
>>
>> Which arch/arm/mach-* platform are you using for Juno?
>
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.

I believe the answer is none. Enabling VExpress may enable other
drivers, but obviously none of the code in mach-vexpress is needed
since it is not used for 64-bit builds.

Rob

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Sudeep Holla]

On 23/09/16 14:18, Robin Murphy wrote:
> On 23/09/16 14:13, Stuart Yoder wrote:
>>
>>

[...]

>>
>> Which arch/arm/mach-* platform are you using for Juno?
>
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.
>

It should be matching "arm,vexpress" and just using mach-vexpress/v2m.c
as it's present as compatible in Juno DT but nothing else there.

mach-virt was deleted and we just have "Generic DT based system" in
arch/arm/kernel/devtree.c which IIUC doesn't require any compatible in
the DT. So dropping "arm,vexpress" will make it use "Generic DT based
system" I believe.

-- 
Regards,
Sudeep

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Stuart Yoder]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 8:19 AM
> To: Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang <b18965@freescale.com>; shawnguo at kernel.org;
> kernel at pengutronix.de; Fabio Estevam Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
> 
> On 23/09/16 14:13, Stuart Yoder wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy at arm.com]
> >> Sent: Friday, September 23, 2016 7:17 AM
> >> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> >> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
> >> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> >> <leoyang.li@nxp.com>
> >> Cc: Jason Jin <jason.jin@nxp.com>
> >> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
> >>
> >> Hi Alison,
> >>
> >> On 23/09/16 03:19, Alison Wang wrote:
> >>> The ARMv8 architecture supports:
> >>> 1. 64-bit execution state, AArch64.
> >>> 2. 32-bit execution state, AArch32, that is compatible with previous
> >>> versions of the ARM architecture.
> >>>
> >>> LayerScape platforms are compliant with ARMv8 architecture. This patch
> >>> is to support running 32-bit Linux kernel for LayerScape platforms.
> >>>
> >>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> >>>
> >>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> >>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> >>> ---
> >>>  arch/arm/Kconfig                    |  9 +++++++++
> >>>  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
> >>>  arch/arm/mach-imx/Makefile          |  4 +++-
> >>>  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> >>>  4 files changed, 49 insertions(+), 1 deletion(-)
> >>>  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> >>>
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index f0c8068..e8d470e 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> >>>  	default 3 if ARM_LPAE
> >>>  	default 2
> >>>
> >>> +config ARCH_AARCH32_ES_SUPPORT
> >>> +	def_bool n
> >>> +	help
> >>> +	 The ARMv8 architecture supports 64-bit execution state, AArch64
> >>> +	 and 32-bit execution state, AArch32, that is compatible with
> >>> +	 previous versions of the ARM architecture.
> >>> +
> >>> +	 Enable AArch32 execution state support for ARMv8 architecture.
> >>
> >> What's this supposed to do, exactly? I've been running 32-bit kernels on
> >> my Juno with very little issue (beyond a couple of DT tweaks, and some
> >> firmware hacks with a corresponding bit of A64 assembly tacked on the
> >> front of the zImage to switch into AArch32 state).
> >
> > Which arch/arm/mach-* platform are you using for Juno?
> 
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.

Thanks.  A question about the switch into aarch32 state... our assumption
was that the kernel starts at EL2.  In this proof of concept we're doing the
switch to aarch32/EL2 in firmware.  And what I'm being told is that the
firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some 
assistance from EL3 firmware.  This is leading us to invent a new
SMC call to do this.

Did you face this?

If there is such a requirement, it's something begging for standardization.
Doesn't make sense for multiple divergent approaches for switching from
aarch64/EL2 to aarch32/EL2.

Thanks,
Stuart

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Robin Murphy]

On 23/09/16 15:01, Stuart Yoder wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 8:19 AM
>> To: Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang <b18965@freescale.com>; shawnguo at kernel.org;
>> kernel at pengutronix.de; Fabio Estevam Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-
>> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Leo Li
>> <leoyang.li@nxp.com>
>> Cc: Jason Jin <jason.jin@nxp.com>
>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>
>> On 23/09/16 14:13, Stuart Yoder wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>>>> Sent: Friday, September 23, 2016 7:17 AM
>>>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>>>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>>>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>>>> <leoyang.li@nxp.com>
>>>> Cc: Jason Jin <jason.jin@nxp.com>
>>>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>>>
>>>> Hi Alison,
>>>>
>>>> On 23/09/16 03:19, Alison Wang wrote:
>>>>> The ARMv8 architecture supports:
>>>>> 1. 64-bit execution state, AArch64.
>>>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>>>> versions of the ARM architecture.
>>>>>
>>>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>>>
>>>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>>>
>>>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>>>> ---
>>>>>  arch/arm/Kconfig                    |  9 +++++++++
>>>>>  arch/arm/mach-imx/Kconfig           | 14 ++++++++++++++
>>>>>  arch/arm/mach-imx/Makefile          |  4 +++-
>>>>>  arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>>>>  4 files changed, 49 insertions(+), 1 deletion(-)
>>>>>  create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>>>
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>> index f0c8068..e8d470e 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>>>>  	default 3 if ARM_LPAE
>>>>>  	default 2
>>>>>
>>>>> +config ARCH_AARCH32_ES_SUPPORT
>>>>> +	def_bool n
>>>>> +	help
>>>>> +	 The ARMv8 architecture supports 64-bit execution state, AArch64
>>>>> +	 and 32-bit execution state, AArch32, that is compatible with
>>>>> +	 previous versions of the ARM architecture.
>>>>> +
>>>>> +	 Enable AArch32 execution state support for ARMv8 architecture.
>>>>
>>>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>>>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>>>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>>>> front of the zImage to switch into AArch32 state).
>>>
>>> Which arch/arm/mach-* platform are you using for Juno?
>>
>> I don't even know! :) I just start with a multi_v7_defconfig plus a few
>> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
>> combination of mach-vexpress and mach-virt.
> 
> Thanks.  A question about the switch into aarch32 state... our assumption
> was that the kernel starts at EL2.  In this proof of concept we're doing the
> switch to aarch32/EL2 in firmware.  And what I'm being told is that the
> firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some 
> assistance from EL3 firmware.  This is leading us to invent a new
> SMC call to do this.
> 
> Did you face this?

Yes, the only way to enter in Hyp is to have the firmware twiddle
SCR_EL3.RW (I simply stuck a disgusting hack directly in ATF's exception
handler, which my dodgy 64-bit header then calls). Otherwise you can
always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
need to trap and translate subsequent SMC calls for e.g. PSCI).

> If there is such a requirement, it's something begging for standardization.
> Doesn't make sense for multiple divergent approaches for switching from
> aarch64/EL2 to aarch32/EL2.

Perhaps - I did briefly look into how hard it would be to write a proper
SMC service handler to do this (since ATF does have a framework for such
things), but concluded it would be more than 10 minutes' work and just
cheated instead. It's certainly something which could be raised with the
firmware folks.

Robin.

> 
> Thanks,
> Stuart
> 

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Arnd Bergmann]

On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> On 23/09/16 15:01, Stuart Yoder wrote:
> Otherwise you can
> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> need to trap and translate subsequent SMC calls for e.g. PSCI).
> 
> > If there is such a requirement, it's something begging for standardization.
> > Doesn't make sense for multiple divergent approaches for switching from
> > aarch64/EL2 to aarch32/EL2.
> 
> Perhaps - I did briefly look into how hard it would be to write a proper
> SMC service handler to do this (since ATF does have a framework for such
> things), but concluded it would be more than 10 minutes' work and just
> cheated instead. It's certainly something which could be raised with the
> firmware folks.

If we end up allowing all arm64 platforms to be enabled in arch/arm,
we could perhaps create a generic implementation that does both of
those things, i.e.

- Take the arm32 kernel Image or zImage file, wrap it inside of a binary
  that implements the arm64 boot protocol.
- When that starts up, try to use the new PSCI call to jump into
  the arm32 kernel
- If PSCI failed and we are running in EL2, implement the shim
  and start the arm32 kernel in EL1 mode

	Arnd

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Robin Murphy]

On 23/09/16 15:44, Arnd Bergmann wrote:
> On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
>> On 23/09/16 15:01, Stuart Yoder wrote:
>> Otherwise you can
>> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
>> need to trap and translate subsequent SMC calls for e.g. PSCI).
>>
>>> If there is such a requirement, it's something begging for standardization.
>>> Doesn't make sense for multiple divergent approaches for switching from
>>> aarch64/EL2 to aarch32/EL2.
>>
>> Perhaps - I did briefly look into how hard it would be to write a proper
>> SMC service handler to do this (since ATF does have a framework for such
>> things), but concluded it would be more than 10 minutes' work and just
>> cheated instead. It's certainly something which could be raised with the
>> firmware folks.
> 
> If we end up allowing all arm64 platforms to be enabled in arch/arm,
> we could perhaps create a generic implementation that does both of
> those things, i.e.
> 
> - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
>   that implements the arm64 boot protocol.
> - When that starts up, try to use the new PSCI call to jump into
>   the arm32 kernel
> - If PSCI failed and we are running in EL2, implement the shim
>   and start the arm32 kernel in EL1 mode

Really, though, the firmware call thing is an incredibly niche use-case.
Beyond development, the only real benefit of starting an AArch32 kernel
in Hyp is that you can run AArch32 KVM guests, which you can do equally
well (if not better) under an AArch64 kernel.

The standalone EL2 shim probably has legs, though, if the one currently
found in arch/arm64 is too heavyweight ;) My first version was
essentially that, albeit implemented by a load of .inst directives in
head.S.

Robin.

> 
> 	Arnd
> 

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Arnd Bergmann]

On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote:
> On 23/09/16 15:44, Arnd Bergmann wrote:
> > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> >> On 23/09/16 15:01, Stuart Yoder wrote:
> >> Otherwise you can
> >> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> >> need to trap and translate subsequent SMC calls for e.g. PSCI).
> >>
> >>> If there is such a requirement, it's something begging for standardization.
> >>> Doesn't make sense for multiple divergent approaches for switching from
> >>> aarch64/EL2 to aarch32/EL2.
> >>
> >> Perhaps - I did briefly look into how hard it would be to write a proper
> >> SMC service handler to do this (since ATF does have a framework for such
> >> things), but concluded it would be more than 10 minutes' work and just
> >> cheated instead. It's certainly something which could be raised with the
> >> firmware folks.
> > 
> > If we end up allowing all arm64 platforms to be enabled in arch/arm,
> > we could perhaps create a generic implementation that does both of
> > those things, i.e.
> > 
> > - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
> >   that implements the arm64 boot protocol.
> > - When that starts up, try to use the new PSCI call to jump into
> >   the arm32 kernel
> > - If PSCI failed and we are running in EL2, implement the shim
> >   and start the arm32 kernel in EL1 mode
> 
> Really, though, the firmware call thing is an incredibly niche use-case.
> Beyond development, the only real benefit of starting an AArch32 kernel
> in Hyp is that you can run AArch32 KVM guests, which you can do equally
> well (if not better) under an AArch64 kernel.

This was my question earlier in the thread, apparently Alison has
another use case in mind, but I don't yet know what that is. If
that use case is important enough, we could do it this way.

The only use case I can think of at the moment is boot testing
on kernelci.org, which could be used to check whether all the drivers
work in 32-bit environments.

	Arnd

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Stuart Yoder]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, September 23, 2016 10:58 AM
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org; Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang
> <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam Estevam
> <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-kernel at vger.kernel.org; Scott Wood
> <scott.wood@nxp.com>; Leo Li <leoyang.li@nxp.com>; Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
> 
> On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote:
> > On 23/09/16 15:44, Arnd Bergmann wrote:
> > > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> > >> On 23/09/16 15:01, Stuart Yoder wrote:
> > >> Otherwise you can
> > >> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> > >> need to trap and translate subsequent SMC calls for e.g. PSCI).
> > >>
> > >>> If there is such a requirement, it's something begging for standardization.
> > >>> Doesn't make sense for multiple divergent approaches for switching from
> > >>> aarch64/EL2 to aarch32/EL2.
> > >>
> > >> Perhaps - I did briefly look into how hard it would be to write a proper
> > >> SMC service handler to do this (since ATF does have a framework for such
> > >> things), but concluded it would be more than 10 minutes' work and just
> > >> cheated instead. It's certainly something which could be raised with the
> > >> firmware folks.
> > >
> > > If we end up allowing all arm64 platforms to be enabled in arch/arm,
> > > we could perhaps create a generic implementation that does both of
> > > those things, i.e.
> > >
> > > - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
> > >   that implements the arm64 boot protocol.
> > > - When that starts up, try to use the new PSCI call to jump into
> > >   the arm32 kernel
> > > - If PSCI failed and we are running in EL2, implement the shim
> > >   and start the arm32 kernel in EL1 mode
> >
> > Really, though, the firmware call thing is an incredibly niche use-case.
> > Beyond development, the only real benefit of starting an AArch32 kernel
> > in Hyp is that you can run AArch32 KVM guests, which you can do equally
> > well (if not better) under an AArch64 kernel.
> 
> This was my question earlier in the thread, apparently Alison has
> another use case in mind, but I don't yet know what that is. If
> that use case is important enough, we could do it this way.
> 
> The only use case I can think of at the moment is boot testing
> on kernelci.org, which could be used to check whether all the drivers
> work in 32-bit environments.

The reason we want aarch32 kernel support is for specific customers that
have requirements for legacy 32-bit kernel drivers that function on ARMv7
but for some reason are very problematic to port to a 64-bit kernel.  So,
the way to ease the 64-bit transition is allow them to run an aarch32 kernel
and their driver on an ARMv8 SoC.   I don't think we specifically care
whether the kernel starts at EL2 or EL1.

Stuart

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Arnd Bergmann]

On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Friday, September 23, 2016 10:58 AM

> > > Really, though, the firmware call thing is an incredibly niche use-case.
> > > Beyond development, the only real benefit of starting an AArch32 kernel
> > > in Hyp is that you can run AArch32 KVM guests, which you can do equally
> > > well (if not better) under an AArch64 kernel.
> > 
> > This was my question earlier in the thread, apparently Alison has
> > another use case in mind, but I don't yet know what that is. If
> > that use case is important enough, we could do it this way.
> > 
> > The only use case I can think of at the moment is boot testing
> > on kernelci.org, which could be used to check whether all the drivers
> > work in 32-bit environments.
> 
> The reason we want aarch32 kernel support is for specific customers that
> have requirements for legacy 32-bit kernel drivers that function on ARMv7
> but for some reason are very problematic to port to a 64-bit kernel.  So,
> the way to ease the 64-bit transition is allow them to run an aarch32 kernel
> and their driver on an ARMv8 SoC.   I don't think we specifically care
> whether the kernel starts at EL2 or EL1.

Thanks for the explanation. Unfortunately I don't think that helps
get this approach upstream, in particular I wouldn't want to add
a platform specific hack just to help a third party not have to fix
their out-of-tree drivers to be 64-bit clean.

If your customer already has a chunk of downstream patches large
enough to be problematic to rebuild for 64-bit, they should be able
to also pick up these two patches, but of course what we really
want is to get drivers upstream and fixed (presumably this would
be an even larger task than just fixing them, so I don't set my
hopes too high here).

I'm still not opposed to making *all* 64-bit platforms available
to 32-bit kernels for testing purposes though, and that would solve
the customer problem too, as would the approach of encapsulating
the kernel in hypervisor stub that implements the PSCI calls
and using MACH_VIRT with the respective layerscape drivers enabled.

	Arnd

[PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

[Jason Jin]

> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape
> platforms
> 
> On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: Friday, September 23, 2016 10:58 AM
> 
> > > > Really, though, the firmware call thing is an incredibly niche use-case.
> > > > Beyond development, the only real benefit of starting an AArch32
> > > > kernel in Hyp is that you can run AArch32 KVM guests, which you
> > > > can do equally well (if not better) under an AArch64 kernel.
> > >
> > > This was my question earlier in the thread, apparently Alison has
> > > another use case in mind, but I don't yet know what that is. If that
> > > use case is important enough, we could do it this way.
> > >
> > > The only use case I can think of at the moment is boot testing on
> > > kernelci.org, which could be used to check whether all the drivers
> > > work in 32-bit environments.
> >
> > The reason we want aarch32 kernel support is for specific customers
> > that have requirements for legacy 32-bit kernel drivers that function
> > on ARMv7 but for some reason are very problematic to port to a 64-bit
> > kernel.  So, the way to ease the 64-bit transition is allow them to run an
> aarch32 kernel
> > and their driver on an ARMv8 SoC.   I don't think we specifically care
> > whether the kernel starts at EL2 or EL1.
> 
> Thanks for the explanation. Unfortunately I don't think that helps get this
> approach upstream, in particular I wouldn't want to add a platform specific
> hack just to help a third party not have to fix their out-of-tree drivers to be 64-
> bit clean.
> 
> If your customer already has a chunk of downstream patches large enough to
> be problematic to rebuild for 64-bit, they should be able to also pick up these
> two patches, but of course what we really want is to get drivers upstream and
> fixed (presumably this would be an even larger task than just fixing them, so I
> don't set my hopes too high here).
> 
> I'm still not opposed to making *all* 64-bit platforms available to 32-bit kernels
> for testing purposes though, and that would solve the customer problem too,
> as would the approach of encapsulating the kernel in hypervisor stub that
> implements the PSCI calls and using MACH_VIRT with the respective layerscape
> drivers enabled.
> 
[Jason] Thanks for all the comments regarding to the ARMv8 32bit kernel patches.
 I'd like to provide some comment from this thread.

To run the 32bit kernel on ARMv8, we also provided some patches to u-boot. The
same U-boot image will be used to boot up the 64bit and 32bit kernel. With u-boot
patches, bootm will automatically identify the kernel image, if it's 32bit kernel image,
u-boot will change the ES to AArch32 EL2 and boot up the 32bit kernel. So we do
not need to wrap the 32bit image with 64bit bootup protocol.

Our FW set the u-boot to EL2 and did not have the 'NEW' SMC call to switch the 
AArch64(EL2) to AArch32(EL2) at this moment, so this patch set did not rely on
the FW and did not  implement the PSCI for secondary core bootup.

I agree with Robin that maybe it's not necessary to support the Hyp for ARMv8 AArch32,
so we can boot up the 32bit kernel with EL1 directly. With this assumption, I think we
can switch to FW and PSCI for SMP easily and drop the spin table patches.

Thanks all for the suggestion. We'll try the "Generic DT based system" instead of
introducing a new platform to support the 32bit kernel. And rely on the dtb built
from ARM64 to bootup the system. Not sure at this moment if some minor update
patches still needed for ARMv8.

Jason
> 	Arnd