[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 at benettiengineering.com> wrote:
>> On 16/12/21 09:26, Arnd Bergmann wrote:
>>> On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075 at gmail.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