From: Peng Fan <[email protected]>
Only need to build soc-imx8.c when CONFIG_ARM64 defined,
no need to build it for CONFIG_ARM32 currently.
Signed-off-by: Peng Fan <[email protected]>
---
drivers/soc/imx/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index cf9ca42ff739..cfcbc62b11d7 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,5 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
+ifdef CONFIG_ARM64
obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
+endif
obj-$(CONFIG_IMX_SCU_SOC) += soc-imx-scu.o
--
2.16.4
On Tue, Jan 14, 2020 at 08:08:45AM +0000, Peng Fan wrote:
> From: Peng Fan <[email protected]>
>
> Only need to build soc-imx8.c when CONFIG_ARM64 defined,
> no need to build it for CONFIG_ARM32 currently.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> drivers/soc/imx/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index cf9ca42ff739..cfcbc62b11d7 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1,5 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> +ifdef CONFIG_ARM64
> obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
> +endif
For earlier SoCs we had kconfig symbols like SOC_IMX25. Actually
SOC_IMX8 would be the right one to decide about soc-imx8.c to be
compiled, it would be easier to read and verify than the suggested
"ARM64 && ARCH_MXC" and it would stay right once NXP presents it's next
64-bit SoC i.MX9.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi Uwe,
> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
>
> On Tue, Jan 14, 2020 at 08:08:45AM +0000, Peng Fan wrote:
> > From: Peng Fan <[email protected]>
> >
> > Only need to build soc-imx8.c when CONFIG_ARM64 defined, no need to
> > build it for CONFIG_ARM32 currently.
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > drivers/soc/imx/Makefile | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index
> > cf9ca42ff739..cfcbc62b11d7 100644
> > --- a/drivers/soc/imx/Makefile
> > +++ b/drivers/soc/imx/Makefile
> > @@ -1,5 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> > obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> > +ifdef CONFIG_ARM64
> > obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
> > +endif
>
> For earlier SoCs we had kconfig symbols like SOC_IMX25. Actually
> SOC_IMX8 would be the right one to decide about soc-imx8.c to be compiled,
> it would be easier to read and verify than the suggested
> "ARM64 && ARCH_MXC" and it would stay right once NXP presents it's next
> 64-bit SoC i.MX9.
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?
Thanks,
Peng.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig
> |
> Industrial Linux Solutions |
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> pengutronix.de%2F&data=02%7C01%7Cpeng.fan%40nxp.com%7C90c4c
> 1a07d9242a422ce08d798ca414e%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637145866755858613&sdata=A3e1lAq5wR7d9doxZZV%
> 2FUud1u2qDxdY9VhaHlfzgbhc%3D&reserved=0 |
On Tue, Jan 14, 2020 at 9:32 AM Peng Fan <[email protected]> wrote:
> > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > CONFIG_ARM64
> >
> > On Tue, Jan 14, 2020 at 08:08:45AM +0000, Peng Fan wrote:
> > > From: Peng Fan <[email protected]>
> > >
> > > Only need to build soc-imx8.c when CONFIG_ARM64 defined, no need to
> > > build it for CONFIG_ARM32 currently.
> > >
> > > Signed-off-by: Peng Fan <[email protected]>
> > > ---
> > > drivers/soc/imx/Makefile | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index
> > > cf9ca42ff739..cfcbc62b11d7 100644
> > > --- a/drivers/soc/imx/Makefile
> > > +++ b/drivers/soc/imx/Makefile
> > > @@ -1,5 +1,7 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> > > obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> > > +ifdef CONFIG_ARM64
> > > obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
> > > +endif
> >
> > For earlier SoCs we had kconfig symbols like SOC_IMX25. Actually
> > SOC_IMX8 would be the right one to decide about soc-imx8.c to be compiled,
> > it would be easier to read and verify than the suggested
> > "ARM64 && ARCH_MXC" and it would stay right once NXP presents it's next
> > 64-bit SoC i.MX9.
>
> 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.
If the driver is well written, it should be possible to allow compile
testing it on any architecture (please test this, at least on x86).
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.
Arnd
Hi Arnd,
> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
>
> On Tue, Jan 14, 2020 at 9:32 AM Peng Fan <[email protected]> wrote:
> > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > > CONFIG_ARM64
> > >
> > > On Tue, Jan 14, 2020 at 08:08:45AM +0000, Peng Fan wrote:
> > > > From: Peng Fan <[email protected]>
> > > >
> > > > Only need to build soc-imx8.c when CONFIG_ARM64 defined, no need
> > > > to build it for CONFIG_ARM32 currently.
> > > >
> > > > Signed-off-by: Peng Fan <[email protected]>
> > > > ---
> > > > drivers/soc/imx/Makefile | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> > > > index
> > > > cf9ca42ff739..cfcbc62b11d7 100644
> > > > --- a/drivers/soc/imx/Makefile
> > > > +++ b/drivers/soc/imx/Makefile
> > > > @@ -1,5 +1,7 @@
> > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> > > > obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> > > > +ifdef CONFIG_ARM64
> > > > obj-$(CONFIG_ARCH_MXC) += soc-imx8.o
> > > > +endif
> > >
> > > For earlier SoCs we had kconfig symbols like SOC_IMX25. Actually
> > > SOC_IMX8 would be the right one to decide about soc-imx8.c to be
> > > compiled, it would be easier to read and verify than the suggested
> > > "ARM64 && ARCH_MXC" and it would stay right once NXP presents it's
> > > next 64-bit SoC i.MX9.
> >
> > 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.
>
> If the driver is well written, it should be possible to allow compile testing it on
> any architecture (please test this, at least on x86).
Yes.
>
> 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.
So Is there any plan to support 32bit kernel on AARCH64 in upstream kernel?
Or any suggestions?
Thanks,
Peng.
>
> Arnd
On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <[email protected]> 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 <[email protected]> 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
On Wed, Jan 15, 2020 at 4:39 AM Arnd Bergmann <[email protected]> wrote:
>
> On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <[email protected]> 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 <[email protected]> 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.
I would be interested in learning more about running the i.MX8M in
32-bit mode. I'm looking at running Linux on a device with < 1GB of
RAM, so having 32-bit pointers and instructions would be preferred.
My preference would be to run as ARMv7 for migration purposes, but I'm
open to alternatives.
Does anyone have any suggestions on where I might find some generic
stuff for either iMX8M or generic ARMv8 docs for doing something like
this?
adam
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Jan 24, 2020 at 4:54 PM Adam Ford <[email protected]> wrote:
> On Wed, Jan 15, 2020 at 4:39 AM Arnd Bergmann <[email protected]> wrote:
> > On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <[email protected]> wrote:
>
> I would be interested in learning more about running the i.MX8M in
> 32-bit mode. I'm looking at running Linux on a device with < 1GB of
> RAM, so having 32-bit pointers and instructions would be preferred.
> My preference would be to run as ARMv7 for migration purposes, but I'm
> open to alternatives.
>
> Does anyone have any suggestions on where I might find some generic
> stuff for either iMX8M or generic ARMv8 docs for doing something like
> this?
By far the easiest way is to just run a 64-bit kernel and 32-bit user space,
which should give you 90% of the space savings. This requires no further
work, just pick the 32-bit distro of your choice.
The get the last few percent of memory savings and run a 64-bit kernel,
at least a bit of porting effort should be needed. In principle you should
be able to pass the dtb file for your machine to a 32-bit kernel, but
all drivers have to be there and you need to adjust a few dependencies
to allow 32-bit builds such as
config CLK_IMX8MM
bool "IMX8MM CCM Clock Driver"
- depends on ARCH_MXC && ARM64
+ depends on ARCH_MXC && ARM64
help
Build the driver for i.MX8MM CCM Clock Driver
and then there will likely be a few bugs.
Arnd
> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
>
> On Wed, Jan 15, 2020 at 4:39 AM Arnd Bergmann <[email protected]> wrote:
> >
> > On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <[email protected]> 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
> <[email protected]> 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.
>
> I would be interested in learning more about running the i.MX8M in 32-bit
> mode. I'm looking at running Linux on a device with < 1GB of RAM, so having
> 32-bit pointers and instructions would be preferred.
> My preference would be to run as ARMv7 for migration purposes, but I'm
> open to alternatives.
>
> Does anyone have any suggestions on where I might find some generic stuff
> for either iMX8M or generic ARMv8 docs for doing something like this?
We did a porting for one customer, but code is not public available.
First let uboot switch to AARCH32 mode when booting Linux, this is already
supported by uboot mailine.
Second, create a mach-imx8m.c under arch/arm/mach-imx to handle i.MX8M
just like other i.mx arm32 socs. This is not preferred by Linux community.
3rd, build i.MX8M drivers when using imx_v7_defconfig( or imx_v6_v7_defconfig
in upstream)
Regards,
Peng.
>
> adam
>
> >
> > Arnd
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [email protected]
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%
> 7C0
> >
> 1%7Cpeng.fan%40nxp.com%7Cce51e0735fe547fa561f08d7a0e5ae22%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637154780637371999&sdata
> =n1wX%2FF
> >
> FbDvpcYpE%2FDQZLA8mqhNugtcguit%2F8Mo%2B2O7Q%3D&reserved=
> 0
On Mon, Jan 27, 2020 at 6:05 AM Peng Fan <[email protected]> wrote:
> > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > Does anyone have any suggestions on where I might find some generic stuff
> > for either iMX8M or generic ARMv8 docs for doing something like this?
>
> We did a porting for one customer, but code is not public available.
>
> First let uboot switch to AARCH32 mode when booting Linux, this is already
> supported by uboot mailine.
>
> Second, create a mach-imx8m.c under arch/arm/mach-imx to handle i.MX8M
> just like other i.mx arm32 socs. This is not preferred by Linux community.
>
> 3rd, build i.MX8M drivers when using imx_v7_defconfig( or imx_v6_v7_defconfig
> in upstream)
I think the third part is something we can clearly do once it actually boots.
Can you post the patch for the second part for reference? In theory nothing
should be necessary there, so I wonder what I'm missing (as we need no
code for arch/arm64) and what we can do differently to make it work out of
the box.
Is the problem that the SMP bringup using PSCI for arm64 doesn't work
with the 32-bit kernel for some reason?
Arnd
Hi Arnd,
> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
>
> On Mon, Jan 27, 2020 at 6:05 AM Peng Fan <[email protected]> wrote:
> > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > > Does anyone have any suggestions on where I might find some generic
> > > stuff for either iMX8M or generic ARMv8 docs for doing something like
> this?
> >
> > We did a porting for one customer, but code is not public available.
> >
> > First let uboot switch to AARCH32 mode when booting Linux, this is
> > already supported by uboot mailine.
> >
> > Second, create a mach-imx8m.c under arch/arm/mach-imx to handle
> i.MX8M
> > just like other i.mx arm32 socs. This is not preferred by Linux community.
> >
> > 3rd, build i.MX8M drivers when using imx_v7_defconfig( or
> > imx_v6_v7_defconfig in upstream)
>
> I think the third part is something we can clearly do once it actually boots.
>
> Can you post the patch for the second part for reference? In theory nothing
> should be necessary there, so I wonder what I'm missing (as we need no code
> for arch/arm64) and what we can do differently to make it work out of the
> box.
>
> Is the problem that the SMP bringup using PSCI for arm64 doesn't work with
> the 32-bit kernel for some reason?
Sorry for long time delay. I forgot your mail. I did some try again, seems only need
the following piece code to make it boot, also select GIC_V3 and drop some ARM64
dependencies in Kconfig for some i.MX drivers.
Need some addition work in ATF/U-Boot
to make smp work, that is not Linux related.
+static const char *const imx8mm_dt_compat[] __initconst = {
+ "fsl,imx8mm",
+ NULL,
+};
+
+#include <asm/mach/arch.h>
+DT_MACHINE_START(IMX7D, "Freescale i.MX8MM (Device Tree)")
+ .dt_compat = imx8mm_dt_compat,
+MACHINE_END
Are you ok we add such piece code in drivers/soc/imx/soc-imx8.c to support
aarch32 linux?
Thanks,
Peng.
>
> Arnd
On Mon, Mar 9, 2020 at 2:28 PM Peng Fan <[email protected]> wrote:
> > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > CONFIG_ARM64
> >
> > On Mon, Jan 27, 2020 at 6:05 AM Peng Fan <[email protected]> wrote:
> > > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > > > Does anyone have any suggestions on where I might find some generic
> > > > stuff for either iMX8M or generic ARMv8 docs for doing something like
> > this?
> > >
> > > We did a porting for one customer, but code is not public available.
> > >
> > > First let uboot switch to AARCH32 mode when booting Linux, this is
> > > already supported by uboot mailine.
> > >
> > > Second, create a mach-imx8m.c under arch/arm/mach-imx to handle
> > i.MX8M
> > > just like other i.mx arm32 socs. This is not preferred by Linux community.
> > >
> > > 3rd, build i.MX8M drivers when using imx_v7_defconfig( or
> > > imx_v6_v7_defconfig in upstream)
> >
> > I think the third part is something we can clearly do once it actually boots.
> >
> > Can you post the patch for the second part for reference? In theory nothing
> > should be necessary there, so I wonder what I'm missing (as we need no code
> > for arch/arm64) and what we can do differently to make it work out of the
> > box.
> >
> > Is the problem that the SMP bringup using PSCI for arm64 doesn't work with
> > the 32-bit kernel for some reason?
>
> Sorry for long time delay. I forgot your mail. I did some try again, seems only need
> the following piece code to make it boot, also select GIC_V3 and drop some ARM64
> dependencies in Kconfig for some i.MX drivers.
> Need some addition work in ATF/U-Boot
> to make smp work, that is not Linux related.
Ah, nice!
> +static const char *const imx8mm_dt_compat[] __initconst = {
> + "fsl,imx8mm",
> + NULL,
> +};
> +
> +#include <asm/mach/arch.h>
> +DT_MACHINE_START(IMX7D, "Freescale i.MX8MM (Device Tree)")
> + .dt_compat = imx8mm_dt_compat,
> +MACHINE_END
>
>
> Are you ok we add such piece code in drivers/soc/imx/soc-imx8.c to support
> aarch32 linux?
I don't think that code does anything other than set the machine name. Are you
sure it doesn't work without that?
If it's indeed required, I'd prefer to add a file for in arch/arm/mach-imx than
in drivers/soc/.
Arnd
> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
>
> On Mon, Mar 9, 2020 at 2:28 PM Peng Fan <[email protected]> wrote:
> > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> > > CONFIG_ARM64
> > >
> > > On Mon, Jan 27, 2020 at 6:05 AM Peng Fan <[email protected]> wrote:
> > > > > Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8
> > > > > when Does anyone have any suggestions on where I might find some
> > > > > generic stuff for either iMX8M or generic ARMv8 docs for doing
> > > > > something like
> > > this?
> > > >
> > > > We did a porting for one customer, but code is not public available.
> > > >
> > > > First let uboot switch to AARCH32 mode when booting Linux, this is
> > > > already supported by uboot mailine.
> > > >
> > > > Second, create a mach-imx8m.c under arch/arm/mach-imx to handle
> > > i.MX8M
> > > > just like other i.mx arm32 socs. This is not preferred by Linux
> community.
> > > >
> > > > 3rd, build i.MX8M drivers when using imx_v7_defconfig( or
> > > > imx_v6_v7_defconfig in upstream)
> > >
> > > I think the third part is something we can clearly do once it actually boots.
> > >
> > > Can you post the patch for the second part for reference? In theory
> > > nothing should be necessary there, so I wonder what I'm missing (as
> > > we need no code for arch/arm64) and what we can do differently to
> > > make it work out of the box.
> > >
> > > Is the problem that the SMP bringup using PSCI for arm64 doesn't
> > > work with the 32-bit kernel for some reason?
> >
> > Sorry for long time delay. I forgot your mail. I did some try again,
> > seems only need the following piece code to make it boot, also select
> > GIC_V3 and drop some ARM64 dependencies in Kconfig for some i.MX
> drivers.
> > Need some addition work in ATF/U-Boot
> > to make smp work, that is not Linux related.
>
> Ah, nice!
>
> > +static const char *const imx8mm_dt_compat[] __initconst = {
> > + "fsl,imx8mm",
> > + NULL,
> > +};
> > +
> > +#include <asm/mach/arch.h>
> > +DT_MACHINE_START(IMX7D, "Freescale i.MX8MM (Device Tree)")
> > + .dt_compat = imx8mm_dt_compat,
> > +MACHINE_END
> >
> >
> > Are you ok we add such piece code in drivers/soc/imx/soc-imx8.c to
> > support
> > aarch32 linux?
>
> I don't think that code does anything other than set the machine name. Are
> you sure it doesn't work without that?
Per setup_machine_fdt code, I may need to give a try with
CONFIG_ARCH_MULTIPLATFORM. I'll give a try and update later.
>
> If it's indeed required, I'd prefer to add a file for in arch/arm/mach-imx than
> in drivers/soc/.
Thanks,
Peng.
>
> Arnd