ARM: nommu: R-class fixes

PATCH New Vladimir Murzin 5 participants 27 messages Apr 22, 2016 – Apr 28, 2016 Arm (32-bit)

lore

Share & tools

lore

Vladimir Murzin

author

2016-04-22 11:43 UTC #0 lore raw

cover ARM: nommu: R-class fixes

Small set of fixes discovered with R-class cores.

Jean-Philippe Brucker (2):
ARM: nommu: fix PMSAv7 setup
ARM: nommu: change memory reserve for the vectors

Vladimir Murzin (1):
ARM: domain: move {set,get}_domain under config guard

 arch/arm/include/asm/domain.h |    5 ++++-
 arch/arm/kernel/head-nommu.S  |    2 +-
 arch/arm/mm/nommu.c           |   15 ++++++++-------
 3 files changed, 13 insertions(+), 9 deletions(-)

Signature · 1 line

1.7.9.5

Vladimir Murzin

author

2016-04-22 11:43 UTC #1 lore raw

PATCH 1/3 ARM: nommu: fix PMSAv7 setup

From: Jean-Philippe Brucker <[email protected]>

Commit 1c2f87c (ARM: 8025/1: Get rid of meminfo) broke the support for MPU on ARMv7-R. This patch adapts the code inside CONFIG_ARM_MPU to use memblocks appropriately.

MPU initialisation only uses the first memory region, and removes all subsequent ones. Because looping over all regions that need removal is inefficient, and memblock_remove already handles memory ranges, we can flatten the 'for_each_memblock' part.

Signed-off-by Jean-Philippe Brucker <[email protected]>

Signed-off-by Vladimir Murzin <[email protected]>

---
 arch/arm/mm/nommu.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

arch/arm/mm/nommu.c +7 -6

index 1dd1093..4d113fc 100644
@@ -87,7 +87,6 @@ static unsigned long irbar_read(void)
 /* MPU initialisation functions */
 void __init sanity_check_meminfo_mpu(void)
 {
-	int i;
 	phys_addr_t phys_offset = PHYS_OFFSET;
 	phys_addr_t aligned_region_size, specified_mem_size, rounded_mem_size;
 	struct memblock_region *reg;

@@ -110,11 +109,13 @@ void __init sanity_check_meminfo_mpu(void)
 		} else {
 			/*
 			 * memblock auto merges contiguous blocks, remove
-			 * all blocks afterwards
+			 * all blocks afterwards in one go (we can't remove
+			 * blocks separately while iterating)
 			 */
 			pr_notice("Ignoring RAM after %pa, memory at %pa ignored\n",
-				  &mem_start, &reg->base);
-			memblock_remove(reg->base, reg->size);
+				  &mem_end, &reg->base);
+			memblock_remove(reg->base, 0 - reg->base);
+			break;
 		}
 	}

@@ -144,7 +145,7 @@ void __init sanity_check_meminfo_mpu(void)
 		pr_warn("Truncating memory from %pa to %pa (MPU region constraints)",
 				&specified_mem_size, &aligned_region_size);
 		memblock_remove(mem_start + aligned_region_size,
-				specified_mem_size - aligned_round_size);
+				specified_mem_size - aligned_region_size);
 
 		mem_end = mem_start + aligned_region_size;
 	}

