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

Tue Apr 26 02:10:18 PDT 2016

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

