mbox series

[RFC,0/3] ARM: Support Cortex-R platform(s)

Message ID 20220630083641.21835-1-vladimir.murzin@arm.com (mailing list archive)
Headers show
Series ARM: Support Cortex-R platform(s) | expand

Message

Vladimir Murzin June 30, 2022, 8:36 a.m. UTC
Hi,

I've been running Linux on Cortex-R cores with downstream patches for
several years already. There are few reasons why we have not got any
real platform supporting Cortex-R cores so far:
1) lack of interest
2) lack of easily available platforms
3) missing Kconfig bits

During these years I've been receiving questions (mostly in private)
about running Linux with Cortex-R cores. Use cases vary, but mostly
fall under "we know Linux and do not want yet another RTOS", also
people not always care about real-time features of R-class cores and
see it as an upgrade from M-class cores.

Sometime ago MPS3 platform got support for FPGA image [1] with
Cortex-R52 cores where Linux can live comfortably.

This patchset addresses #3 and brings support for MPS3 platform
featuring Cortex-R52

[1] https://developer.arm.com/downloads/-/download-fpga-images

Vladimir Murzin (3):
  ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms
  ARM: mps2: Split into ARCH/MACH options
  ARM: Introduce MPS3 AN536

 arch/arm/Kconfig                   |  31 ++++---
 arch/arm/Kconfig.debug             |   6 +-
 arch/arm/Makefile                  |   2 +
 arch/arm/boot/dts/Makefile         |   3 +-
 arch/arm/boot/dts/mps3-an536.dts   | 135 +++++++++++++++++++++++++++++
 arch/arm/kernel/devtree.c          |   3 +-
 arch/arm/mach-versatile/Kconfig    |  47 ++++++++++
 arch/arm/mach-versatile/v2m-mps2.c |   3 +-
 8 files changed, 212 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/boot/dts/mps3-an536.dts

Comments

Arnd Bergmann June 30, 2022, 9:17 p.m. UTC | #1
On Thu, Jun 30, 2022 at 10:36 AM Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
>
> I've been running Linux on Cortex-R cores with downstream patches for
> several years already. There are few reasons why we have not got any
> real platform supporting Cortex-R cores so far:
> 1) lack of interest
> 2) lack of easily available platforms
> 3) missing Kconfig bits
>
> During these years I've been receiving questions (mostly in private)
> about running Linux with Cortex-R cores. Use cases vary, but mostly
> fall under "we know Linux and do not want yet another RTOS", also
> people not always care about real-time features of R-class cores and
> see it as an upgrade from M-class cores.
>
> Sometime ago MPS3 platform got support for FPGA image [1] with
> Cortex-R52 cores where Linux can live comfortably.
>
> This patchset addresses #3 and brings support for MPS3 platform
> featuring Cortex-R52

The patches look ok to me, if we want to support Cortex-R, this
is clearly how it should be done.

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?

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.

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.

         Arnd
Vladimir Murzin July 1, 2022, 9:39 a.m. UTC | #2
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:
>>
>> I've been running Linux on Cortex-R cores with downstream patches for
>> several years already. There are few reasons why we have not got any
>> real platform supporting Cortex-R cores so far:
>> 1) lack of interest
>> 2) lack of easily available platforms
>> 3) missing Kconfig bits
>>
>> During these years I've been receiving questions (mostly in private)
>> about running Linux with Cortex-R cores. Use cases vary, but mostly
>> fall under "we know Linux and do not want yet another RTOS", also
>> people not always care about real-time features of R-class cores and
>> see it as an upgrade from M-class cores.
>>
>> Sometime ago MPS3 platform got support for FPGA image [1] with
>> Cortex-R52 cores where Linux can live comfortably.
>>
>> This patchset addresses #3 and brings support for MPS3 platform
>> featuring Cortex-R52
> 
> The patches look ok to me, if we want to support Cortex-R, this
> is clearly how it should be done.

Thanks!

> 
> 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...

> 
> 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.

> 
> 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"

Cheers
Vladimir

> 
>          Arnd
Arnd Bergmann July 1, 2022, 2:18 p.m. UTC | #3
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.

> > 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?

       Arnd
