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

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

[Vladimir Murzin]

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

-- 
2.25.1


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

[RFC PATCH 1/3] ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms

[Vladimir Murzin]

Similar to ARM_SINGLE_ARMV7M introduce the new config symbol
ARM_SINGLE_ARMV7R which groups config symbols required by ARMv7-R (and
above) platforms.

This would allow supporting multiple ARMv7-R platforms in one kernel
image. However, to be bootable such kernel image requires to share the
same main memory layout.

Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/Kconfig          | 19 ++++++++++++++++++-
 arch/arm/Kconfig.debug    |  6 ++++--
 arch/arm/Makefile         |  2 ++
 arch/arm/kernel/devtree.c |  3 ++-
 4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7630ba9cb6cc..0dda6523724d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -304,8 +304,13 @@ config MMU
 	  Select if you want MMU-based virtualised addressing space
 	  support by paged memory management. If unsure, say 'Y'.
 
+choice
+	prompt "ARM system type"
+	depends on !MMU
+	default ARM_SINGLE_ARMV7M
+
 config ARM_SINGLE_ARMV7M
-	def_bool !MMU
+       bool "ARM Cortex-M based platforms"
 	select ARM_NVIC
 	select AUTO_ZRELADDR
 	select TIMER_OF
@@ -315,6 +320,18 @@ config ARM_SINGLE_ARMV7M
 	select SPARSE_IRQ
 	select USE_OF
 
+config ARM_SINGLE_ARMV7R
+       bool "ARM Cortex-R based platforms"
+	select AUTO_ZRELADDR
+	select TIMER_OF
+	select COMMON_CLK
+	select CPU_V7
+	select NO_IOPORT_MAP
+	select SPARSE_IRQ
+	select USE_OF
+
+endchoice
+
 config ARCH_MMAP_RND_BITS_MIN
 	default 8
 
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b0aa4822d69..832d624203b8 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1904,7 +1904,8 @@ config DEBUG_UART_8250_PALMCHIP
 
 config DEBUG_UNCOMPRESS
 	bool "Enable decompressor debugging via DEBUG_LL output"
-	depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+	depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+		   ARM_SINGLE_ARMV7R
 	depends on DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
 		     (!DEBUG_TEGRA_UART || !ZBOOT_ROM) && \
 		     !DEBUG_BRCMSTB_UART && !DEBUG_SEMIHOSTING
@@ -1922,7 +1923,8 @@ config DEBUG_UNCOMPRESS
 config UNCOMPRESS_INCLUDE
 	string
 	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
-					PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+					PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+					ARM_SINGLE_ARMV7R
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c8e3633f5434..985df6b00b49 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -245,9 +245,11 @@ platdirs := $(patsubst %,arch/arm/plat-%/,$(sort $(plat-y)))
 
 ifneq ($(CONFIG_ARCH_MULTIPLATFORM),y)
 ifneq ($(CONFIG_ARM_SINGLE_ARMV7M),y)
+ifneq ($(CONFIG_ARM_SINGLE_ARMV7R),y)
 KBUILD_CPPFLAGS += $(patsubst %,-I$(srctree)/%include,$(machdirs) $(platdirs))
 endif
 endif
