Message-ID: <634e9304-2eba-4ea9-65ac-5d4f5d011b70@benettiengineering.com>
Date:   Fri, 17 Dec 2021 10:54:39 +0100
From:   Giulio Benetti <giulio.benetti@...ettiengineering.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jesse Taube <mr.bossman075@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Dong Aisheng <aisheng.dong@....com>,
        Stefan Agner <stefan@...er.ch>,
        Linus Walleij <linus.walleij@...aro.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Olof Johansson <olof@...om.net>, SoC Team <soc@...nel.org>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Abel Vesa <abel.vesa@....com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
        linux-clk <linux-clk@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Vladimir Murzin <vladimir.murzin@....com>
Subject: Re: [RESEND in plain-test] Re: [PATCH v5 0/9] Add initial support for
 the i.MXRTxxxx SoC family starting from i.IMXRT1050 SoC.

Hi Arnd,

On 16/12/21 22:13, Arnd Bergmann wrote:
> On Thu, Dec 16, 2021 at 6:33 PM Giulio Benetti
> <giulio.benetti@...ettiengineering.com> wrote:
>> On 16/12/21 09:26, Arnd Bergmann wrote:
>>> On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@...il.com> wrote:
> 
>>> As a more general comment, it's always nice to see newly added SoC
>>> platforms, especially when they are this well implemented and done
>>> by hobbyists. However, I do think you are being overly optimistic
>>> as to how useful this is going to be to other people: interest in NOMMU
>>> ARM platforms has dropped a lot over the past 5 years, and as far as I
>>> can tell, it is only being kept alive for existing stm32 customers
>>> as the economics do not favor Linux on Cortex-M for new products
>>> compare to Linux on Cortex-A or some RTOS on Cortex-M.
>>>
>>> The existing users will inevitably stop updating their kernels at some
>>> point, and then it's most likely just you and Vladimir Murzin that care.
>>
>>
>> About this will you accept support for the other SoCs in the family?
>> We would like to add in the near future:
>> - i.MXRT1020(uboot support is already upstreamed)
>> - i.MXRT1024(almost equal to 1020)
>> - i.MXRT1060(almost equal to 1050)
>> - i.MXRT1064(almost equal to 1060)
>> And
>> - i.MXRT1160/70 new family with faster core clock(1Ghz) and a cortex M4
>>
>> We need to add missing lcd(uboot upstreamed), usb(uboot upstreamed),
>> ethernet(wip) supports for i.MXRT10xx family.
> 
> Sure, anything you want to work on supporting can be added to the kernel,
> the important bit is that it's well written and can be maintained going forward.
> 
> My best guess is that we'll end up ripping out all NOMMU support in
> a few years, when we get to a point when both of these things happen:
> 
> - the number of actual users that still update their kernels becomes
>    really low
> 
> - There is some treewide refactoring that isn't easily supportable without an
>     MMU unless someone puts extra work into it.
> 
> At the moment, we still support NOMMU kernels on a bunch of architectures
> (Arm, riscv/k210, sh/j2, m68k/coldfire, xtensa and h8300). Out of these,
> Arm is by far the most active, and if Arm NOMMU support was to go away
> for some reason, the others would likely follow.

Ok, I understad now.

>> This is to organize with Jesse also about buying evaluation boards and
>> timing.
>>
>> We’ve meant this porting also as an exercise to deal with Linux deeper
>> for us and for the other newbies.
>>
>> We’ve been also asked about a possible support for s32s(quad cortex-R52)
>> on initial emails but it has no mmu too.
>> While I’m seeing that some cortex-R is landing inside Linux.
>> Would it be interesting anyway?
> 
> I brought that up during the initial review, but I think this is even
> less interesting
> than Cortex-M support from the perspective of potential use cases. While
> Cortex-M MCUs have some advantages over larger SoCs in terms of
> power consumption and cost, this is generally not true for running Linux
> on Cortex-R. The Cortex-R and Cortex-A cores are closely related, so
> they tend have similar power/performance/area characteristics, but
> the lack of an MMU makes the Cortex-R much less useful. If there was
> an advantage to running with the MMU disabled, you could actually do that
> on a Cortex-A as well, but clearly nobody does that either.

Yes

Thank you for the answer

> Vladimir has put some work into making Cortex-R work in the kernel, and
> he may have some other thoughts on this question.

I'm curious if he has something specific to Cortex-R to tell.

I've found that Cortex-R82 has a MMU:
https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82
but I can't find any SoC that uses it. Also, I don't know how many 
people could use it honestly.

Best regards
-- 
Giulio Benetti
Benetti Engineering sas

Powered by blists - more mailing lists