@@ -261,7 +262,7 @@ void __init mpu_setup(void)
 		return;
 
 	region_err = mpu_setup_region(MPU_RAM_REGION, PHYS_OFFSET,
-					ilog2(meminfo.bank[0].size),
+					ilog2(memblock.memory.regions[0].size),
 					MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL);
 	if (region_err) {
 		panic("MPU region initialization failure! %d", region_err);

Signature · 1 line

1.7.9.5

Vladimir Murzin

author

2016-04-22 11:43 UTC #2 lore raw

PATCH 2/3 ARM: nommu: change memory reserve for the vectors

In reply to Vladimir Murzin

From: Jean-Philippe Brucker <[email protected]>

Commit 19accfd3 (ARM: move vector stubs) moved the vector stubs in an additional page above the base vector one. This change wasn't taken into account by the nommu memreserve.
This patch ensures that the kernel won't overwrite any vector stub on nommu.

Signed-off-by Jean-Philippe Brucker <[email protected]>

[changed the MPU side too]

Signed-off-by Vladimir Murzin <[email protected]>

---
 arch/arm/kernel/head-nommu.S |    2 +-
 arch/arm/mm/nommu.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/kernel/head-nommu.S +1 -1

index 9b8c5a1..fb1a69e 100644
@@ -236,7 +236,7 @@ ENTRY(__setup_mpu)
 	mov	r0, #CONFIG_VECTORS_BASE	@ Cover from VECTORS_BASE
 	ldr	r5,=(MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL)
 	/* Writing N to bits 5:1 (RSR_SZ) --> region size 2^N+1 */
-	mov	r6, #(((PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN)
+	mov	r6, #(((2 * PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN)
 
 	setup_region r0, r5, r6, MPU_DATA_SIDE	@ VECTORS_BASE, PL0 NA, enabled
 	beq	3f				@ Memory-map not unified

arch/arm/mm/nommu.c +1 -1

index 4d113fc..d5805e4 100644
@@ -286,7 +286,7 @@ void __init arm_mm_memblock_reserve(void)
 	 * some architectures which the DRAM is the exception vector to trap,
 	 * alloc_page breaks with error, although it is not NULL, but "0."
 	 */
-	memblock_reserve(CONFIG_VECTORS_BASE, PAGE_SIZE);
+	memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
 #else /* ifndef CONFIG_CPU_V7M */
 	/*
 	 * There is no dedicated vector page on V7-M. So nothing needs to be

Signature · 1 line

1.7.9.5

Vladimir Murzin

author

2016-04-22 11:43 UTC #3 lore raw

PATCH 3/3 ARM: domain: move {set,get}_domain under config guard

In reply to Vladimir Murzin

Domains is not available on !MMU cores, like R/M class. However, currently guarding manages M-class only, for the R-class, in case of fault we get in recursive "undefined instruction" faulting because __show_regs() tries to get domain information.

Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain functions and providing stubs for the case where Domains is not supported.

Signed-off-by Vladimir Murzin <[email protected]>

---
 arch/arm/include/asm/domain.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

arch/arm/include/asm/domain.h +4 -1

index fc8ba16..a031bb9 100644
@@ -84,6 +84,8 @@
 
 #ifndef __ASSEMBLY__
 
+#ifdef CONFIG_CPU_USE_DOMAINS
+
 static inline unsigned int get_domain(void)
 {
 	unsigned int domain;

@@ -104,7 +106,6 @@ static inline void set_domain(unsigned val)
 	isb();
 }
 
-#ifdef CONFIG_CPU_USE_DOMAINS
 #define modify_domain(dom,type)					\
 	do {							\
 		unsigned int domain = get_domain();		\

@@ -114,6 +115,8 @@ static inline void set_domain(unsigned val)
 	} while (0)
 
 #else
+static inline unsigned int get_domain(void) { return 0;}
+static inline void set_domain(unsigned val) { }
 static inline void modify_domain(unsigned dom, unsigned type)	{ }
 #endif

Signature · 1 line

1.7.9.5

Russell King - ARM Linux

2016-04-27 10:49 UTC #4 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 8 lines · Vladimir Murzin

Domains is not available on !MMU cores, like R/M class. However, currently guarding manages M-class only, for the R-class, in case of fault we get in recursive "undefined instruction" faulting because __show_regs() tries to get domain information.
Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain functions and providing stubs for the case where Domains is not supported.

Huge big bloody NAK.

I think it would be useful if you read the history of the file, particularly looking at commit a5e090acbf545c0a3b04080f8a488b17ec41fe02.

It really amazes me how people propose patches which undo bits of previous patches without making comments about it.

No way is this patch going in, which has the effect of completely disabling SW PAN, sorry.

Signature · 3 lines

RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Vladimir Murzin

author

2016-04-27 12:16 UTC #5 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 12 lines · Russell King - ARM Linux

Quoted 8 lines · Vladimir Murzin
Domains is not available on !MMU cores, like R/M class. However, currently guarding manages M-class only, for the R-class, in case of fault we get in recursive "undefined instruction" faulting because __show_regs() tries to get domain information.
Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain functions and providing stubs for the case where Domains is not supported.
Huge big bloody NAK.

Quoted 9 lines

I think it would be useful if you read the history of the file, particularly looking at commit a5e090acbf545c0a3b04080f8a488b17ec41fe02.
It really amazes me how people propose patches which undo bits of previous patches without making comments about it.
No way is this patch going in, which has the effect of completely disabling SW PAN, sorry.

Thanks, Russell!

I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors.

So something like below should be sufficient to fix my case, right?

arch/arm/kernel/process.c +1 -1

index 4adfb46..d10c385 100644
@@ -108,7 +108,7 @@ void __show_regs(struct pt_regs *regs)
        else
                domain = *(unsigned int *)(regs + 1);
 #else
-       domain = get_domain();
+       domain = IS_ENABLED(CONFIG_CPU_USE_DOMAINS)? get_domain() : 0;
 #endif
 #endif

Cheers
Vladimir

Russell King - ARM Linux

2016-04-28 13:50 UTC #6 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 5 lines · Vladimir Murzin

I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors.
So something like below should be sufficient to fix my case, right?

How about:

 arch/arm/include/asm/domain.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

arch/arm/include/asm/domain.h +11 -0

index fc8ba1663601..4e218993c12d 100644
@@ -84,6 +84,7 @@
 
 #ifndef __ASSEMBLY__
 
+#ifdef CONFIG_CPU_CP15
 static inline unsigned int get_domain(void)
 {
 	unsigned int domain;

@@ -103,6 +104,16 @@ static inline void set_domain(unsigned val)
 	  : : "r" (val) : "memory");
 	isb();
 }
+#else
+static inline unsigned int get_domain(void)
+{
+	return 0;
+}
+
+static inline void set_domain(unsigned val)
+{
+}
+#endif
 
 #ifdef CONFIG_CPU_USE_DOMAINS
 #define modify_domain(dom,type)					\

Signature · 3 lines

RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Vladimir Murzin

author

2016-04-28 14:44 UTC #7 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 17 lines · Russell King - ARM Linux

Quoted 5 lines · Vladimir Murzin
I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors.
So something like below should be sufficient to fix my case, right?
How about:
 arch/arm/include/asm/domain.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
arch/arm/include/asm/domain.h +0 -0
index fc8ba1663601..4e218993c12d 100644

arch/arm/include/asm/domain.h line 87

Quoted 4 lines

arch/arm/include/asm/domain.h +1 -0

@@ -84,6 +84,7 @@
 
 #ifndef __ASSEMBLY__
 
+#ifdef CONFIG_CPU_CP15

I'm afraid it won't solve my case since R-class uses cp15 :(

Cheers
Vladimir

Quoted 21 lines

arch/arm/include/asm/domain.h +10 -0

 static inline unsigned int get_domain(void)
 {
 	unsigned int domain;

@@ -103,6 +104,16 @@ static inline void set_domain(unsigned val)
 	  : : "r" (val) : "memory");
 	isb();
 }
+#else
+static inline unsigned int get_domain(void)
+{
+	return 0;
+}
+
+static inline void set_domain(unsigned val)
+{
+}
+#endif
 
 #ifdef CONFIG_CPU_USE_DOMAINS
 #define modify_domain(dom,type)					\

Russell King - ARM Linux

2016-04-28 14:59 UTC #8 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 19 lines · Vladimir Murzin

Quoted 18 lines · Russell King - ARM Linux
Quoted 5 lines · Vladimir Murzin
I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors.
So something like below should be sufficient to fix my case, right?
How about:
 arch/arm/include/asm/domain.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
arch/arm/include/asm/domain.h +0 -0
index fc8ba1663601..4e218993c12d 100644
@@ -84,6 +84,7 @@
 

Quoted 5 lines

arch/arm/include/asm/domain.h line 87
Quoted 3 lines
arch/arm/include/asm/domain.h +1 -0
 #ifndef __ASSEMBLY__
 
+#ifdef CONFIG_CPU_CP15
I'm afraid it won't solve my case since R-class uses cp15 :(

So maybe CPU_CP15_MMU then there?

Quoted 26 lines

Cheers
Vladimir

Quoted 21 lines

arch/arm/include/asm/domain.h +10 -0

 static inline unsigned int get_domain(void)
 {
 	unsigned int domain;

@@ -103,6 +104,16 @@ static inline void set_domain(unsigned val)
 	  : : "r" (val) : "memory");
 	isb();
 }
+#else
+static inline unsigned int get_domain(void)
+{
+	return 0;
+}
+
+static inline void set_domain(unsigned val)
+{
+}
+#endif
 
 #ifdef CONFIG_CPU_USE_DOMAINS
 #define modify_domain(dom,type)					\

Signature · 3 lines

RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Vladimir Murzin

author

2016-04-28 15:06 UTC #9 lore raw

PATCH 3/3 ARM: domain: move {set, get}_domain under config guard

Quoted 20 lines · Russell King - ARM Linux

Quoted 19 lines · Vladimir Murzin
Quoted 18 lines · Russell King - ARM Linux
Quoted 5 lines · Vladimir Murzin
I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors.
So something like below should be sufficient to fix my case, right?
How about:
 arch/arm/include/asm/domain.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
arch/arm/include/asm/domain.h +0 -0
index fc8ba1663601..4e218993c12d 100644
@@ -84,6 +84,7 @@
 

Quoted 7 lines

Quoted 5 lines
arch/arm/include/asm/domain.h line 87
Quoted 3 lines
arch/arm/include/asm/domain.h +1 -0
 #ifndef __ASSEMBLY__
 
+#ifdef CONFIG_CPU_CP15
I'm afraid it won't solve my case since R-class uses cp15 :(
So maybe CPU_CP15_MMU then there?

That should work :)

Thanks
Vladimir

Quoted 28 lines

Quoted 27 lines

Cheers
Vladimir

Quoted 21 lines

arch/arm/include/asm/domain.h +10 -0

 static inline unsigned int get_domain(void)
 {
 	unsigned int domain;

@@ -103,6 +104,16 @@ static inline void set_domain(unsigned val)
 	  : : "r" (val) : "memory");
 	isb();
 }
+#else
+static inline unsigned int get_domain(void)
+{
+	return 0;
+}
+
+static inline void set_domain(unsigned val)
+{
+}
+#endif
 
 #ifdef CONFIG_CPU_USE_DOMAINS
 #define modify_domain(dom,type)					\

Afzal Mohammed

2016-04-23 06:54 UTC #10 lore raw

cover ARM: nommu: R-class fixes

In reply to Vladimir Murzin

Hi,

Quoted 1 line · Vladimir Murzin

Small set of fixes discovered with R-class cores.

just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.

Regards
afzal

Vladimir Murzin

author

2016-04-25 07:55 UTC #11 lore raw

cover ARM: nommu: R-class fixes

Quoted 8 lines · Afzal Mohammed

Hi,
Quoted 1 line · Vladimir Murzin
Small set of fixes discovered with R-class cores.
just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.

Hi,

I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first.

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html

Cheers
Vladimir

Quoted 5 lines

Regards
afzal

Arnd Bergmann

2016-04-25 12:59 UTC #12 lore raw

cover ARM: nommu: R-class fixes

Quoted 12 lines · On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:

Quoted 8 lines · Afzal Mohammed
Hi,
Quoted 1 line · Vladimir Murzin
Small set of fixes discovered with R-class cores.
just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.
Hi,

Quoted 8 lines

I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html

Good to know, thanks for working on this!

What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.

Arnd

Afzal Mohammed

2016-04-25 13:30 UTC #13 lore raw

cover ARM: nommu: R-class fixes

Hi,

Quoted 5 lines · Arnd Bergmann

On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.

And for compiling user space, which toolchain is being used ? (i am quite shaky on this question, since !MMU, assuming that the normal one used for Cortex-A userspace can't be used)

Regards
afzal

Vladimir Murzin

author

2016-04-26 08:17 UTC #14 lore raw

cover ARM: nommu: R-class fixes

Quoted 5 lines · Afzal Mohammed

Hi,
Quoted 1 line · Arnd Bergmann
On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:

Quoted 7 lines

Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
And for compiling user space, which toolchain is being used ? (i am quite shaky on this question, since !MMU, assuming that the normal one used for Cortex-A userspace can't be used)

I built myself, but there are prebild tools available at [1] although I've never tried them.

It seems to me there have been internal patches to support FDPIC [2], but I don't know what happen afterwards :(

[1] https://launchpad.net/gcc-arm-embedded
[2]
http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/

Cheers
Vladimir

Quoted 5 lines

Regards
afzal

Afzal Mohammed

2016-04-26 15:23 UTC #15 lore raw

cover ARM: nommu: R-class fixes

Hi,

Quoted 9 lines · Vladimir Murzin

I built myself, but there are prebild tools available at [1] although I've never tried them.
It seems to me there have been internal patches to support FDPIC [2], but I don't know what happen afterwards :(
[1] https://launchpad.net/gcc-arm-embedded
[2]
http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/

Thank You, [2] gave some indigestion :), will take some to ...

Quoted 3 lines · Arnd Bergmann

On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
and there are probably use cases for ARMv7-A without MMU.

My regular work is motor control related that uses RTOS, there was a potential customer asking about running it with MMU, caches disabled on A9. Probably the reason being they considering guranteed worst case performance w/ caches enabled similar to that w/ caches disabled, though that requirement was not in Linux.

Quoted 6 lines

Quoted 2 lines
Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP
I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches).

Have once tried to compile ARMv7-A w/o MMU, got entangled in a web of Kconfig dependencies, iirc one among them was that with !MMU, MULTI_V7 platforms (AM335x, Vybrid A5 part) couldn't be selected, probably because of SMP dependency, but that was on a older Kernel version.

Regards
afzal

Maxime Coquelin

2016-04-28 09:41 UTC #16 lore raw

cover ARM: nommu: R-class fixes

Hi,

Quoted 14 lines · Afzal Mohammed

Hi,
Quoted 10 lines · Vladimir Murzin
I built myself, but there are prebild tools available at [1] although I've never tried them.
It seems to me there have been internal patches to support FDPIC [2], but I don't know what happen afterwards :(
[1] https://launchpad.net/gcc-arm-embedded
[2]
http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/

The ARM FDPIC port is done by Mickael Guene (Added in cc:). His work is available on github:
- abi : https://github.com/mickael-guene/fdpic_doc
- general info : https://github.com/mickael-guene/fdpic_manifest

If you want more details, don't hesitate to contact him.

Regards,
Maxime

Vladimir Murzin

author

2016-04-26 08:17 UTC #17 lore raw

cover ARM: nommu: R-class fixes

In reply to Arnd Bergmann

Quoted 19 lines · Arnd Bergmann

Quoted 18 lines · On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
Quoted 8 lines · Afzal Mohammed
Hi,
Quoted 1 line · Vladimir Murzin
Small set of fixes discovered with R-class cores.
just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.
Hi,
I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first.

Quoted 4 lines

Quoted 2 lines
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html
Good to know, thanks for working on this!

Since you are in a thread, just want to confirm if the following is still the right (only?) way how we want to support R-class?

-----8<-------

arch/arm/Kconfig +1 -2

index a7f066e..ead2b25 100644
@@ -289,8 +289,7 @@ choice
 
  config ARCH_MULTIPLATFORM
         bool "Allow multiple platforms to be selected"
-       depends on MMU
-       select ARM_PATCH_PHYS_VIRT
+       select ARM_PATCH_PHYS_VIRT if MMU
         select AUTO_ZRELADDR
         select COMMON_CLK
         select MULTI_IRQ_HANDLER

----->8--------

I have separate Kconfig entry to represent R-class Vexpress platform locally, but I guess it is noway, right? ;)

Quoted 4 lines

What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.

Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.

Cheers
Vladimir

Quoted 4 lines

Arnd

Arnd Bergmann

2016-04-26 09:10 UTC #18 lore raw

cover ARM: nommu: R-class fixes

Quoted 45 lines · On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:

Quoted 19 lines · Arnd Bergmann
Quoted 18 lines · On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
Quoted 8 lines · Afzal Mohammed
Hi,
Quoted 1 line · Vladimir Murzin
Small set of fixes discovered with R-class cores.
just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.
Hi,
I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first.
Quoted 4 lines
Quoted 2 lines
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html
Good to know, thanks for working on this!
Since you are in a thread, just want to confirm if the following is still the right (only?) way how we want to support R-class?
-----8<-------
arch/arm/Kconfig +1 -3
index a7f066e..ead2b25 100644
@@ -289,8 +289,7 @@ choice
 
  config ARCH_MULTIPLATFORM
         bool "Allow multiple platforms to be selected"
-       depends on MMU
-       select ARM_PATCH_PHYS_VIRT
+       select ARM_PATCH_PHYS_VIRT if MMU
         select AUTO_ZRELADDR
         select COMMON_CLK
         select MULTI_IRQ_HANDLER
----->8--------

Quoted 2 lines

I have separate Kconfig entry to represent R-class Vexpress platform locally, but I guess it is noway, right? ;)

I think we should discuss this first. It's not necessarily wrong or right, but I have taken a slightly different approach in my randconfig test tree:

arch/arm/Kconfig +6 ~~-13~~

index 107d2868706c..8745f84932af 100644
@@ -314,9 +314,11 @@ source "kernel/Kconfig.freezer"
 
 menu "System Type"
 
+config NOMMU
+	bool
+
 config MMU
-	bool "MMU-based Paged Memory Management Support"
-	default y
+	def_bool !NOMMU
 	help
 	  Select if you want MMU-based virtualised addressing space
 	  support by paged memory management. If unsure, say 'Y'.

@@ -335,12 +337,10 @@ config ARCH_MMAP_RND_BITS_MAX
 #
 choice
 	prompt "ARM system type"
-	default ARM_SINGLE_ARMV7M if !MMU
-	default ARCH_MULTIPLATFORM if MMU
+	default ARCH_MULTIPLATFORM
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
-	depends on MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT

@@ -355,7 +355,6 @@ config ARCH_MULTIPLATFORM
 
 config ARM_SINGLE_ARMV7M
 	bool "ARMv7-M based platforms (Cortex-M0/M3/M4)"
-	depends on !MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_NVIC
 	select AUTO_ZRELADDR

@@ -364,6 +363,7 @@ config ARM_SINGLE_ARMV7M
 	select CPU_V7M
 	select GENERIC_CLOCKEVENTS
 	select NO_IOPORT_MAP
+	select NOMMU
 	select SPARSE_IRQ
 	select USE_OF

@@ -434,7 +434,6 @@ config ARCH_NETX
 
 config ARCH_IOP13XX
 	bool "IOP13xx-based"
-	depends on MMU
 	select CPU_XSC3
 	select NEED_MACH_MEMORY_H
 	select NEED_RET_TO_USER

@@ -447,7 +446,6 @@ config ARCH_IOP13XX
 
 config ARCH_IOP32X
 	bool "IOP32x-based"
-	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select CPU_XSCALE
 	select GPIO_IOP

@@ -460,7 +458,6 @@ config ARCH_IOP32X
 
 config ARCH_IOP33X
 	bool "IOP33x-based"
-	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select CPU_XSCALE
 	select GPIO_IOP

@@ -472,7 +469,6 @@ config ARCH_IOP33X
 
 config ARCH_IXP4XX
 	bool "IXP4xx-based"
-	depends on MMU
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_SUPPORTS_BIG_ENDIAN

@@ -531,7 +527,6 @@ config ARCH_LPC32XX
 
 config ARCH_PXA
 	bool "PXA2xx/PXA3xx-based"
-	depends on MMU
 	select ARCH_MTD_XIP
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_CPU_SUSPEND if PM

@@ -554,7 +549,6 @@ config ARCH_PXA
 
 config ARCH_RPC
 	bool "RiscPC"
-	depends on MMU
 	select ARCH_ACORN
 	select ARCH_MAY_HAVE_PC_FDC
 	select ARCH_SPARSEMEM_ENABLE

@@ -629,7 +623,6 @@ config ARCH_DAVINCI
 
 config ARCH_OMAP1
 	bool "TI OMAP1"
-	depends on MMU
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_OMAP
 	select ARCH_REQUIRE_GPIOLIB

The main question here is how explicit we want to make the selection of MMU support per platform. Today, CONFIG_MMU is a top-level option that decides which platforms are visible, based on whether they can work with or without an MMU or both.

This works fine, but means we probably have to add a lot of 'depends on MMU' with your patch to all the platforms that we want to only build with MMU enabled for some reason.

Turning it around would limit the platforms to the ones that explictly turn on NOMMU support. In order to make ARMv7-R support work, we need either another top-level platform option next to ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A.

Quoted 8 lines

Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.

What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.

The other question here is the usefulness of doing it. I think it would be mainly used for testing, as real Cortex-R type CPUs are rather rare, but a lot of people have cheap ARMv7-A hardware that they can use for testing NOMMU kernels if they want to.

Arnd

Vladimir Murzin

author

2016-04-26 10:57 UTC #19 lore raw

cover ARM: nommu: R-class fixes

Quoted 46 lines · Arnd Bergmann

Quoted 45 lines · On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:
Quoted 19 lines · Arnd Bergmann
Quoted 18 lines · On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
Quoted 8 lines · Afzal Mohammed
Hi,
Quoted 1 line · Vladimir Murzin
Small set of fixes discovered with R-class cores.
just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling.
Hi,
I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first.
Quoted 4 lines
Quoted 2 lines
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html
Good to know, thanks for working on this!
Since you are in a thread, just want to confirm if the following is still the right (only?) way how we want to support R-class?
-----8<-------
arch/arm/Kconfig +1 -3
index a7f066e..ead2b25 100644
@@ -289,8 +289,7 @@ choice
 
  config ARCH_MULTIPLATFORM
         bool "Allow multiple platforms to be selected"
-       depends on MMU
-       select ARM_PATCH_PHYS_VIRT
+       select ARM_PATCH_PHYS_VIRT if MMU
         select AUTO_ZRELADDR
         select COMMON_CLK
         select MULTI_IRQ_HANDLER
----->8--------

Quoted 4 lines

Quoted 2 lines
I have separate Kconfig entry to represent R-class Vexpress platform locally, but I guess it is noway, right? ;)
I think we should discuss this first. It's not necessarily wrong

I'm open ;)

Quoted 3 lines

or right, but I have taken a slightly different approach in my randconfig test tree:

I'll play with this, thanks!

Quoted 105 lines

arch/arm/Kconfig +6 ~~-13~~

index 107d2868706c..8745f84932af 100644
@@ -314,9 +314,11 @@ source "kernel/Kconfig.freezer"
 
 menu "System Type"
 
+config NOMMU
+	bool
+
 config MMU
-	bool "MMU-based Paged Memory Management Support"
-	default y
+	def_bool !NOMMU
 	help
 	  Select if you want MMU-based virtualised addressing space
 	  support by paged memory management. If unsure, say 'Y'.

@@ -335,12 +337,10 @@ config ARCH_MMAP_RND_BITS_MAX
 #
 choice
 	prompt "ARM system type"
-	default ARM_SINGLE_ARMV7M if !MMU
-	default ARCH_MULTIPLATFORM if MMU
+	default ARCH_MULTIPLATFORM
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
-	depends on MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT

@@ -355,7 +355,6 @@ config ARCH_MULTIPLATFORM
 
 config ARM_SINGLE_ARMV7M
 	bool "ARMv7-M based platforms (Cortex-M0/M3/M4)"
-	depends on !MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_NVIC
 	select AUTO_ZRELADDR

@@ -364,6 +363,7 @@ config ARM_SINGLE_ARMV7M
 	select CPU_V7M
 	select GENERIC_CLOCKEVENTS
 	select NO_IOPORT_MAP
+	select NOMMU
 	select SPARSE_IRQ
 	select USE_OF

@@ -434,7 +434,6 @@ config ARCH_NETX
 
 config ARCH_IOP13XX
 	bool "IOP13xx-based"
-	depends on MMU
 	select CPU_XSC3
 	select NEED_MACH_MEMORY_H
 	select NEED_RET_TO_USER

@@ -447,7 +446,6 @@ config ARCH_IOP13XX
 
 config ARCH_IOP32X
 	bool "IOP32x-based"
-	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select CPU_XSCALE
 	select GPIO_IOP

@@ -460,7 +458,6 @@ config ARCH_IOP32X
 
 config ARCH_IOP33X
 	bool "IOP33x-based"
-	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select CPU_XSCALE
 	select GPIO_IOP

@@ -472,7 +469,6 @@ config ARCH_IOP33X
 
 config ARCH_IXP4XX
 	bool "IXP4xx-based"
-	depends on MMU
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_SUPPORTS_BIG_ENDIAN

@@ -531,7 +527,6 @@ config ARCH_LPC32XX
 
 config ARCH_PXA
 	bool "PXA2xx/PXA3xx-based"
-	depends on MMU
 	select ARCH_MTD_XIP
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_CPU_SUSPEND if PM

@@ -554,7 +549,6 @@ config ARCH_PXA
 
 config ARCH_RPC
 	bool "RiscPC"
-	depends on MMU
 	select ARCH_ACORN
 	select ARCH_MAY_HAVE_PC_FDC
 	select ARCH_SPARSEMEM_ENABLE

@@ -629,7 +623,6 @@ config ARCH_DAVINCI
 
 config ARCH_OMAP1
 	bool "TI OMAP1"
-	depends on MMU
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_OMAP
 	select ARCH_REQUIRE_GPIOLIB

Quoted 8 lines

The main question here is how explicit we want to make the selection of MMU support per platform. Today, CONFIG_MMU is a top-level option that decides which platforms are visible, based on whether they can work with or without an MMU or both.
This works fine, but means we probably have to add a lot of 'depends on MMU' with your patch to all the platforms that we want to only build with MMU enabled for some reason.

I've just checked my local branch and it seems not much "depend on" (although I'm not dare to claim randconfig stays happy with that), but some noMMU stubs and a few Kconfig changes across platform.

Quoted 7 lines

Turning it around would limit the platforms to the ones that explictly turn on NOMMU support. In order to make ARMv7-R support work, we need either another top-level platform option next to ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A.

It depends if we what NOMMU represented (apart from M-class) R-class only or R-class + A-class without MMU.

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.

Quoted 8 lines

Quoted 4 lines
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.
What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.

Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see.

On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST.

Quoted 4 lines

The other question here is the usefulness of doing it. I think it would be mainly used for testing, as real Cortex-R type CPUs are rather rare, but a lot of people have cheap ARMv7-A hardware that they can use for testing NOMMU kernels if they want to.

Yes, Cortex-R is extremely rare, it is why I've looked at another alternative - reuse R-class features (MPU only at the moment) from the feature-closest M-class - MPU got unlocked for M-class in the same way as it's done for caches [1].

[1] http://www.spinics.net/lists/arm-kernel/msg498910.html

Quoted 4 lines

Arnd

Arnd Bergmann

2016-04-26 11:59 UTC #20 lore raw

cover ARM: nommu: R-class fixes

Quoted 10 lines · On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:

Quoted 8 lines · Arnd Bergmann
On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:
Turning it around would limit the platforms to the ones that explictly turn on NOMMU support. In order to make ARMv7-R support work, we need either another top-level platform option next to ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A.

Quoted 2 lines

It depends if we what NOMMU represented (apart from M-class) R-class only or R-class + A-class without MMU.

Exactly. The same is of course true for the older architectures:
There are tons of ARM7TDMI, ARM946, ARM1156 or Marvell Feroceon cores without MMU, but we don't currently support any of them with an upstream kernel. Respectively, we should in theory be able to run on any of the other MMU based cores that we do support (ARM720T, StrongARM, ARM92x, ARM1136/1176/MPCore, ...) with the MMU disabled, but neither of the two scenarios seems interesting for mainline kernels in this age any more.

What we know is that ARMv7-M is widely used, ARMv7-R makes a lot of sense to use, and there are probably use cases for ARMv7-A without MMU.

Quoted 17 lines

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
Quoted 8 lines
Quoted 4 lines
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.
What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.
Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see.

Quoted 5 lines

On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST.

I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches).

However, this can be worked around using a static page table set up at boot time that creates hugepage entries with appropriate flags for RAM and I/O areas. If we ever had a usecase for running this setup in production, we could even fake an MPU that way.

Arnd

Vladimir Murzin

author

2016-04-26 12:24 UTC #21 lore raw

cover ARM: nommu: R-class fixes

Quoted 50 lines · Arnd Bergmann

Quoted 10 lines · On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
Quoted 8 lines · Arnd Bergmann
On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:
Turning it around would limit the platforms to the ones that explictly turn on NOMMU support. In order to make ARMv7-R support work, we need either another top-level platform option next to ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A.
Quoted 2 lines
It depends if we what NOMMU represented (apart from M-class) R-class only or R-class + A-class without MMU.
Exactly. The same is of course true for the older architectures:
There are tons of ARM7TDMI, ARM946, ARM1156 or Marvell Feroceon cores without MMU, but we don't currently support any of them with an upstream kernel. Respectively, we should in theory be able to run on any of the other MMU based cores that we do support (ARM720T, StrongARM, ARM92x, ARM1136/1176/MPCore, ...) with the MMU disabled, but neither of the two scenarios seems interesting for mainline kernels in this age any more.
What we know is that ARMv7-M is widely used, ARMv7-R makes a lot of sense to use, and there are probably use cases for ARMv7-A without MMU.
Quoted 17 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
Quoted 8 lines
Quoted 4 lines
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.
What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.
Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see.
Quoted 5 lines
On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST.

Quoted 3 lines

I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches).

Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for such builds, but it can be addressed with 1:1 mappings you've described below

Quoted 5 lines

However, this can be worked around using a static page table set up at boot time that creates hugepage entries with appropriate flags for RAM and I/O areas. If we ever had a usecase for running this setup in production, we could even fake an MPU that way.

I'd think that support for FDPIC would make it one step closer.

I conclude that we don't want dedicated option for R-class cores and we start from assumption that NOMMU covers: M-, R- and A- (without MMU or 1:1 mapping) cores. Please, correct me.

Vladimir

Quoted 3 lines

Arnd

Arnd Bergmann

2016-04-26 18:12 UTC #22 lore raw

cover ARM: nommu: R-class fixes

Quoted 26 lines · On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:

Quoted 25 lines · Arnd Bergmann
Quoted 23 lines · On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
Quoted 4 lines · Arnd Bergmann
Quoted 4 lines
Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
Quoted 8 lines
Quoted 4 lines
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.
What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.
Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see.
On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST.

Quoted 7 lines

Quoted 3 lines
I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches).
Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for such builds, but it can be addressed with 1:1 mappings you've described below

But that's not any different between ARMv7-A and ARMv7-R, right?

Quoted 6 lines

Quoted 4 lines
However, this can be worked around using a static page table set up at boot time that creates hugepage entries with appropriate flags for RAM and I/O areas. If we ever had a usecase for running this setup in production, we could even fake an MPU that way.
I'd think that support for FDPIC would make it one step closer.

Yes, that would be very useful.

Quoted 3 lines

I conclude that we don't want dedicated option for R-class cores and we start from assumption that NOMMU covers: M-, R- and A- (without MMU or 1:1 mapping) cores. Please, correct me.

I'm still undecided on that. On the one hand it would be nice to support building a kernel that can run on both ARMv7-A and ARMv7-R, especially when you are talking about pluggable CPU modules on the same baseboard in case of RealView and Versatile Express.

On the other hand, separating the two has the advantage of keeping it simple, as we don't have to worry about all the ARMv7-A platforms and whether we actually want to allow their kernels to be built with MMU disabled.

Arnd

Vladimir Murzin

author

2016-04-27 09:10 UTC #23 lore raw

cover ARM: nommu: R-class fixes

Quoted 31 lines · Arnd Bergmann

Quoted 30 lines · On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:
Quoted 28 lines · Arnd Bergmann
Quoted 18 lines · On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
Quoted 4 lines · Arnd Bergmann
Quoted 4 lines
Quoted 3 lines
What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled.
Quoted 8 lines
Quoted 4 lines
Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible.
What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU.
Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see.
Quoted 5 lines
On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST.
I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches).

Quoted 5 lines

Quoted 3 lines
Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for such builds, but it can be addressed with 1:1 mappings you've described below
But that's not any different between ARMv7-A and ARMv7-R, right?

Right, but it'd make sort of feeling "as soon as I disable MMU it stops booting" for ARMv7-A where for ARMv7-R it likely won't boot till these parameters supplied. However, it is not a show stopper, just a reminder that extra configuration step might be needed.

Quoted 19 lines

Quoted 7 lines
Quoted 5 lines
However, this can be worked around using a static page table set up at boot time that creates hugepage entries with appropriate flags for RAM and I/O areas. If we ever had a usecase for running this setup in production, we could even fake an MPU that way.
I'd think that support for FDPIC would make it one step closer.
Yes, that would be very useful.
Quoted 3 lines
I conclude that we don't want dedicated option for R-class cores and we start from assumption that NOMMU covers: M-, R- and A- (without MMU or 1:1 mapping) cores. Please, correct me.
I'm still undecided on that. On the one hand it would be nice to support building a kernel that can run on both ARMv7-A and ARMv7-R, especially when you are talking about pluggable CPU modules on the same baseboard in case of RealView and Versatile Express.

Quoted 5 lines

On the other hand, separating the two has the advantage of keeping it simple, as we don't have to worry about all the ARMv7-A platforms and whether we actually want to allow their kernels to be built with MMU disabled.

Ok, what if we start with your approach explicitly saying which platform wants to be listed when CONFIG_MMU is deselected (I think R-class is the first user here) gradually extending such list with ARMv7-A? There is (little?) chance that at some point we can support kernel which can run on both configurations.

Vladimir

Quoted 3 lines

Arnd

Arnd Bergmann

2016-04-27 09:50 UTC #24 lore raw

cover ARM: nommu: R-class fixes

Quoted 11 lines · On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote:

Quoted 5 lines
On the other hand, separating the two has the advantage of keeping it simple, as we don't have to worry about all the ARMv7-A platforms and whether we actually want to allow their kernels to be built with MMU disabled.
Ok, what if we start with your approach explicitly saying which platform wants to be listed when CONFIG_MMU is deselected (I think R-class is the first user here) gradually extending such list with ARMv7-A? There is (little?) chance that at some point we can support kernel which can run on both configurations.

Do you mean adding a ARM_SINGLE_ARMV7R option, or ARCH_MULTI_V7R?

Arnd

Vladimir Murzin

author

2016-04-27 10:55 UTC #25 lore raw

cover ARM: nommu: R-class fixes

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote:
Quoted 5 lines
On the other hand, separating the two has the advantage of keeping it simple, as we don't have to worry about all the ARMv7-A platforms and whether we actually want to allow their kernels to be built with MMU disabled.

Quoted 7 lines

Quoted 5 lines
Ok, what if we start with your approach explicitly saying which platform wants to be listed when CONFIG_MMU is deselected (I think R-class is the first user here) gradually extending such list with ARMv7-A? There is (little?) chance that at some point we can support kernel which can run on both configurations.
Do you mean adding a ARM_SINGLE_ARMV7R option, or ARCH_MULTI_V7R?

I'd think that ARCH_MULTI_V7R would make more sense since it is close rather to the CPU variant than platform, so for the imaginary case where ARMv7-A platform want to run without MMU can adjust it's dependency to

depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R

where

config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" depends on MMU
...

config ARCH_MULTI_V7R
bool "MMU-less ARMv7 based platforms (Cortex-R)" depends on !MMU
...

It is also should work for purely R-class platform, although I'm not keen on Kconfig and may be totally wrong here :(

Cheers
Vladimir

Quoted 4 lines

Arnd

Arnd Bergmann

2016-04-27 11:18 UTC #26 lore raw

cover ARM: nommu: R-class fixes

Quoted 11 lines · On Wednesday 27 April 2016 11:55:12 Vladimir Murzin wrote:

ARMv7-A platform want to run without MMU can adjust it's dependency to
depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R
where
config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" depends on MMU
...

Quoted 7 lines

config ARCH_MULTI_V7R
bool "MMU-less ARMv7 based platforms (Cortex-R)" depends on !MMU
...
It is also should work for purely R-class platform, although I'm not keen on Kconfig and may be totally wrong here

I would not use "depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R" for a machine that actually has an ARMv7-A core, that would be a bit confusing.

If we want to allow building a kernel for ARMv7-A with MMU disabled, I'd drop the 'depends on MMU' for ARCH_MULTI_V7 and move it to whatever parts of the kernel actually have a build-time dependency or that are known to be broken in that configuration.

Arnd