+endif
 
 export	TEXT_OFFSET GZFLAGS MMUEXT
 
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 02839d8b6202..ce2c67c9301e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -194,7 +194,8 @@ const struct machine_desc * __init setup_machine_fdt(void *dt_virt)
 {
 	const struct machine_desc *mdesc, *mdesc_best = NULL;
 
-#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M)
+#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M) || \
+    defined(CONFIG_ARM_SINGLE_ARMV7R)
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
 		.l2c_aux_val = 0x0,
 		.l2c_aux_mask = ~0x0,
-- 
2.25.1


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

[RFC PATCH 2/3] ARM: mps2: Split into ARCH/MACH options

[Vladimir Murzin]

We are about to add MPS2 compatible R-class platform, so we'd need
fine grain control over what should go under M-calss.

Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/Kconfig                | 12 ------------
 arch/arm/mach-versatile/Kconfig | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0dda6523724d..7fa06db2d9e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -631,18 +631,6 @@ config ARCH_LPC18XX
 	  Support for NXP's LPC18xx Cortex-M3 and LPC43xx Cortex-M4
 	  high performance microcontrollers.
 
-config ARCH_MPS2
-	bool "ARM MPS2 platform"
-	depends on ARM_SINGLE_ARMV7M
-	select ARM_AMBA
-	select CLKSRC_MPS2
-	help
-	  Support for Cortex-M Prototyping System (or V2M-MPS2) which comes
-	  with a range of available cores like Cortex-M3/M4/M7.
-
-	  Please, note that depends which Application Note is used memory map
-	  for the platform may vary, so adjustment of RAM base might be needed.
-
 # Definitions to make life easier
 config ARCH_ACORN
 	bool
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index 2ef226194c3a..18643af4f3e1 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -325,3 +325,35 @@ config ARCH_VEXPRESS_TC2_PM
 	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
 
 endif
+
+menuconfig ARCH_MPS2
+	bool "ARM MPS2 family"
+	depends on ARM_SINGLE_ARMV7M
+	select ARM_AMBA
+	select CLKSRC_MPS2
+	help
+         Support for Cortex-M Prototyping System (or V2M-MPS2) which comes
+         with a range of available cores like Cortex-M3/M4/M7.
+
+         Please, note that depends which Application Note is used memory map
+         for the platform may vary, so adjustment of RAM base might be needed.
+
+if ARCH_MPS2
+
+config MACH_MPS2_AN385
+	bool "ARM MPS2 Application Note 385"
+	default y
+
+config MACH_MPS2_AN385
+	bool "ARM MPS2 Application Note 385"
+	default y
+
+config MACH_MPS2_AN399
+	bool "ARM MPS2 Application Note 399"
+	default y
+
+config MACH_MPS2_AN400
+	bool "ARM MPS2 Application Note 400"
+	default y
+
+endif # MPS2
-- 
2.25.1


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

[RFC PATCH 3/3] ARM: Introduce MPS3 AN536

[Vladimir Murzin]

Application Note 536 FPGA image implements the dual Cortex-R52 system
which is extended with interconnect and peripherals to provide an
example design.

Unfortunately, design does't support exclusive access to shareable
memory which is show stopper for SMP support - we enforce shareable
attribute via MPU.

Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/boot/dts/Makefile         |   3 +-
 arch/arm/boot/dts/mps3-an536.dts   | 135 +++++++++++++++++++++++++++++
 arch/arm/mach-versatile/Kconfig    |  27 ++++--
 arch/arm/mach-versatile/v2m-mps2.c |   3 +-
 4 files changed, 160 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/mps3-an536.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5112f493f494..831401e5d021 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -400,7 +400,8 @@ dtb-$(CONFIG_ARCH_MMP) += \
 	mmp3-dell-ariel.dtb
 dtb-$(CONFIG_ARCH_MPS2) += \
 	mps2-an385.dtb \
-	mps2-an399.dtb
+	mps2-an399.dtb \
+	mps3-an536.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_ARCH_SD5203) += \
diff --git a/arch/arm/boot/dts/mps3-an536.dts b/arch/arm/boot/dts/mps3-an536.dts
new file mode 100644
index 000000000000..240c5bb46471
--- /dev/null
+++ b/arch/arm/boot/dts/mps3-an536.dts
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+/*
+ * Copyright (c) 2022, Arm Limited. All rights reserved.
+ *
+ * Author: Vladimir Murzin <vladimir.murzin@arm.com>
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/dts-v1/;
+
+
+/ {
+	model = "ARM MPS3 Application Note 536";
+	compatible = "arm,mps3","arm,mps2";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
+	chosen {
+		bootargs = "earlycon";
+		stdout-path = "serial0:115200n8";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0>;
+		};
+	};
+
+	memory@20000000 {
+		device_type = "memory";
+		reg = <0x20000000 0x20000000>;
+	};
+
+	clk-osc0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+	};
+
+	sysclk: clk-osc1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+	};
+
+	gic: interrupt-controller@f0000000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0xf0000000 0x10000>, // GICD
+		      <0xf0100000 0x40000>; // GICR
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	timer {
+	      compatible = "arm,armv8-timer";
+              interrupts = <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+                           <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+              interrupt-names = "phys", "virt";
+        };
+
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		uart0: serial@e0205000 {
+			compatible = "arm,mps2-uart";
+			reg = <0xe0205000 0x1000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysclk>;
+		};
+
+		uart1: serial@e0206000 {
+			compatible = "arm,mps2-uart";
+			reg = <0xe0206000 0x1000>;
+			interrupts = <GIC_SPI 7  IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8  IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysclk>;
+		};
+
+	};
+
+	fpga@e0200000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0xe0200000 0x3000>;
+
+		fpgaio@2000 {
+			compatible = "syscon", "simple-mfd";
+			reg = <0x2000 0x10>;
+			ranges = <0x0 0x2000 0x10>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			led0,0 {
+				compatible = "register-bit-led";
+				reg = <0x00 0x04>;
+				offset = <0x00>;
+				mask = <0x01>;
+				label = "userled:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+
+			led0,1 {
+				compatible = "register-bit-led";
+				reg = <0x00 0x04>;
+				offset = <0x00>;
+				mask = <0x02>;
+				label = "userled:1";
+				linux,default-trigger = "usr";
+				default-state = "off";
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index 18643af4f3e1..94c26bd7d3b9 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -327,19 +327,21 @@ config ARCH_VEXPRESS_TC2_PM
 endif
 
 menuconfig ARCH_MPS2
-	bool "ARM MPS2 family"
-	depends on ARM_SINGLE_ARMV7M
+	bool "ARM MPS2/MPS3 family"
+	depends on ARM_SINGLE_ARMV7M || ARM_SINGLE_ARMV7R
 	select ARM_AMBA
 	select CLKSRC_MPS2
 	help
-         Support for Cortex-M Prototyping System (or V2M-MPS2) which comes
-         with a range of available cores like Cortex-M3/M4/M7.
+	  Support for ARM MPS2/MPS3 paltform which comes with a range
+	  of available cores from Cortex-M and Cortex-R families.
 
-         Please, note that depends which Application Note is used memory map
-         for the platform may vary, so adjustment of RAM base might be needed.
+	  Please, note that depends which Application Note is used memory map
+	  for the platform may vary, so adjustment of RAM base might be needed.
 
 if ARCH_MPS2
 
+if ARM_SINGLE_ARMV7M
+
 config MACH_MPS2_AN385
 	bool "ARM MPS2 Application Note 385"
 	default y
@@ -356,4 +358,17 @@ config MACH_MPS2_AN400
 	bool "ARM MPS2 Application Note 400"
 	default y
 
+endif # ARMv7-M
+
+if ARM_SINGLE_ARMV7R
+
+config MACH_MPS3_AN536
+       bool "ARM MPS3 Application Note 536"
+       default y
+       select ARM_GIC_V3
+       select HAVE_ARM_ARCH_TIMER
+
+endif # ARMv7-R
+
+
 endif # MPS2
diff --git a/arch/arm/mach-versatile/v2m-mps2.c b/arch/arm/mach-versatile/v2m-mps2.c
index 5b50d8e95cd7..3a6c3bdfefd0 100644
--- a/arch/arm/mach-versatile/v2m-mps2.c
+++ b/arch/arm/mach-versatile/v2m-mps2.c
@@ -9,9 +9,10 @@
 
 static const char *const mps2_compat[] __initconst = {
 	"arm,mps2",
+	"arm,mps3",
 	NULL
 };
 
-DT_MACHINE_START(MPS2DT, "MPS2 (Device Tree Support)")
+DT_MACHINE_START(MPS2DT, "MPS2/MPS3 (Device Tree Support)")
 	.dt_compat = mps2_compat,
 MACHINE_END
-- 
2.25.1


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

Re: [RFC PATCH 1/3] ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms

[Arnd Bergmann]

On Thu, Jun 30, 2022 at 10:36 AM Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
>  config ARM_SINGLE_ARMV7M
> -       def_bool !MMU
> +       bool "ARM Cortex-M based platforms"
>         select ARM_NVIC
>         select AUTO_ZRELADDR
>         select TIMER_OF
> @@ -315,6 +320,18 @@ config ARM_SINGLE_ARMV7M
>         select SPARSE_IRQ
>         select USE_OF
>
> +config ARM_SINGLE_ARMV7R
> +       bool "ARM Cortex-R based platforms"
> +       select AUTO_ZRELADDR
> +       select TIMER_OF
> +       select COMMON_CLK
> +       select CPU_V7
> +       select NO_IOPORT_MAP
> +       select SPARSE_IRQ
> +       select USE_OF
> +

I was actually hoping to eventually kill off the
ARM_SINGLE_ARMV7M and ARCH_MULTIPLATFORM symbols
and just select the other symbols from CONFIG_ARM directly, like

        select SPARSE_IRQ if !ARCH_RPC
        select TIMER_OF if OF
        select USE_OF if !(CPU_SA110 || CPU_SA1100)
        select COMMON_CLK if !(ARCH_FOOTBRIDGE || ARCH_RPC)
        ...

That can of course be done independently from your series, but
it looks like ARM_SINGLE_ARMV7M and ARM_SINGLE_ARMV7R
are mostly the same here, except for the ARM_NVIC selects that
could be done by the platforms, and the CPU_V7/CPU_V7M
difference that could be folded into the CPU selection menu.

       Arnd

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

Re: [RFC PATCH 3/3] ARM: Introduce MPS3 AN536

[Stefano Stabellini]

On Thu, 30 Jun 2022, Vladimir Murzin wrote:
> Application Note 536 FPGA image implements the dual Cortex-R52 system
> which is extended with interconnect and peripherals to provide an
> example design.
> 
> Unfortunately, design does't support exclusive access to shareable
> memory which is show stopper for SMP support - we enforce shareable
> attribute via MPU.

Hi Vladimir,

What do you mean by "design does't support exclusive access to shareable
memory"?

I thought it was possible to use LDREX/STREX on memory shared between
two R52 cores as long as the memory is uncacheable.



> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  arch/arm/boot/dts/Makefile         |   3 +-
>  arch/arm/boot/dts/mps3-an536.dts   | 135 +++++++++++++++++++++++++++++
>  arch/arm/mach-versatile/Kconfig    |  27 ++++--
>  arch/arm/mach-versatile/v2m-mps2.c |   3 +-
>  4 files changed, 160 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm/boot/dts/mps3-an536.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5112f493f494..831401e5d021 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -400,7 +400,8 @@ dtb-$(CONFIG_ARCH_MMP) += \
>         mmp3-dell-ariel.dtb
>  dtb-$(CONFIG_ARCH_MPS2) += \
>         mps2-an385.dtb \
> -       mps2-an399.dtb
> +       mps2-an399.dtb \
> +       mps3-an536.dtb
>  dtb-$(CONFIG_ARCH_MOXART) += \
>         moxart-uc7112lx.dtb
>  dtb-$(CONFIG_ARCH_SD5203) += \
> diff --git a/arch/arm/boot/dts/mps3-an536.dts b/arch/arm/boot/dts/mps3-an536.dts
> new file mode 100644
> index 000000000000..240c5bb46471
> --- /dev/null
> +++ b/arch/arm/boot/dts/mps3-an536.dts
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/*
> + * Copyright (c) 2022, Arm Limited. All rights reserved.
> + *
> + * Author: Vladimir Murzin <vladimir.murzin@arm.com>
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/dts-v1/;
> +
> +
> +/ {
> +       model = "ARM MPS3 Application Note 536";
> +       compatible = "arm,mps3","arm,mps2";
> +       interrupt-parent = <&gic>;
> +       #address-cells = <1>;
> +       #size-cells = <1>;
> +
> +       aliases {
> +               serial0 = &uart0;
> +               serial1 = &uart1;
> +       };
> +
> +       chosen {
> +               bootargs = "earlycon";
> +               stdout-path = "serial0:115200n8";
> +       };
> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "arm,armv8";
> +                       reg = <0>;
> +               };
> +       };
> +
> +       memory@20000000 {
> +               device_type = "memory";
> +               reg = <0x20000000 0x20000000>;
> +       };
> +
> +       clk-osc0 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <24000000>;
> +       };
> +
> +       sysclk: clk-osc1 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <50000000>;
> +       };
> +
> +       gic: interrupt-controller@f0000000 {
> +               compatible = "arm,gic-v3";
> +               #interrupt-cells = <3>;
> +               interrupt-controller;
> +               reg = <0xf0000000 0x10000>, // GICD
> +                     <0xf0100000 0x40000>; // GICR
> +               interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +       };
> +
> +       timer {
> +             compatible = "arm,armv8-timer";
> +              interrupts = <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
> +                           <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
> +              interrupt-names = "phys", "virt";
> +        };
> +
> +
> +       soc {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               uart0: serial@e0205000 {
> +                       compatible = "arm,mps2-uart";
> +                       reg = <0xe0205000 0x1000>;
> +                       interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> +                       clocks = <&sysclk>;
> +               };
> +
> +               uart1: serial@e0206000 {
> +                       compatible = "arm,mps2-uart";
> +                       reg = <0xe0206000 0x1000>;
> +                       interrupts = <GIC_SPI 7  IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 8  IRQ_TYPE_LEVEL_HIGH>,
> +                                    <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> +                       clocks = <&sysclk>;
> +               };
> +
> +       };
> +
> +       fpga@e0200000 {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges = <0 0xe0200000 0x3000>;
> +
> +               fpgaio@2000 {
> +                       compatible = "syscon", "simple-mfd";
> +                       reg = <0x2000 0x10>;
> +                       ranges = <0x0 0x2000 0x10>;
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +
> +                       led0,0 {
> +                               compatible = "register-bit-led";
> +                               reg = <0x00 0x04>;
> +                               offset = <0x00>;
> +                               mask = <0x01>;
> +                               label = "userled:0";
> +                               linux,default-trigger = "heartbeat";
> +                               default-state = "on";
> +                       };
> +
> +                       led0,1 {
> +                               compatible = "register-bit-led";
> +                               reg = <0x00 0x04>;
> +                               offset = <0x00>;
> +                               mask = <0x02>;
> +                               label = "userled:1";
> +                               linux,default-trigger = "usr";
> +                               default-state = "off";
> +                       };
> +               };
> +       };
> +};
> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
> index 18643af4f3e1..94c26bd7d3b9 100644
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -327,19 +327,21 @@ config ARCH_VEXPRESS_TC2_PM
>  endif
> 
>  menuconfig ARCH_MPS2
> -       bool "ARM MPS2 family"
> -       depends on ARM_SINGLE_ARMV7M
> +       bool "ARM MPS2/MPS3 family"
> +       depends on ARM_SINGLE_ARMV7M || ARM_SINGLE_ARMV7R
>         select ARM_AMBA
>         select CLKSRC_MPS2
>         help
> -         Support for Cortex-M Prototyping System (or V2M-MPS2) which comes
> -         with a range of available cores like Cortex-M3/M4/M7.
> +         Support for ARM MPS2/MPS3 paltform which comes with a range
> +         of available cores from Cortex-M and Cortex-R families.
> 
> -         Please, note that depends which Application Note is used memory map
> -         for the platform may vary, so adjustment of RAM base might be needed.
> +         Please, note that depends which Application Note is used memory map
> +         for the platform may vary, so adjustment of RAM base might be needed.
> 
>  if ARCH_MPS2
> 
> +if ARM_SINGLE_ARMV7M
> +
>  config MACH_MPS2_AN385
>         bool "ARM MPS2 Application Note 385"
>         default y
> @@ -356,4 +358,17 @@ config MACH_MPS2_AN400
>         bool "ARM MPS2 Application Note 400"
>         default y
> 
> +endif # ARMv7-M
> +
> +if ARM_SINGLE_ARMV7R
> +
> +config MACH_MPS3_AN536
> +       bool "ARM MPS3 Application Note 536"
> +       default y
> +       select ARM_GIC_V3
> +       select HAVE_ARM_ARCH_TIMER
> +
> +endif # ARMv7-R
> +
> +
>  endif # MPS2
> diff --git a/arch/arm/mach-versatile/v2m-mps2.c b/arch/arm/mach-versatile/v2m-mps2.c
> index 5b50d8e95cd7..3a6c3bdfefd0 100644
> --- a/arch/arm/mach-versatile/v2m-mps2.c
> +++ b/arch/arm/mach-versatile/v2m-mps2.c
> @@ -9,9 +9,10 @@
> 
>  static const char *const mps2_compat[] __initconst = {
>         "arm,mps2",
> +       "arm,mps3",
>         NULL
>  };
> 
> -DT_MACHINE_START(MPS2DT, "MPS2 (Device Tree Support)")
> +DT_MACHINE_START(MPS2DT, "MPS2/MPS3 (Device Tree Support)")
>         .dt_compat = mps2_compat,
>  MACHINE_END
> --
> 2.25.1
> 
> 

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

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

[Arnd Bergmann]

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

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

Re: [RFC PATCH 3/3] ARM: Introduce MPS3 AN536

[Vladimir Murzin]

Hi Stefano,

On 6/30/22 21:36, Stefano Stabellini wrote:
> On Thu, 30 Jun 2022, Vladimir Murzin wrote:
>> Application Note 536 FPGA image implements the dual Cortex-R52 system
>> which is extended with interconnect and peripherals to provide an
>> example design.
>>
>> Unfortunately, design does't support exclusive access to shareable
>> memory which is show stopper for SMP support - we enforce shareable
>> attribute via MPU.
> 
> Hi Vladimir,
> 
> What do you mean by "design does't support exclusive access to shareable
> memory"?
> 

I meant platform integration issue and it has nothing to do with core itself,
in other words it is the issue for this particular platform.

> I thought it was possible to use LDREX/STREX on memory shared between
> two R52 cores as long as the memory is uncacheable.

That's correct understanding assuming integration done correctly :) 

Cheers
Vladimir

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

Re: [RFC PATCH 1/3] ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms

[Vladimir Murzin]

On 6/30/22 10:22, Arnd Bergmann wrote:
> On Thu, Jun 30, 2022 at 10:36 AM Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
>>  config ARM_SINGLE_ARMV7M
>> -       def_bool !MMU
>> +       bool "ARM Cortex-M based platforms"
>>         select ARM_NVIC
>>         select AUTO_ZRELADDR
>>         select TIMER_OF
>> @@ -315,6 +320,18 @@ config ARM_SINGLE_ARMV7M
>>         select SPARSE_IRQ
>>         select USE_OF
>>
>> +config ARM_SINGLE_ARMV7R
>> +       bool "ARM Cortex-R based platforms"
>> +       select AUTO_ZRELADDR
>> +       select TIMER_OF
>> +       select COMMON_CLK
>> +       select CPU_V7
>> +       select NO_IOPORT_MAP
>> +       select SPARSE_IRQ
>> +       select USE_OF
>> +
> 
> I was actually hoping to eventually kill off the
> ARM_SINGLE_ARMV7M and ARCH_MULTIPLATFORM symbols
> and just select the other symbols from CONFIG_ARM directly, like
> 
>         select SPARSE_IRQ if !ARCH_RPC
>         select TIMER_OF if OF
>         select USE_OF if !(CPU_SA110 || CPU_SA1100)
>         select COMMON_CLK if !(ARCH_FOOTBRIDGE || ARCH_RPC)
>         ...
> 
> That can of course be done independently from your series, but
> it looks like ARM_SINGLE_ARMV7M and ARM_SINGLE_ARMV7R
> are mostly the same here, except for the ARM_NVIC selects that
> could be done by the platforms, and the CPU_V7/CPU_V7M
> difference that could be folded into the CPU selection menu.
> 

That sounds interesting! Moving NVIC into platforms looks straightforward,
yet CPU selection would require some surgery:
 - CPU_V7/CPU_V7M are not user selectable at the moment
 - We still need some hint from the platform if it supports more
   than one CPU variant, no?

Cheers
Vladimir

>        Arnd


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

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

[Vladimir Murzin]

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


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

Re: [RFC PATCH 1/3] ARM: Introduce ARM_SINGLE_ARMV7R for ARMv7-R platforms

[Arnd Bergmann]

On Fri, Jul 1, 2022 at 11:22 AM Vladimir Murzin <vladimir.murzin@arm.com> wrote:
> On 6/30/22 10:22, Arnd Bergmann wrote:
> > On Thu, Jun 30, 2022 at 10:36 AM Vladimir Murzin
> >         ...
> >
> > That can of course be done independently from your series, but
> > it looks like ARM_SINGLE_ARMV7M and ARM_SINGLE_ARMV7R
> > are mostly the same here, except for the ARM_NVIC selects that
> > could be done by the platforms, and the CPU_V7/CPU_V7M
> > difference that could be folded into the CPU selection menu.
> >
>
> That sounds interesting! Moving NVIC into platforms looks straightforward,
> yet CPU selection would require some surgery:
>  - CPU_V7/CPU_V7M are not user selectable at the moment
>  - We still need some hint from the platform if it supports more
>    than one CPU variant, no?

Right, the two options still need to be visible somewhere. An obvious
place for this would be the CPU architecture select that currently
depends on ARCH_MULTIPLATFORM and contains the choice
between V4/v4TV5/V6/V6K/V7 but could be extended to cover
V7M and V7R, as well as possibly being extended to V7VE and
V8. I would also consider turning this into a 'choice' list where you
only pick the minimum CPU type, so e.g. enabling V6K lets you
pick V6K/V7/V7VE/V8 based machines but not
V4/V4T/V5/V6/V7M/V7R.

       Arnd

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

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

[Arnd Bergmann]

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

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

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

[Vladimir Murzin]

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

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

[Vladimir Murzin]

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
> 


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

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

[Arnd Bergmann]

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

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

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

[Stefano Stabellini]

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.

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

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

[Vladimir Murzin]

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

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