Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG_ARM64

[Arnd Bergmann]

On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <peng.fan@xxxxxxx> wrote:
> > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG_ARM64
> > On Tue, Jan 14, 2020 at 9:32 AM Peng Fan <peng.fan@xxxxxxx> wrote:
> > > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > >
> > > There is no SOC_IMX8 currently. Need to introduce one in
> > > arch/arm64/Kconfig.platforms. But I not see other vendors introduce
> > > options like SOC_XX. Is this the right direction to add one in
> > > Kconfig.platforms?
> >
> > I think it would be more consistent with the other platforms to have a symbol
> > in drivers/soc/imx/Kconfig to control whether we build that driver.
>
> Ok, I'll add Kconfig entry in drivers/soc/imx/Kconfig for various i.MX SoCs.

I was thinking of one entry for this driver.

> > For some SoCs, we also allow running 32-bit kernels, so it would not be wrong
> > to allow enabling the symbol on 32-bit ARM as well, but this is probably
> > something where you want to consider the bigger picture to see if you want
> > to support that configuration or not.
>
> Does the current upstream kernel support 32bit kernels on ARM64 platforms
> without vendor specific stuff. I recalled that several years ago, NXP people
> tried to upstream 32bit kernel support, but rejected by you.

We have at least some Broadcom SoCs that are supported this way. As
long as you can use the same dtb file on a regular multi_v7_defconfig
I see no problem with doing this.

What I would like to avoid though are ports that require extra code in
arch/arm/mach-* that is not needed for the 64-bit target, or ports to
64-bit hardware that only run in 32-bit mode.

> So Is there any plan to support 32bit kernel on AARCH64 in upstream
> kernel?
> Or any suggestions?

I don't think there should be 32-bit kernel running in aarch64-ilp32
mode. This was discussed way back when the aarch64-ilp32 user
space patches first appeared.

Generally speaking you are usually better off running an aarch64
kernel using aarch32 user space, but there may be reasons for
running an ARMv8 aarch32 kernel on the same hardware and there
is no technical reason why this shouldn't work for a clean port.

We never really supported ARMv8-aarch32 in arch/arm/ as a
separate target, but usually building an ARMv7 kernel is close
enough to ARMv8-aarch32 that things just work. If you would
like to help out making ARMv7VE and ARMv8-aarch64 proper
targets for arch/arm/, let me know and we can discuss what parts
are missing.

     Arnd