Re: [RESEND in plain-test] Re: [PATCH v5 0/9] Add initial support for the i.MXRTxxxx SoC family starting from i.IMXRT1050 SoC.

[Giulio Benetti]

Hi Arnd,

On 16/12/21 22:13, Arnd Bergmann wrote:
> On Thu, Dec 16, 2021 at 6:33 PM Giulio Benetti
> <giulio.benetti@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On 16/12/21 09:26, Arnd Bergmann wrote:
> > > On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@xxxxxxxxx> 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