Vladimir Murzin July 1, 2022, 2:38 p.m. UTC | #4
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
Vladimir Murzin July 12, 2022, 8:33 a.m. UTC | #5
On 6/30/22 09:36, Vladimir Murzin wrote:
> Hi,
> 
> I've been running Linux on Cortex-R cores with downstream patches for
> several years already. There are few reasons why we have not got any
> real platform supporting Cortex-R cores so far:
> 1) lack of interest
> 2) lack of easily available platforms
> 3) missing Kconfig bits
> 
> During these years I've been receiving questions (mostly in private)
> about running Linux with Cortex-R cores. Use cases vary, but mostly
> fall under "we know Linux and do not want yet another RTOS", also
> people not always care about real-time features of R-class cores and
> see it as an upgrade from M-class cores.
> 
> Sometime ago MPS3 platform got support for FPGA image [1] with
> Cortex-R52 cores where Linux can live comfortably.
> 
> This patchset addresses #3 and brings support for MPS3 platform
> featuring Cortex-R52
> 
> [1] https://developer.arm.com/downloads/-/download-fpga-images

Anything I can do to make progress with the series or it falls under
"we do not care" category?

Cheers
Vladimir

> 
> Vladimir Murzin (3):
>   ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms
>   ARM: mps2: Split into ARCH/MACH options
>   ARM: Introduce MPS3 AN536
> 
>  arch/arm/Kconfig                   |  31 ++++---
>  arch/arm/Kconfig.debug             |   6 +-
>  arch/arm/Makefile                  |   2 +
>  arch/arm/boot/dts/Makefile         |   3 +-
>  arch/arm/boot/dts/mps3-an536.dts   | 135 +++++++++++++++++++++++++++++
>  arch/arm/kernel/devtree.c          |   3 +-
>  arch/arm/mach-versatile/Kconfig    |  47 ++++++++++
>  arch/arm/mach-versatile/v2m-mps2.c |   3 +-
>  8 files changed, 212 insertions(+), 18 deletions(-)
>  create mode 100644 arch/arm/boot/dts/mps3-an536.dts
>
Arnd Bergmann July 12, 2022, 9:23 a.m. UTC | #6
On Tue, Jul 12, 2022 at 10:33 AM Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> On 6/30/22 09:36, Vladimir Murzin wrote:
> >
> > I've been running Linux on Cortex-R cores with downstream patches for
> > several years already. There are few reasons why we have not got any
> > real platform supporting Cortex-R cores so far:
> > 1) lack of interest
> > 2) lack of easily available platforms
> > 3) missing Kconfig bits
> >
> > During these years I've been receiving questions (mostly in private)
> > about running Linux with Cortex-R cores. Use cases vary, but mostly
> > fall under "we know Linux and do not want yet another RTOS", also
> > people not always care about real-time features of R-class cores and
> > see it as an upgrade from M-class cores.
> >
> > Sometime ago MPS3 platform got support for FPGA image [1] with
> > Cortex-R52 cores where Linux can live comfortably.
> >
> > This patchset addresses #3 and brings support for MPS3 platform
> > featuring Cortex-R52
> >
> > [1] https://developer.arm.com/downloads/-/download-fpga-images
>
> Anything I can do to make progress with the series or it falls under
> "we do not care" category?

I think at this point it's an actively bad idea to merge support for Cortex-R.

I don't think anyone else cares, but if you can find other people that want
this to get merged (and know what they are talking about), you can
overrule me on this.

The existing MPS2 support is important because it gives developers
an easy way to test Cortex-M based NOMMU code, and we still have
users on STM32 at least. I do expect the STM32 MCU user base to
further shrink, to the point where nobody is updating their kernels any
more and we want to remove not just STM32 but all other Cortex-M
platforms. All others are already further down the road of decline and
MPS2 is not useful by itself.

Merging MPS3/Cortex-R52 now feels like a step in the wrong
direction, if that leads to a future situation where we remove
Cortex-M but keep Cortex-R support around.

        Arnd
