[PATCH 0/3] ARM: nommu: R-class fixes

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

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(-)

-- 
1.7.9.5

[PATCH 1/3] ARM: nommu: fix PMSAv7 setup

[Vladimir Murzin]

From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

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 <jean-philippe.brucker@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/mm/nommu.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 1dd1093..4d113fc 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -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);
-- 
1.7.9.5

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

[Vladimir Murzin]

From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

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 <jean-philippe.brucker@arm.com>
[changed the MPU side too]
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/kernel/head-nommu.S |    2 +-
 arch/arm/mm/nommu.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 9b8c5a1..fb1a69e 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -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
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 4d113fc..d5805e4 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -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
-- 
1.7.9.5

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

[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 <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/domain.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
index fc8ba16..a031bb9 100644
--- a/arch/arm/include/asm/domain.h
+++ b/arch/arm/include/asm/domain.h
@@ -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
 
-- 
1.7.9.5

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

[Russell King - ARM Linux]

On Fri, Apr 22, 2016 at 12:43:36PM +0100, Vladimir Murzin wrote:
> 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.

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

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

[Vladimir Murzin]

On 27/04/16 11:49, Russell King - ARM Linux wrote:
> On Fri, Apr 22, 2016 at 12:43:36PM +0100, Vladimir Murzin wrote:
>> 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.
> 

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?

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 4adfb46..d10c385 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -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

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

[Russell King - ARM Linux]

On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote:
> 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(+)

diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
index fc8ba1663601..4e218993c12d 100644
--- a/arch/arm/include/asm/domain.h
+++ b/arch/arm/include/asm/domain.h
@@ -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)					\

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

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

[Vladimir Murzin]

On 28/04/16 14:50, Russell King - ARM Linux wrote:
> On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote:
>> 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(+)
> 
> diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
> index fc8ba1663601..4e218993c12d 100644
> --- a/arch/arm/include/asm/domain.h
> +++ b/arch/arm/include/asm/domain.h
> @@ -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

>  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)					\
> 

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

[Russell King - ARM Linux]

On Thu, Apr 28, 2016 at 03:44:34PM +0100, Vladimir Murzin wrote:
> On 28/04/16 14:50, Russell King - ARM Linux wrote:
> > On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote:
> >> 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(+)
> > 
> > diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
> > index fc8ba1663601..4e218993c12d 100644
> > --- a/arch/arm/include/asm/domain.h
> > +++ b/arch/arm/include/asm/domain.h
> > @@ -84,6 +84,7 @@
> >  
> >  #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?

> 
> Cheers
> Vladimir
> 
> >  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)					\
> > 
> 

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

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

[Vladimir Murzin]

On 28/04/16 15:59, Russell King - ARM Linux wrote:
> On Thu, Apr 28, 2016 at 03:44:34PM +0100, Vladimir Murzin wrote:
>> On 28/04/16 14:50, Russell King - ARM Linux wrote:
>>> On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote:
>>>> 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(+)
>>>
>>> diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h
>>> index fc8ba1663601..4e218993c12d 100644
>>> --- a/arch/arm/include/asm/domain.h
>>> +++ b/arch/arm/include/asm/domain.h
>>> @@ -84,6 +84,7 @@
>>>  
>>>  #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

> 
>>
>> Cheers
>> Vladimir
>>
>>>  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)					\
>>>
>>
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Afzal Mohammed]

Hi,

On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:

> 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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 23/04/16 07:54, Afzal Mohammed wrote:
> Hi,
> 
> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:
> 
>> 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

> 
> Regards
> afzal
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
> On 23/04/16 07:54, Afzal Mohammed wrote:
> > Hi,
> > 
> > On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:
> > 
> >> 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

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

[PATCH 0/3] ARM: nommu: R-class fixes

[Afzal Mohammed]

Hi,

On Mon, Apr 25, 2016 at 02:59:13PM +0200, Arnd Bergmann wrote:
> 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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 25/04/16 14:30, Afzal Mohammed wrote:
> Hi,
> 
> On Mon, Apr 25, 2016 at 02:59:13PM +0200, Arnd Bergmann wrote:
>> 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)

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

> 
> Regards
> afzal
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 25/04/16 13:59, Arnd Bergmann wrote:
> On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
>> On 23/04/16 07:54, Afzal Mohammed wrote:
>>> Hi,
>>>
>>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:
>>>
>>>> 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
> 
> 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<-------
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f066e..ead2b25 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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? ;)

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

> 
> 	Arnd
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:
> On 25/04/16 13:59, Arnd Bergmann wrote:
> > On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
> >> On 23/04/16 07:54, Afzal Mohammed wrote:
> >>> Hi,
> >>>
> >>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:
> >>>
> >>>> 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
> > 
> > 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<-------
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a7f066e..ead2b25 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -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? ;)

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:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 107d2868706c..8745f84932af 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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.

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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 26/04/16 10:10, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote:
>> On 25/04/16 13:59, Arnd Bergmann wrote:
>>> On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote:
>>>> On 23/04/16 07:54, Afzal Mohammed wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote:
>>>>>
>>>>>> 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
>>>
>>> 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<-------
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index a7f066e..ead2b25 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -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? ;)
> 
> I think we should discuss this first. It's not necessarily wrong

I'm open ;)

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

I'll play with this, thanks!

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 107d2868706c..8745f84932af 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -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.

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.

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

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

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.

> 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

> 
> 	Arnd
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
> On 26/04/16 10:10, Arnd Bergmann wrote:
> > 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.
> > 
> 
> 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.

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

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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 26/04/16 12:59, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
>> On 26/04/16 10:10, Arnd Bergmann wrote:
>>> 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.
>>>
>>
>> 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.
> 
>>>>> 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.
>>
>> 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.
> 
> 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

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

> 	Arnd
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:
> On 26/04/16 12:59, Arnd Bergmann wrote:
> > On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
> >> On 26/04/16 10:10, Arnd Bergmann 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.
> >>>>
> >>>> 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.
> > 
> > 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?

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

> 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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 26/04/16 19:12, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:
>> On 26/04/16 12:59, Arnd Bergmann wrote:
>>> On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
>>>> On 26/04/16 10:10, Arnd Bergmann 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.
>>>>>>
>>>>>> 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.
>>>
>>> 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?

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.

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

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

> 	Arnd
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote:
> > 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

[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

On 27/04/16 10:50, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote:
>>> 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?

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

> 
> 	Arnd
> 
> 

[PATCH 0/3] ARM: nommu: R-class fixes

[Arnd Bergmann]

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

[PATCH 0/3] ARM: nommu: R-class fixes

[Afzal Mohammed]

Hi,

On Tue, Apr 26, 2016 at 09:17:43AM +0100, Vladimir Murzin wrote:

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

On Tue, Apr 26, 2016 at 01:59:57PM +0200, Arnd Bergmann wrote:
> 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.

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

[PATCH 0/3] ARM: nommu: R-class fixes

[Maxime Coquelin]

Hi,
On 04/26/2016 05:23 PM, Afzal Mohammed wrote:
> Hi,
>
> On Tue, Apr 26, 2016 at 09:17:43AM +0100, Vladimir Murzin wrote:
>
>> 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