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

Commit Message

Alison Wang Sept. 23, 2016, 2:19 a.m. UTC

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 <[e-mail]>
Signed-off-by: Alison Wang <[e-mail]>
---
 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

Comments

Arnd Bergmann Sept. 23, 2016, 12:11 p.m. UTC | #1

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 <[e-mail]>
> Signed-off-by: Alison Wang <[e-mail]>

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

Robin Murphy Sept. 23, 2016, 12:17 p.m. UTC | #2

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 <[e-mail]>
> Signed-off-by: Alison Wang <[e-mail]>
> ---
>  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
>

Stuart Yoder Sept. 23, 2016, 1:13 p.m. UTC | #3

> -----Original Message-----
> From: Robin Murphy [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 7:17 AM
> To: Alison Wang <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam
> Estevam <[e-mail]>; [e-mail]; [e-mail]; linux-
> [e-mail]; Scott Wood <[e-mail]>; Stuart Yoder <[e-mail]>; Leo Li
> <[e-mail]>
> Cc: Jason Jin <[e-mail]>
> 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 <[e-mail]>
> > Signed-off-by: Alison Wang <[e-mail]>
> > ---
> >  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

Robin Murphy Sept. 23, 2016, 1:18 p.m. UTC | #4

On 23/09/16 14:13, Stuart Yoder wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:[e-mail]]
>> Sent: Friday, September 23, 2016 7:17 AM
>> To: Alison Wang <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam
>> Estevam <[e-mail]>; [e-mail]; [e-mail]; linux-
>> [e-mail]; Scott Wood <[e-mail]>; Stuart Yoder <[e-mail]>; Leo Li
>> <[e-mail]>
>> Cc: Jason Jin <[e-mail]>
>> 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 <[e-mail]>
>>> Signed-off-by: Alison Wang <[e-mail]>
>>> ---
>>>  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
>

Rob Herring Sept. 23, 2016, 1:27 p.m. UTC | #5

On Fri, Sep 23, 2016 at 8:18 AM, Robin Murphy <[e-mail]> wrote:
> On 23/09/16 14:13, Stuart Yoder wrote:
>>
>>
>>> -----Original Message-----
>>> From: Robin Murphy [mailto:[e-mail]]
>>> Sent: Friday, September 23, 2016 7:17 AM
>>> To: Alison Wang <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam
>>> Estevam <[e-mail]>; [e-mail]; [e-mail]; linux-
>>> [e-mail]; Scott Wood <[e-mail]>; Stuart Yoder <[e-mail]>; Leo Li
>>> <[e-mail]>
>>> Cc: Jason Jin <[e-mail]>
>>> 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 <[e-mail]>
>>>> Signed-off-by: Alison Wang <[e-mail]>
>>>> ---
>>>>  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

Sudeep Holla Sept. 23, 2016, 1:42 p.m. UTC | #6

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.

Stuart Yoder Sept. 23, 2016, 2:01 p.m. UTC | #7

> -----Original Message-----
> From: Robin Murphy [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 8:19 AM
> To: Stuart Yoder <[e-mail]>; Alison Wang <[e-mail]>; [e-mail];
> [e-mail]; Fabio Estevam Estevam <[e-mail]>; [e-mail]; linux-arm-
> [e-mail]; [e-mail]; Scott Wood <[e-mail]>; Leo Li
> <[e-mail]>
> Cc: Jason Jin <[e-mail]>
> 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:[e-mail]]
> >> Sent: Friday, September 23, 2016 7:17 AM
> >> To: Alison Wang <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam
> >> Estevam <[e-mail]>; [e-mail]; [e-mail]; linux-
> >> [e-mail]; Scott Wood <[e-mail]>; Stuart Yoder <[e-mail]>; Leo Li
> >> <[e-mail]>
> >> Cc: Jason Jin <[e-mail]>
> >> 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 <[e-mail]>
> >>> Signed-off-by: Alison Wang <[e-mail]>
> >>> ---
> >>>  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

Robin Murphy Sept. 23, 2016, 2:24 p.m. UTC | #8

On 23/09/16 15:01, Stuart Yoder wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:[e-mail]]
>> Sent: Friday, September 23, 2016 8:19 AM
>> To: Stuart Yoder <[e-mail]>; Alison Wang <[e-mail]>; [e-mail];
>> [e-mail]; Fabio Estevam Estevam <[e-mail]>; [e-mail]; linux-arm-
>> [e-mail]; [e-mail]; Scott Wood <[e-mail]>; Leo Li
>> <[e-mail]>
>> Cc: Jason Jin <[e-mail]>
>> 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:[e-mail]]
>>>> Sent: Friday, September 23, 2016 7:17 AM
>>>> To: Alison Wang <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam
>>>> Estevam <[e-mail]>; [e-mail]; [e-mail]; linux-
>>>> [e-mail]; Scott Wood <[e-mail]>; Stuart Yoder <[e-mail]>; Leo Li
>>>> <[e-mail]>
>>>> Cc: Jason Jin <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> Signed-off-by: Alison Wang <[e-mail]>
>>>>> ---
>>>>>  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
>

Arnd Bergmann Sept. 23, 2016, 2:44 p.m. UTC | #9

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

Robin Murphy Sept. 23, 2016, 3:13 p.m. UTC | #10

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
>

Arnd Bergmann Sept. 23, 2016, 3:58 p.m. UTC | #11

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

Stuart Yoder Sept. 23, 2016, 4:09 p.m. UTC | #12

> -----Original Message-----
> From: Arnd Bergmann [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 10:58 AM
> To: Robin Murphy <[e-mail]>
> Cc: [e-mail]; Stuart Yoder <[e-mail]>; Alison Wang
> <[e-mail]>; [e-mail]; [e-mail]; Fabio Estevam Estevam
> <[e-mail]>; [e-mail]; [e-mail]; Scott Wood
> <[e-mail]>; Leo Li <[e-mail]>; Jason Jin <[e-mail]>
> 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

Arnd Bergmann Sept. 23, 2016, 6:22 p.m. UTC | #13

On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:[e-mail]]
> > 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

Jason Jin Sept. 26, 2016, 9:58 a.m. UTC | #14

> 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:[e-mail]]
> > > 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

Patch

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