Stefano Stabellini July 12, 2022, 8:44 p.m. UTC | #7
On Tue, 12 Jul 2022, Arnd Bergmann wrote:
> On Tue, Jul 12, 2022 at 10:33 AM Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
> > On 6/30/22 09:36, Vladimir Murzin wrote:
> > >
> > > I've been running Linux on Cortex-R cores with downstream patches for
> > > several years already. There are few reasons why we have not got any
> > > real platform supporting Cortex-R cores so far:
> > > 1) lack of interest
> > > 2) lack of easily available platforms
> > > 3) missing Kconfig bits
> > >
> > > During these years I've been receiving questions (mostly in private)
> > > about running Linux with Cortex-R cores. Use cases vary, but mostly
> > > fall under "we know Linux and do not want yet another RTOS", also
> > > people not always care about real-time features of R-class cores and
> > > see it as an upgrade from M-class cores.
> > >
> > > Sometime ago MPS3 platform got support for FPGA image [1] with
> > > Cortex-R52 cores where Linux can live comfortably.
> > >
> > > This patchset addresses #3 and brings support for MPS3 platform
> > > featuring Cortex-R52
> > >
> > > [1] https://developer.arm.com/downloads/-/download-fpga-images
> >
> > Anything I can do to make progress with the series or it falls under
> > "we do not care" category?
> 
> I think at this point it's an actively bad idea to merge support for Cortex-R.
> 
> I don't think anyone else cares, but if you can find other people that want
> this to get merged (and know what they are talking about), you can
> overrule me on this.
> 
> The existing MPS2 support is important because it gives developers
> an easy way to test Cortex-M based NOMMU code, and we still have
> users on STM32 at least. I do expect the STM32 MCU user base to
> further shrink, to the point where nobody is updating their kernels any
> more and we want to remove not just STM32 but all other Cortex-M
> platforms. All others are already further down the road of decline and
> MPS2 is not useful by itself.
> 
> Merging MPS3/Cortex-R52 now feels like a step in the wrong
> direction, if that leads to a future situation where we remove
> Cortex-M but keep Cortex-R support around.


I think this series is really cool if nothing else as a demo, so please
make it available somewhere on kernel.org or github with some docs on
how to use it because I am certain someone is going to try it and show
it as a PoC (R52s are still going to be around for a long time). Your
efforts are not going to go to waste :-)

On upstreamability: if the issue was just lack of reviews I can find
time to step in and review the patches. But if the general idea is that
we don't want to keep the code upstream in Linux then I am happy to go
with Arnd's recommendation not to merge.
Vladimir Murzin Aug. 1, 2022, 3:11 p.m. UTC | #8
On 7/12/22 21:44, Stefano Stabellini wrote:
> On Tue, 12 Jul 2022, Arnd Bergmann wrote:
>> On Tue, Jul 12, 2022 at 10:33 AM Vladimir Murzin
>> <vladimir.murzin@arm.com> wrote:
>>> On 6/30/22 09:36, Vladimir Murzin wrote:
>>>>
>>>> I've been running Linux on Cortex-R cores with downstream patches for
>>>> several years already. There are few reasons why we have not got any
>>>> real platform supporting Cortex-R cores so far:
>>>> 1) lack of interest
>>>> 2) lack of easily available platforms
>>>> 3) missing Kconfig bits
>>>>
>>>> During these years I've been receiving questions (mostly in private)
>>>> about running Linux with Cortex-R cores. Use cases vary, but mostly
>>>> fall under "we know Linux and do not want yet another RTOS", also
>>>> people not always care about real-time features of R-class cores and
>>>> see it as an upgrade from M-class cores.
>>>>
>>>> Sometime ago MPS3 platform got support for FPGA image [1] with
>>>> Cortex-R52 cores where Linux can live comfortably.
>>>>
>>>> This patchset addresses #3 and brings support for MPS3 platform
>>>> featuring Cortex-R52
>>>>
>>>> [1] https://developer.arm.com/downloads/-/download-fpga-images
>>>
>>> Anything I can do to make progress with the series or it falls under
>>> "we do not care" category?
>>
>> I think at this point it's an actively bad idea to merge support for Cortex-R.
>>
>> I don't think anyone else cares, but if you can find other people that want
>> this to get merged (and know what they are talking about), you can
>> overrule me on this.
>>
>> The existing MPS2 support is important because it gives developers
>> an easy way to test Cortex-M based NOMMU code, and we still have
>> users on STM32 at least. I do expect the STM32 MCU user base to
>> further shrink, to the point where nobody is updating their kernels any
>> more and we want to remove not just STM32 but all other Cortex-M
>> platforms. All others are already further down the road of decline and
>> MPS2 is not useful by itself.
>>
>> Merging MPS3/Cortex-R52 now feels like a step in the wrong
>> direction, if that leads to a future situation where we remove
>> Cortex-M but keep Cortex-R support around.
> 
> 
> I think this series is really cool if nothing else as a demo, so please
> make it available somewhere on kernel.org or github with some docs on
> how to use it because I am certain someone is going to try it and show
> it as a PoC (R52s are still going to be around for a long time). Your
> efforts are not going to go to waste :-)
> 
> On upstreamability: if the issue was just lack of reviews I can find
> time to step in and review the patches. But if the general idea is that
> we don't want to keep the code upstream in Linux then I am happy to go
> with Arnd's recommendation not to merge.

Thanks everyone for inputs! I've just pushed a branch [1] which contains
the series.

[1] https://gitlab.arm.com/linux-arm/linux-vm/-/tree/staging/rclass-5.19

Cheers
Vladimir