All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Ayan Kumar Halder <ayan.kumar.halder@xilinx.com>,
	Stefano Stabellini <stefanos@xilinx.com>
Subject: Re: [RFC PATCH 0/3] ARM: Support Cortex-R platform(s)
Date: Fri, 1 Jul 2022 15:38:21 +0100	[thread overview]
Message-ID: <0a12aa00-f3b5-bc54-b756-38aa06a496fd@arm.com> (raw)
In-Reply-To: <CAK8P3a3w7aUVWi4DG+P1gfWDOoHq=a1ZshDZ41=cp_sb2ErjYQ@mail.gmail.com>

On 7/1/22 15:18, Arnd Bergmann wrote:
> On Fri, Jul 1, 2022 at 11:39 AM Vladimir Murzin <vladimir.murzin@arm.com> wrote:
>> On 6/30/22 22:17, Arnd Bergmann wrote:
>>> On Thu, Jun 30, 2022 at 10:36 AM Vladimir Murzin
>>> <vladimir.murzin@arm.com> wrote:
>>> My main concern is the same as the one we discussed before:
>>> are there actually use cases for which running Linux con Cortex-R
>>> is the right thing to do?
>>
>> Unfortunately, people who have been wondering how to run Linux on
>> Cortex-R are not keen to uncover their use cases it details. Maybe
>> that for quick prototyping or just curiosity...
> 
> Do you know which SoCs they are using? That may give a hint.

No.

> 
>>> While it's clearly an awesome hack that this actually works, I don't
>>> really want to encourage developers to ship products with Linux
>>> on Cortex-R unless there is at least one sensible use case for it.
>>
>> It could be that already happening and we are not aware because
>> area of application might not be visible or broad.
> 
> I'm not too worried about non-mainline products here.
> 
>>> The Cortex-M support is still holding up for the moment, but I
>>> don't think there have been any new deployments in years
>>> (there are a few new hobbyist projects like the imxrt and the
>>> stm32 art pi), and I expect that we will want to completely remove
>>> nommu support at some point.
>>
>> At least for M-class I was told about commercial application (yet in
>> low volume) - the reason why Linux was exactly "we know Linux and
>> do not want yet another RTOS"
> 
> I think that was a common view until a few years ago, but has gotten
> much less common recently. In Linaro, we had multiple developers
> working on Cortex-M, in particular getting ELF-FDPIC support
> working properly. Emcraft had its entire business built around this
> seems to have completely stopped: the software on their website
> has never been updated to use FDPIC or kernels newer than
> linux-4.5.
> 
> Are you aware of anyone going into production recently, and
> based on a more modern kernel?

I'm not at the level where I can observe production story :( Case I
mentioned was around 4.13~4.20

Cheers
Vladimir

> 
>        Arnd


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-01 14:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30  8:36 [RFC PATCH 0/3] ARM: Support Cortex-R platform(s) Vladimir Murzin
2022-06-30  8:36 ` [RFC PATCH 1/3] ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms Vladimir Murzin
2022-06-30  9:22   ` Arnd Bergmann
2022-07-01  9:22     ` Vladimir Murzin
2022-07-01 11:24       ` Arnd Bergmann
2022-06-30  8:36 ` [RFC PATCH 2/3] ARM: mps2: Split into ARCH/MACH options Vladimir Murzin
2022-06-30  8:36 ` [RFC PATCH 3/3] ARM: Introduce MPS3 AN536 Vladimir Murzin
2022-06-30 20:36   ` Stefano Stabellini
2022-07-01  9:06     ` Vladimir Murzin
2022-06-30 21:17 ` [RFC PATCH 0/3] ARM: Support Cortex-R platform(s) Arnd Bergmann
2022-07-01  9:39   ` Vladimir Murzin
2022-07-01 14:18     ` Arnd Bergmann
2022-07-01 14:38       ` Vladimir Murzin [this message]
2022-07-12  8:33 ` Vladimir Murzin
2022-07-12  9:23   ` Arnd Bergmann
2022-07-12 20:44     ` Stefano Stabellini
2022-08-01 15:11       ` Vladimir Murzin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a12aa00-f3b5-bc54-b756-38aa06a496fd@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=arnd@arndb.de \
    --cc=ayan.kumar.halder@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=stefanos@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.