linux-kernel - RE: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB4481B8BDAD2CD7376208B5F2880B0@AM0PR04MB4481.eurprd04.prod.outlook.com>
Date:   Mon, 27 Jan 2020 05:05:14 +0000
From:   Peng Fan <peng.fan@....com>
To:     Adam Ford <aford173@...il.com>, Arnd Bergmann <arnd@...db.de>
CC:     Abel Vesa <abel.vesa@....com>, Anson Huang <anson.huang@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Leonard Crestez <leonard.crestez@....com>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] soc: imx: Makefile: only build soc-imx8 when CONFIG_ARM64

> Subject: Re: [PATCH] soc: imx: Makefile: only build soc-imx8 when
> CONFIG_ARM64
> 
> On Wed, Jan 15, 2020 at 4:39 AM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > On Wed, Jan 15, 2020 at 3:38 AM Peng Fan <peng.fan@....com> 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@....com> 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
> > linux-arm-kernel@...ts.infradead.org
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&amp;data=02%
> 7C0
> >
> 1%7Cpeng.fan%40nxp.com%7Cce51e0735fe547fa561f08d7a0e5ae22%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637154780637371999&amp;sdata
> =n1wX%2FF
> >
> FbDvpcYpE%2FDQZLA8mqhNugtcguit%2F8Mo%2B2O7Q%3D&amp;reserved=
> 0