[RFC PATCH 00/11] Allow NOMMU for MULTIPLATFORM

[RFC PATCH 00/11] Allow NOMMU for MULTIPLATFORM

[Vladimir Murzin]

Hi,

With transition to MULTIPLATFORM we lost capability to build NOMMU
configurations. Maybe not a big deal, but there is still interest in
building NOMMU configuration apart from M-class cores. Basically, I'm
talking about R-class cores which shares a lot with A-class except
MMU; there was little interest to run A-class with MMU disabled (or
1:1 MMU mapping) as well.  By now it is not even possible to build
such configurations without extra patches on top. Another aspect is
that some portion of NOMMU code have been (build) untested for a
while.  All these makes it even harder to involve more people in using
NOMMU and build community around that.

This series is trying to make it possible to build NOMMU
configurations. It is done in PATCH 11/11 which allows to select
ARCH_MULTIPLATFORM even for NOMMU. This is controlled with EXPERT
config option. All patches prior 11/11 is an attempt to fix build
failures for NOMMU case. I don't claim they are 100% correct, so I'm
open to suggestion how they can be done in a better way.

Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>

Vladimir Murzin (11):
  ARM: NOMMU: define stubs for fixup
  ARM: ep93xx: select ARM_PATCH_PHYS_VIRT for MMU builds only
  ARM: omap: do not select HIGHMEM explicitly
  PCI: tegra: limit to MMU build only
  ARM: move arm_heavy_mb to MMU/noMMU neutral place
  ARM: tlbflush: drop dependency on CONFIG_SMP
  ARM: sleep: allow it to be build for R-class
  ARM: NOMMU: define debug_ll_io_ini
  ARM: NOMMU: define SECTION_xxx macros
  ARM: NOMMU: define __arm_ioremap_exec and pci_ioremap functions
  ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

 arch/arm/Kconfig                     |    8 ++++----
 arch/arm/include/asm/fixmap.h        |    6 ++++++
 arch/arm/include/asm/mach/map.h      |    2 ++
 arch/arm/include/asm/pgtable-nommu.h |    5 +++++
 arch/arm/include/asm/tlbflush.h      |    2 +-
 arch/arm/kernel/sleep.S              |    4 ----
 arch/arm/mach-omap2/Kconfig          |    1 -
 arch/arm/mm/flush.c                  |   15 ---------------
 arch/arm/mm/iomap.c                  |   17 +++++++++++++++++
 arch/arm/mm/nommu.c                  |   35 ++++++++++++++++++++++++++++++++++
 drivers/pci/host/Kconfig             |    2 +-
 11 files changed, 71 insertions(+), 26 deletions(-)

-- 
1.7.9.5

[RFC PATCH 01/11] ARM: NOMMU: define stubs for fixup

[Vladimir Murzin]

When build for NOMMU following errors show ups:

arch/arm/kernel/patch.c: In function 'patch_map':
arch/arm/kernel/patch.c:39:2: error: implicit declaration of function 'set_fixmap' [-Werror=implicit-function-declaration]
  set_fixmap(fixmap, page_to_phys(page));
  ^
arch/arm/kernel/patch.c:41:2: error: implicit declaration of function '__fix_to_virt' [-Werror=implicit-function-declaration]
  return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
  ^
arch/arm/kernel/patch.c: In function 'patch_unmap':
arch/arm/kernel/patch.c:47:2: error: implicit declaration of function 'clear_fixmap' [-Werror=implicit-function-declaration]
  clear_fixmap(fixmap);
  ^
cc1: some warnings being treated as errors

Fixup does not make much sense in NOMMU configurations, so provide
stub definitions.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/fixmap.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 5c17d2d..0bfc2e3 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -59,6 +59,12 @@ enum fixed_addresses {
 
 #else
 
+#define set_fixmap(idx, phys)
+#define clear_fixmap(idx)
+
+#define __fix_to_virt(x)	(x)
+#define __virt_to_fix(x)	(x)
+
 static inline void early_fixmap_init(void) { }
 
 #endif
-- 
1.7.9.5

[RFC PATCH 01/11] ARM: NOMMU: define stubs for fixup

[Russell King - ARM Linux]

On Tue, Nov 22, 2016 at 09:25:58AM +0000, Vladimir Murzin wrote:
> When build for NOMMU following errors show ups:
> 
> arch/arm/kernel/patch.c: In function 'patch_map':
> arch/arm/kernel/patch.c:39:2: error: implicit declaration of function 'set_fixmap' [-Werror=implicit-function-declaration]
>   set_fixmap(fixmap, page_to_phys(page));
>   ^
> arch/arm/kernel/patch.c:41:2: error: implicit declaration of function '__fix_to_virt' [-Werror=implicit-function-declaration]
>   return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
>   ^
> arch/arm/kernel/patch.c: In function 'patch_unmap':
> arch/arm/kernel/patch.c:47:2: error: implicit declaration of function 'clear_fixmap' [-Werror=implicit-function-declaration]
>   clear_fixmap(fixmap);
>   ^
> cc1: some warnings being treated as errors
> 
> Fixup does not make much sense in NOMMU configurations, so provide
> stub definitions.
> 
> Cc: Russell King <linux@armlinux.org.uk>

I think there should be a Fixes: line for the commit which introduced
this?

> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  arch/arm/include/asm/fixmap.h |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 5c17d2d..0bfc2e3 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -59,6 +59,12 @@ enum fixed_addresses {
>  
>  #else
>  
> +#define set_fixmap(idx, phys)
> +#define clear_fixmap(idx)
> +
> +#define __fix_to_virt(x)	(x)
> +#define __virt_to_fix(x)	(x)
> +
>  static inline void early_fixmap_init(void) { }
>  
>  #endif
> -- 
> 1.7.9.5
> 

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

[RFC PATCH 01/11] ARM: NOMMU: define stubs for fixup

[Vladimir Murzin]

On 22/11/16 09:48, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 09:25:58AM +0000, Vladimir Murzin wrote:
>> When build for NOMMU following errors show ups:
>>
>> arch/arm/kernel/patch.c: In function 'patch_map':
>> arch/arm/kernel/patch.c:39:2: error: implicit declaration of function 'set_fixmap' [-Werror=implicit-function-declaration]
>>   set_fixmap(fixmap, page_to_phys(page));
>>   ^
>> arch/arm/kernel/patch.c:41:2: error: implicit declaration of function '__fix_to_virt' [-Werror=implicit-function-declaration]
>>   return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
>>   ^
>> arch/arm/kernel/patch.c: In function 'patch_unmap':
>> arch/arm/kernel/patch.c:47:2: error: implicit declaration of function 'clear_fixmap' [-Werror=implicit-function-declaration]
>>   clear_fixmap(fixmap);
>>   ^
>> cc1: some warnings being treated as errors
>>
>> Fixup does not make much sense in NOMMU configurations, so provide
>> stub definitions.
>>
>> Cc: Russell King <linux@armlinux.org.uk>
> 
> I think there should be a Fixes: line for the commit which introduced
> this?

It was discovered only after PATCH 11/11 was applied. Without that patch this
error is unreachable, so no regression.

If you do think it is a good to have Fixes: I can add 

Fixes: ab0615e2d6fb (" arm: use fixmap for text patching when text is RO")

Cheers
Vladimir

> 
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>>  arch/arm/include/asm/fixmap.h |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
>> index 5c17d2d..0bfc2e3 100644
>> --- a/arch/arm/include/asm/fixmap.h
>> +++ b/arch/arm/include/asm/fixmap.h
>> @@ -59,6 +59,12 @@ enum fixed_addresses {
>>  
>>  #else
>>  
>> +#define set_fixmap(idx, phys)
>> +#define clear_fixmap(idx)
>> +
>> +#define __fix_to_virt(x)	(x)
>> +#define __virt_to_fix(x)	(x)
>> +
>>  static inline void early_fixmap_init(void) { }
>>  
>>  #endif
>> -- 
>> 1.7.9.5
>>
> 

[RFC PATCH 02/11] ARM: ep93xx: select ARM_PATCH_PHYS_VIRT for MMU builds only

[Vladimir Murzin]

Building in NOMMU configurations lead to the following splat:

warning: (ARCH_INTEGRATOR && ARCH_MULTIPLATFORM && ARCH_EP93XX) selects ARM_PATCH_PHYS_VIRT which has unmet direct dependencies (!XIP_KERNEL && MMU)

Make sure ARM_PATCH_PHYS_VIRT is selected for MMU builds only.

Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..49e0f01 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -380,7 +380,7 @@ config ARCH_EP93XX
 	bool "EP93xx-based"
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARM_AMBA
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if MMU
 	select ARM_VIC
 	select AUTO_ZRELADDR
 	select CLKDEV_LOOKUP
-- 
1.7.9.5

[RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly

[Vladimir Murzin]

Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
HIGHMEM is user selectable option, so probably it would be better to
let user to make a decision on this options or, at least, move it to
defconfig.

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/mach-omap2/Kconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a9afeeb..4e3fb69 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,7 +120,6 @@ config ARCH_OMAP2PLUS_TYPICAL
 	bool "Typical OMAP configuration"
 	default y
 	select AEABI
-	select HIGHMEM
 	select I2C
 	select I2C_OMAP
 	select MENELAUS if ARCH_OMAP2
-- 
1.7.9.5

[RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly

[Russell King - ARM Linux]

On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
> Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
> HIGHMEM is user selectable option, so probably it would be better to
> let user to make a decision on this options or, at least, move it to
> defconfig.

That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
option to let the user select a range of options for typical OMAP2+
configurations, so that the user doesn't have to dig around looking
for multiple options, some of which are hard requirements for OMAP
to be functional.  OMAP is a particularly difficult case because the
hardware tends to be very complex.

However, HIGHMEM should never be a requirement to boot, so this looks
sane.

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

[RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
> > Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
> > HIGHMEM is user selectable option, so probably it would be better to
> > let user to make a decision on this options or, at least, move it to
> > defconfig.
> 
> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
> option to let the user select a range of options for typical OMAP2+
> configurations, so that the user doesn't have to dig around looking
> for multiple options, some of which are hard requirements for OMAP
> to be functional.  OMAP is a particularly difficult case because the
> hardware tends to be very complex.
> 
> However, HIGHMEM should never be a requirement to boot, so this looks
> sane.

Yeah we can add that to the defconfig:

Acked-by: Tony Lindgren <tony@atomide.com>

[RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly

[Vladimir Murzin]

On 23/11/16 15:49, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
>> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
>>> Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
>>> HIGHMEM is user selectable option, so probably it would be better to
>>> let user to make a decision on this options or, at least, move it to
>>> defconfig.
>>
>> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
>> option to let the user select a range of options for typical OMAP2+
>> configurations, so that the user doesn't have to dig around looking
>> for multiple options, some of which are hard requirements for OMAP
>> to be functional.  OMAP is a particularly difficult case because the
>> hardware tends to be very complex.
>>
>> However, HIGHMEM should never be a requirement to boot, so this looks
>> sane.
> 
> Yeah we can add that to the defconfig:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>
> 

Thanks!

Vladimir

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Vladimir Murzin]

This driver uses functionality which available for MMU build only,
thus add dependency on MMU.

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 drivers/pci/host/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..836fa02 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -69,7 +69,7 @@ config PCI_IMX6
 
 config PCI_TEGRA
 	bool "NVIDIA Tegra PCIe controller"
-	depends on ARCH_TEGRA && !ARM64
+	depends on ARCH_TEGRA && !ARM64 && MMU
 	help
 	  Say Y here if you want support for the PCIe host controller found
 	  on NVIDIA Tegra SoCs.
-- 
1.7.9.5

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Arnd Bergmann]

On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
> This driver uses functionality which available for MMU build only,
> thus add dependency on MMU.
> 
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> 

Can you be more specific about what requires the MMU here?

Is it the I/O space remapping or something else?

	Arnd

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Vladimir Murzin]

On 22/11/16 09:31, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
>> This driver uses functionality which available for MMU build only,
>> thus add dependency on MMU.
>>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>
> 
> Can you be more specific about what requires the MMU here?
> 
> Is it the I/O space remapping or something else?

Yes it comes from I/O space remapping.

The fill error log:

  CC      drivers/pci/host/pci-tegra.o
In file included from ./arch/arm/include/asm/page.h:22:0,
                 from ./arch/arm/include/asm/thread_info.h:17,
                 from ./include/linux/thread_info.h:58,
                 from ./include/asm-generic/current.h:4,
                 from ./arch/arm/include/generated/asm/current.h:1,
                 from ./include/linux/mutex.h:13,
                 from ./include/linux/notifier.h:13,
                 from ./include/linux/clk.h:17,
                 from drivers/pci/host/pci-tegra.c:29:
drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
  pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
                           ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:388:27: note: each undeclared identifier is reported only once for each function it appears in
  pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
                           ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:388:43: error: 'L_PTE_YOUNG' undeclared (first use in this function)
  pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
                                           ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:388:57: error: 'L_PTE_DIRTY' undeclared (first use in this function)
  pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
                                                         ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:389:6: error: 'L_PTE_XN' undeclared (first use in this function)
      L_PTE_XN | L_PTE_MT_DEV_SHARED | L_PTE_SHARED);
      ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:389:17: error: 'L_PTE_MT_DEV_SHARED' undeclared (first use in this function)
      L_PTE_XN | L_PTE_MT_DEV_SHARED | L_PTE_SHARED);
                 ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c:389:39: error: 'L_PTE_SHARED' undeclared (first use in this function)
      L_PTE_XN | L_PTE_MT_DEV_SHARED | L_PTE_SHARED);
                                       ^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
 #define __pgprot(x)     (x)
                          ^
drivers/pci/host/pci-tegra.c: At top level:
drivers/pci/host/pci-tegra.c:501:10: error: 'pci_generic_config_read32' undeclared here (not in a function)
  .read = pci_generic_config_read32,
          ^
drivers/pci/host/pci-tegra.c:502:11: error: 'pci_generic_config_write32' undeclared here (not in a function)
  .write = pci_generic_config_write32,
           ^
drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_relax_enable':
drivers/pci/host/pci-tegra.c:609:2: error: implicit declaration of function 'pcie_capability_set_word' [-Werror=implicit-function-declaration]
  pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
  ^
drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_setup':
drivers/pci/host/pci-tegra.c:626:8: error: implicit declaration of function 'pci_remap_iospace' [-Werror=implicit-function-declaration]
  err = pci_remap_iospace(&pcie->pio, pcie->io.start);
        ^
drivers/pci/host/pci-tegra.c:628:3: error: implicit declaration of function 'pci_add_resource_offset' [-Werror=implicit-function-declaration]
   pci_add_resource_offset(&sys->resources, &pcie->pio,
   ^
drivers/pci/host/pci-tegra.c:634:2: error: implicit declaration of function 'pci_add_resource' [-Werror=implicit-function-declaration]
  pci_add_resource(&sys->resources, &pcie->busn);
  ^
drivers/pci/host/pci-tegra.c:636:8: error: implicit declaration of function 'devm_request_pci_bus_resources' [-Werror=implicit-function-declaration]
  err = devm_request_pci_bus_resources(dev, &sys->resources);
        ^
cc1: some warnings being treated as errors
make[1]: *** [drivers/pci/host/pci-tegra.o] Error 1
make: *** [drivers/pci/host/pci-tegra.o] Error 2

Cheers
Vladimir

> 
> 	Arnd
> 
> 

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Arnd Bergmann]

On Tuesday, November 22, 2016 9:40:39 AM CET Vladimir Murzin wrote:
> On 22/11/16 09:31, Arnd Bergmann wrote:
> > On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
> >> This driver uses functionality which available for MMU build only,
> >> thus add dependency on MMU.
> >>
> >> Cc: Thierry Reding <thierry.reding@gmail.com>
> >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> >>
> > 
> > Can you be more specific about what requires the MMU here?
> > 
> > Is it the I/O space remapping or something else?
> 
> Yes it comes from I/O space remapping.
> 
> The fill error log:
> 
>   CC      drivers/pci/host/pci-tegra.o
> In file included from ./arch/arm/include/asm/page.h:22:0,
>                  from ./arch/arm/include/asm/thread_info.h:17,
>                  from ./include/linux/thread_info.h:58,
>                  from ./include/asm-generic/current.h:4,
>                  from ./arch/arm/include/generated/asm/current.h:1,
>                  from ./include/linux/mutex.h:13,
>                  from ./include/linux/notifier.h:13,
>                  from ./include/linux/clk.h:17,
>                  from drivers/pci/host/pci-tegra.c:29:
> drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
> drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
>   pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |


That is not the I/O space, that is the config space.

Not sure what a better alternative would be, but the manual selection
of page flags makes the driver non-portable and dependent on architecture
specifics that it really shouldn't have to worry about.

In common PCI code, we use pgprot_device(PAGE_KERNEL)) at some point,
and that sounds like the right thing to do, but ARM doesn't provide
an override for it and the fallback is pgprot_noncached(), which is
probably wrong here.

Unless someone has a good idea for how to change the driver, just
mention this in the changelog.

	Arnd

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Vladimir Murzin]

On 22/11/16 09:54, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:40:39 AM CET Vladimir Murzin wrote:
>> On 22/11/16 09:31, Arnd Bergmann wrote:
>>> On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
>>>> This driver uses functionality which available for MMU build only,
>>>> thus add dependency on MMU.
>>>>
>>>> Cc: Thierry Reding <thierry.reding@gmail.com>
>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>>
>>>
>>> Can you be more specific about what requires the MMU here?
>>>
>>> Is it the I/O space remapping or something else?
>>
>> Yes it comes from I/O space remapping.
>>
>> The fill error log:
>>
>>   CC      drivers/pci/host/pci-tegra.o
>> In file included from ./arch/arm/include/asm/page.h:22:0,
>>                  from ./arch/arm/include/asm/thread_info.h:17,
>>                  from ./include/linux/thread_info.h:58,
>>                  from ./include/asm-generic/current.h:4,
>>                  from ./arch/arm/include/generated/asm/current.h:1,
>>                  from ./include/linux/mutex.h:13,
>>                  from ./include/linux/notifier.h:13,
>>                  from ./include/linux/clk.h:17,
>>                  from drivers/pci/host/pci-tegra.c:29:
>> drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
>> drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
>>   pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> 
> 
> That is not the I/O space, that is the config space.

Sorry for that, I'm not in PCI :(

> 
> Not sure what a better alternative would be, but the manual selection
> of page flags makes the driver non-portable and dependent on architecture
> specifics that it really shouldn't have to worry about.
> 
> In common PCI code, we use pgprot_device(PAGE_KERNEL)) at some point,
> and that sounds like the right thing to do, but ARM doesn't provide
> an override for it and the fallback is pgprot_noncached(), which is
> probably wrong here.
> 
> Unless someone has a good idea for how to change the driver, just
> mention this in the changelog.

Thanks for explanation! I'll wait for Thierry's thoughts on this. 

Cheers
Vladimir 

> 
> 	Arnd
> 

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Thierry Reding]

On Tue, Nov 22, 2016 at 10:54:01AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:40:39 AM CET Vladimir Murzin wrote:
> > On 22/11/16 09:31, Arnd Bergmann wrote:
> > > On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
> > >> This driver uses functionality which available for MMU build only,
> > >> thus add dependency on MMU.
> > >>
> > >> Cc: Thierry Reding <thierry.reding@gmail.com>
> > >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> > >>
> > > 
> > > Can you be more specific about what requires the MMU here?
> > > 
> > > Is it the I/O space remapping or something else?
> > 
> > Yes it comes from I/O space remapping.
> > 
> > The fill error log:
> > 
> >   CC      drivers/pci/host/pci-tegra.o
> > In file included from ./arch/arm/include/asm/page.h:22:0,
> >                  from ./arch/arm/include/asm/thread_info.h:17,
> >                  from ./include/linux/thread_info.h:58,
> >                  from ./include/asm-generic/current.h:4,
> >                  from ./arch/arm/include/generated/asm/current.h:1,
> >                  from ./include/linux/mutex.h:13,
> >                  from ./include/linux/notifier.h:13,
> >                  from ./include/linux/clk.h:17,
> >                  from drivers/pci/host/pci-tegra.c:29:
> > drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
> > drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
> >   pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> 
> 
> That is not the I/O space, that is the config space.
> 
> Not sure what a better alternative would be, but the manual selection
> of page flags makes the driver non-portable and dependent on architecture
> specifics that it really shouldn't have to worry about.
> 
> In common PCI code, we use pgprot_device(PAGE_KERNEL)) at some point,
> and that sounds like the right thing to do, but ARM doesn't provide
> an override for it and the fallback is pgprot_noncached(), which is
> probably wrong here.

Actually I think pgprot_noncached() is correct. Very early on we used to
map this using ioremap() and I remember that working. I also just tested
the pci-tegra driver with pgprot_device(PAGE_KERNEL) instead of the ARM-
specific flags and it seems to work well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/220bb54b/attachment-0001.sig>

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Vladimir Murzin]

On 22/11/16 11:26, Thierry Reding wrote:
> On Tue, Nov 22, 2016 at 10:54:01AM +0100, Arnd Bergmann wrote:
>> On Tuesday, November 22, 2016 9:40:39 AM CET Vladimir Murzin wrote:
>>> On 22/11/16 09:31, Arnd Bergmann wrote:
>>>> On Tuesday, November 22, 2016 9:26:01 AM CET Vladimir Murzin wrote:
>>>>> This driver uses functionality which available for MMU build only,
>>>>> thus add dependency on MMU.
>>>>>
>>>>> Cc: Thierry Reding <thierry.reding@gmail.com>
>>>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>>>>
>>>>
>>>> Can you be more specific about what requires the MMU here?
>>>>
>>>> Is it the I/O space remapping or something else?
>>>
>>> Yes it comes from I/O space remapping.
>>>
>>> The fill error log:
>>>
>>>   CC      drivers/pci/host/pci-tegra.o
>>> In file included from ./arch/arm/include/asm/page.h:22:0,
>>>                  from ./arch/arm/include/asm/thread_info.h:17,
>>>                  from ./include/linux/thread_info.h:58,
>>>                  from ./include/asm-generic/current.h:4,
>>>                  from ./arch/arm/include/generated/asm/current.h:1,
>>>                  from ./include/linux/mutex.h:13,
>>>                  from ./include/linux/notifier.h:13,
>>>                  from ./include/linux/clk.h:17,
>>>                  from drivers/pci/host/pci-tegra.c:29:
>>> drivers/pci/host/pci-tegra.c: In function 'tegra_pcie_bus_alloc':
>>> drivers/pci/host/pci-tegra.c:388:27: error: 'L_PTE_PRESENT' undeclared (first use in this function)
>>>   pgprot_t prot = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
>>
>>
>> That is not the I/O space, that is the config space.
>>
>> Not sure what a better alternative would be, but the manual selection
>> of page flags makes the driver non-portable and dependent on architecture
>> specifics that it really shouldn't have to worry about.
>>
>> In common PCI code, we use pgprot_device(PAGE_KERNEL)) at some point,
>> and that sounds like the right thing to do, but ARM doesn't provide
>> an override for it and the fallback is pgprot_noncached(), which is
>> probably wrong here.
> 
> Actually I think pgprot_noncached() is correct. Very early on we used to
> map this using ioremap() and I remember that working. I also just tested
> the pci-tegra driver with pgprot_device(PAGE_KERNEL) instead of the ARM-
> specific flags and it seems to work well.
> 

I did try that, but tegra_pcie_bus_alloc() calls get_vm_area() so

drivers/built-in.o: In function `tegra_pcie_add_bus':
:(.text+0x7763c): undefined reference to `get_vm_area'
make: *** [vmlinux] Error 1

Cheers
Vladimir

> Thierry
> 

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Stephen Warren]

On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> This driver uses functionality which available for MMU build only,
> thus add dependency on MMU.

I'd expect ARCH_TEGRA to depend on MMU instead.

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Arnd Bergmann]

On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> > This driver uses functionality which available for MMU build only,
> > thus add dependency on MMU.
> 
> I'd expect ARCH_TEGRA to depend on MMU instead.
> 

Any particular reason for why we'd single out Tegra?

	Arnd

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Stephen Warren]

On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
>> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
>>> This driver uses functionality which available for MMU build only,
>>> thus add dependency on MMU.
>>
>> I'd expect ARCH_TEGRA to depend on MMU instead.
>>
>
> Any particular reason for why we'd single out Tegra?

 From the cover letter, it sounded like the point of the series was to 
all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't 
have an M-class core so I wouldn't expect it to be included in such a 
build. I'd expect the same fix that I suggested to apply to all 
non-M-class SoCs, rather than fixing up individual drivers to depend on 
!MMU.

[RFC PATCH 04/11] PCI: tegra: limit to MMU build only

[Arnd Bergmann]

On Tuesday, November 22, 2016 3:27:35 PM CET Stephen Warren wrote:
> On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> > On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
> >> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> >>> This driver uses functionality which available for MMU build only,
> >>> thus add dependency on MMU.
> >>
> >> I'd expect ARCH_TEGRA to depend on MMU instead.
> >>
> >
> > Any particular reason for why we'd single out Tegra?
> 
>  From the cover letter, it sounded like the point of the series was to 
> all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't 
> have an M-class core so I wouldn't expect it to be included in such a 
> build. I'd expect the same fix that I suggested to apply to all 
> non-M-class SoCs, rather than fixing up individual drivers to depend on 
> !MMU.

I think you misread that, the point is to get NOMMU support back for
machines other than ARMv7-M, the Cortex-M based machines already work
without this.

	Arnd

[RFC PATCH 05/11] ARM: move arm_heavy_mb to MMU/noMMU neutral place

[Vladimir Murzin]

So it can be referenced from both camps.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/mm/flush.c |   15 ---------------
 arch/arm/mm/iomap.c |   17 +++++++++++++++++
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 3cced84..0c73969 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -21,21 +21,6 @@
 
 #include "mm.h"
 
-#ifdef CONFIG_ARM_HEAVY_MB
-void (*soc_mb)(void);
-
-void arm_heavy_mb(void)
-{
-#ifdef CONFIG_OUTER_CACHE_SYNC
-	if (outer_cache.sync)
-		outer_cache.sync();
-#endif
-	if (soc_mb)
-		soc_mb();
-}
-EXPORT_SYMBOL(arm_heavy_mb);
-#endif
-
 #ifdef CONFIG_CPU_CACHE_VIPT
 
 static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
diff --git a/arch/arm/mm/iomap.c b/arch/arm/mm/iomap.c
index 4614208..1b601db 100644
--- a/arch/arm/mm/iomap.c
+++ b/arch/arm/mm/iomap.c
@@ -9,6 +9,8 @@
 #include <linux/ioport.h>
 #include <linux/io.h>
 
+#include <asm/outercache.h>
+
 unsigned long vga_base;
 EXPORT_SYMBOL(vga_base);
 
@@ -40,3 +42,18 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
 }
 EXPORT_SYMBOL(pci_iounmap);
 #endif
+
+#ifdef CONFIG_ARM_HEAVY_MB
+void (*soc_mb)(void);
+
+void arm_heavy_mb(void)
+{
+#ifdef CONFIG_OUTER_CACHE_SYNC
+	if (outer_cache.sync)
+		outer_cache.sync();
+#endif
+	if (soc_mb)
+		soc_mb();
+}
+EXPORT_SYMBOL(arm_heavy_mb);
+#endif
-- 
1.7.9.5

[RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP

[Vladimir Murzin]

It can be referenced in UP case as well.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/tlbflush.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index def9e57..d9a6e2e 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
 
 #endif
 
-#elif defined(CONFIG_SMP)	/* !CONFIG_MMU */
+#else /* !CONFIG_MMU */
 
 #ifndef __ASSEMBLY__
 
-- 
1.7.9.5

[RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP

[Russell King - ARM Linux]

On Tue, Nov 22, 2016 at 09:26:03AM +0000, Vladimir Murzin wrote:
> It can be referenced in UP case as well.

What's missing is an explanation of why you want this change.
Exposing the local_* stuff doesn't make sense for UP.

> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  arch/arm/include/asm/tlbflush.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
> index def9e57..d9a6e2e 100644
> --- a/arch/arm/include/asm/tlbflush.h
> +++ b/arch/arm/include/asm/tlbflush.h
> @@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>  
>  #endif
>  
> -#elif defined(CONFIG_SMP)	/* !CONFIG_MMU */
> +#else /* !CONFIG_MMU */
>  
>  #ifndef __ASSEMBLY__
>  
> -- 
> 1.7.9.5
> 

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

[RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP

[Vladimir Murzin]

On 22/11/16 10:03, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 09:26:03AM +0000, Vladimir Murzin wrote:
>> It can be referenced in UP case as well.
> 
> What's missing is an explanation of why you want this change.
> Exposing the local_* stuff doesn't make sense for UP.

It comes from:

arch/arm/mach-mvebu/pmsu.c: In function 'armada_370_xp_pmsu_idle_enter':
arch/arm/mach-mvebu/pmsu.c:291:2: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
  local_flush_tlb_all();
  ^

make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1

and

arch/arm/mach-imx/pm-imx5.c: In function 'mx5_suspend_enter':
arch/arm/mach-imx/pm-imx5.c:227:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]

   local_flush_tlb_all();
   ^
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-imx/pm-imx5.o] Error 1

Maybe there are other users, please, let me know if you want me to count them
all.

Cheers
Vladimir

> 
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>>  arch/arm/include/asm/tlbflush.h |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
>> index def9e57..d9a6e2e 100644
>> --- a/arch/arm/include/asm/tlbflush.h
>> +++ b/arch/arm/include/asm/tlbflush.h
>> @@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>>  
>>  #endif
>>  
>> -#elif defined(CONFIG_SMP)	/* !CONFIG_MMU */
>> +#else /* !CONFIG_MMU */
>>  
>>  #ifndef __ASSEMBLY__
>>  
>> -- 
>> 1.7.9.5
>>
> 

[RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP

[Vladimir Murzin]

On 22/11/16 13:36, Vladimir Murzin wrote:
> On 22/11/16 10:03, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 09:26:03AM +0000, Vladimir Murzin wrote:
>>> It can be referenced in UP case as well.
>>
>> What's missing is an explanation of why you want this change.
>> Exposing the local_* stuff doesn't make sense for UP.
> 
> It comes from:
> 
> arch/arm/mach-mvebu/pmsu.c: In function 'armada_370_xp_pmsu_idle_enter':
> arch/arm/mach-mvebu/pmsu.c:291:2: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
>   local_flush_tlb_all();
>   ^
> 
> make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1
> 
> and
> 
> arch/arm/mach-imx/pm-imx5.c: In function 'mx5_suspend_enter':
> arch/arm/mach-imx/pm-imx5.c:227:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
> 
>    local_flush_tlb_all();
>    ^
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm/mach-imx/pm-imx5.o] Error 1
> 
> Maybe there are other users, please, let me know if you want me to count them
> all.

Russell, is it a good argument to expose the local_* stuff or it should be
addressed differently?

Thanks
Vladimir

> 
> Cheers
> Vladimir
> 
>>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>> ---
>>>  arch/arm/include/asm/tlbflush.h |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
>>> index def9e57..d9a6e2e 100644
>>> --- a/arch/arm/include/asm/tlbflush.h
>>> +++ b/arch/arm/include/asm/tlbflush.h
>>> @@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>>>  
>>>  #endif
>>>  
>>> -#elif defined(CONFIG_SMP)	/* !CONFIG_MMU */
>>> +#else /* !CONFIG_MMU */
>>>  
>>>  #ifndef __ASSEMBLY__
>>>  
>>> -- 
>>> 1.7.9.5
>>>
>>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[RFC PATCH 07/11] ARM: sleep: allow it to be build for R-class

[Vladimir Murzin]

Dependency on MMU is quite strict and prevent R-class from being built -
relax this condition and guard against M-class only

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/Kconfig        |    2 +-
 arch/arm/kernel/sleep.S |    4 ----
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49e0f01..f9ff570 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2179,7 +2179,7 @@ config ARCH_SUSPEND_POSSIBLE
 	def_bool y
 
 config ARM_CPU_SUSPEND
-	def_bool PM_SLEEP || BL_SWITCHER || ARM_PSCI_FW
+	def_bool (PM_SLEEP || BL_SWITCHER || ARM_PSCI_FW) && !CPU_V7M
 	depends on ARCH_SUSPEND_POSSIBLE
 
 config ARCH_HIBERNATION_POSSIBLE
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 0f6c100..0e7fddf 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -119,14 +119,12 @@ ENDPROC(cpu_resume_after_mmu)
 	.text
 	.align
 
-#ifdef CONFIG_MMU
 	.arm
 ENTRY(cpu_resume_arm)
  THUMB(	badr	r9, 1f		)	@ Kernel is entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
-#endif
 
 ENTRY(cpu_resume)
 ARM_BE8(setend be)			@ ensure we are in BE mode
@@ -160,9 +158,7 @@ THUMB(	mov	sp, r2			)
 THUMB(	bx	r3			)
 ENDPROC(cpu_resume)
 
-#ifdef CONFIG_MMU
 ENDPROC(cpu_resume_arm)
-#endif
 
 	.align 2
 _sleep_save_sp:
-- 
1.7.9.5

[RFC PATCH 08/11] ARM: NOMMU: define debug_ll_io_ini

[Vladimir Murzin]

We do not need to do anything in debug_ll_io_init in case of NOMMU.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/mach/map.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..6b86b9c 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,8 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
 #else
 #define iotable_init(map,num)	do { } while (0)
 #define vm_reserve_area_early(a,s,c)	do { } while (0)
+#define debug_ll_io_init() do { } while (0)
+
 #endif
 
 #endif
-- 
1.7.9.5

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Vladimir Murzin]

Pickup defines from pgtable-2level.h to make NOMMU build happy.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/pgtable-nommu.h |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/pgtable-nommu.h b/arch/arm/include/asm/pgtable-nommu.h
index add094d..9115801 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++ b/arch/arm/include/asm/pgtable-nommu.h
@@ -35,6 +35,11 @@
 
 #define PGDIR_SIZE		(1UL << PGDIR_SHIFT)
 #define PGDIR_MASK		(~(PGDIR_SIZE-1))
+
+#define SECTION_SHIFT           20
+#define SECTION_SIZE            (1UL << SECTION_SHIFT)
+#define SECTION_MASK            (~(SECTION_SIZE-1))
+
 /* FIXME */
 
 #define PAGE_NONE	__pgprot(0)
-- 
1.7.9.5

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Russell King - ARM Linux]

On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
> Pickup defines from pgtable-2level.h to make NOMMU build happy.

This needs more detail.

> 
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  arch/arm/include/asm/pgtable-nommu.h |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/include/asm/pgtable-nommu.h b/arch/arm/include/asm/pgtable-nommu.h
> index add094d..9115801 100644
> --- a/arch/arm/include/asm/pgtable-nommu.h
> +++ b/arch/arm/include/asm/pgtable-nommu.h
> @@ -35,6 +35,11 @@
>  
>  #define PGDIR_SIZE		(1UL << PGDIR_SHIFT)
>  #define PGDIR_MASK		(~(PGDIR_SIZE-1))
> +
> +#define SECTION_SHIFT           20
> +#define SECTION_SIZE            (1UL << SECTION_SHIFT)
> +#define SECTION_MASK            (~(SECTION_SIZE-1))
> +
>  /* FIXME */
>  
>  #define PAGE_NONE	__pgprot(0)
> -- 
> 1.7.9.5
> 

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

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Vladimir Murzin]

On 22/11/16 10:07, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
> 
> This needs more detail.
> 

It comes from

  CC      arch/arm/kernel/setup.o
arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
             crash_size, SECTION_SIZE);
                         ^
arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [arch/arm/kernel/setup.o] Error 1
make: *** [arch/arm/kernel] Error 2

Cheers
Vladimir

>>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>>  arch/arm/include/asm/pgtable-nommu.h |    5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/pgtable-nommu.h b/arch/arm/include/asm/pgtable-nommu.h
>> index add094d..9115801 100644
>> --- a/arch/arm/include/asm/pgtable-nommu.h
>> +++ b/arch/arm/include/asm/pgtable-nommu.h
>> @@ -35,6 +35,11 @@
>>  
>>  #define PGDIR_SIZE		(1UL << PGDIR_SHIFT)
>>  #define PGDIR_MASK		(~(PGDIR_SIZE-1))
>> +
>> +#define SECTION_SHIFT           20
>> +#define SECTION_SIZE            (1UL << SECTION_SHIFT)
>> +#define SECTION_MASK            (~(SECTION_SIZE-1))
>> +
>>  /* FIXME */
>>  
>>  #define PAGE_NONE	__pgprot(0)
>> -- 
>> 1.7.9.5
>>
> 

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Russell King - ARM Linux]

On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
> On 22/11/16 10:07, Russell King - ARM Linux wrote:
> > On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
> >> Pickup defines from pgtable-2level.h to make NOMMU build happy.
> > 
> > This needs more detail.
> > 
> 
> It comes from
> 
>   CC      arch/arm/kernel/setup.o
> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>              crash_size, SECTION_SIZE);
>                          ^
> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
> make[1]: *** [arch/arm/kernel/setup.o] Error 1
> make: *** [arch/arm/kernel] Error 2

Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
break anyone's existing setup unnecessarily, however arguably it
should be CRASH_ALIGN to ensure that the new kernel is properly
positioned.

I wonder if we can get away with changing that, rather than
unnecessarily introducing these otherwise meaningless definitions
for R-class.

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

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Vladimir Murzin]

On 22/11/16 11:54, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
>> On 22/11/16 10:07, Russell King - ARM Linux wrote:
>>> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>>>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>>>
>>> This needs more detail.
>>>
>>
>> It comes from
>>
>>   CC      arch/arm/kernel/setup.o
>> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
>> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>>              crash_size, SECTION_SIZE);
>>                          ^
>> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
>> make[1]: *** [arch/arm/kernel/setup.o] Error 1
>> make: *** [arch/arm/kernel] Error 2
> 
> Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
> break anyone's existing setup unnecessarily, however arguably it
> should be CRASH_ALIGN to ensure that the new kernel is properly
> positioned.
> 
> I wonder if we can get away with changing that, rather than
> unnecessarily introducing these otherwise meaningless definitions
> for R-class.
> 

CRASH_ALIGN works fine but it seems not only user of SECTION_SIZE

In file included from ./include/linux/cache.h:4:0,
                 from ./include/linux/printk.h:8,
                 from ./include/linux/kernel.h:13,
                 from arch/arm/mach-omap2/omap-secure.c:15:
arch/arm/mach-omap2/omap-secure.c: In function 'omap_secure_ram_reserve_memblock':
arch/arm/mach-omap2/omap-secure.c:65:21: error: 'SECTION_SIZE' undeclared (first use in this function)
  size = ALIGN(size, SECTION_SIZE);
                     ^
./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
 #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
                                               ^
./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
 #define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
                      ^
arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
  size = ALIGN(size, SECTION_SIZE);
         ^
arch/arm/mach-omap2/omap-secure.c:65:21: note: each undeclared identifier is reported only once for each function it appears in
  size = ALIGN(size, SECTION_SIZE);
                     ^
./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
 #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
                                               ^
./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
 #define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
                      ^
arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
  size = ALIGN(size, SECTION_SIZE);
         ^
make[1]: *** [arch/arm/mach-omap2/omap-secure.o] Error 1

Cheers
Vladimir

[RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros

[Vladimir Murzin]

On 22/11/16 17:03, Vladimir Murzin wrote:
> On 22/11/16 11:54, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
>>> On 22/11/16 10:07, Russell King - ARM Linux wrote:
>>>> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>>>>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>>>>
>>>> This needs more detail.
>>>>
>>>
>>> It comes from
>>>
>>>   CC      arch/arm/kernel/setup.o
>>> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
>>> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>>>              crash_size, SECTION_SIZE);
>>>                          ^
>>> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
>>> make[1]: *** [arch/arm/kernel/setup.o] Error 1
>>> make: *** [arch/arm/kernel] Error 2
>>
>> Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
>> break anyone's existing setup unnecessarily, however arguably it
>> should be CRASH_ALIGN to ensure that the new kernel is properly
>> positioned.
>>
>> I wonder if we can get away with changing that, rather than
>> unnecessarily introducing these otherwise meaningless definitions
>> for R-class.
>>
> 
> CRASH_ALIGN works fine but it seems not only user of SECTION_SIZE
> 
> In file included from ./include/linux/cache.h:4:0,
>                  from ./include/linux/printk.h:8,
>                  from ./include/linux/kernel.h:13,
>                  from arch/arm/mach-omap2/omap-secure.c:15:
> arch/arm/mach-omap2/omap-secure.c: In function 'omap_secure_ram_reserve_memblock':
> arch/arm/mach-omap2/omap-secure.c:65:21: error: 'SECTION_SIZE' undeclared (first use in this function)
>   size = ALIGN(size, SECTION_SIZE);
>                      ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
>  #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
>                                                ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
>  #define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
>                       ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
>   size = ALIGN(size, SECTION_SIZE);
>          ^
> arch/arm/mach-omap2/omap-secure.c:65:21: note: each undeclared identifier is reported only once for each function it appears in
>   size = ALIGN(size, SECTION_SIZE);
>                      ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
>  #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
>                                                ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
>  #define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
>                       ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
>   size = ALIGN(size, SECTION_SIZE);
>          ^
> make[1]: *** [arch/arm/mach-omap2/omap-secure.o] Error 1

Russell, do you have further comment on this? I would try to address them in
the next version.

Thanks!
Vladimir

> 
> Cheers
> Vladimir
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[RFC PATCH 10/11] ARM: NOMMU: define __arm_ioremap_exec and pci_ioremap functions

[Vladimir Murzin]

Define __arm_ioremap_exec and pci_ioremap* functions fallowing pattern
for other ioremap functions.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/mm/nommu.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967..681cec8 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -19,6 +19,7 @@
 #include <asm/cputype.h>
 #include <asm/mpu.h>
 #include <asm/procinfo.h>
+#include <asm/mach/map.h>
 
 #include "mm.h"
 
@@ -401,3 +402,37 @@ void iounmap(volatile void __iomem *addr)
 {
 }
 EXPORT_SYMBOL(iounmap);
+
+void __iomem *
+__arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
+{
+	unsigned int mtype;
+
+	if (cached)
+		mtype = MT_MEMORY_RWX;
+	else
+		mtype = MT_MEMORY_RWX_NONCACHED;
+
+	return __arm_ioremap_caller(phys_addr, size, mtype,
+			__builtin_return_address(0));
+}
+
+#ifdef CONFIG_PCI
+static int pci_ioremap_mem_type = MT_DEVICE;
+
+void pci_ioremap_set_mem_type(int mem_type)
+{
+	pci_ioremap_mem_type = mem_type;
+}
+
+int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
+{
+	BUG_ON(offset + SZ_64K > IO_SPACE_LIMIT);
+
+	return ioremap_page_range(PCI_IO_VIRT_BASE + offset,
+				  PCI_IO_VIRT_BASE + offset + SZ_64K,
+				  phys_addr,
+				  MT_DEVICE);
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_io);
+#endif
-- 
1.7.9.5

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Vladimir Murzin]

With this patch applied potentially any platform can be built in NOMMU
configurations if CONFIG_EXPERT is selected. However, there is no
guaranty that platform can successfully run such Image. So the main
motivation behind of this patch:
- bring build coverage for NOMMU configurations
- allow known working NOMMU platforms (like R-class) to be used
- pave a way to add support for single address space (aka 1:1 mapping)
  for MMU platforms, so they can be usable in NOMMU configurations

Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9ff570..8e7496c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -327,9 +327,9 @@ choice
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
-	depends on MMU
+	depends on MMU || EXPERT
 	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if MMU
 	select AUTO_ZRELADDR
 	select CLKSRC_OF
 	select COMMON_CLK
-- 
1.7.9.5

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Arnd Bergmann]

On Tuesday, November 22, 2016 9:26:08 AM CET Vladimir Murzin wrote:
> With this patch applied potentially any platform can be built in NOMMU
> configurations if CONFIG_EXPERT is selected. However, there is no
> guaranty that platform can successfully run such Image. So the main
> motivation behind of this patch:
> - bring build coverage for NOMMU configurations
> - allow known working NOMMU platforms (like R-class) to be used
> - pave a way to add support for single address space (aka 1:1 mapping)
>   for MMU platforms, so they can be usable in NOMMU configurations
> 
> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Ryan Mallon <rmallon@gmail.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>

I'd have to give this a spin with my randconfig build setup, I'd
rather not introduce build regressions. Have you tried an
allmodconfig build with CONFIG_MMU disabled?

Can you provide a git tree that I can try pulling in?

Another question is what architecture levels and what platforms
we want to support without MMU. The only ARMv4/v5 platform we
still have that can actually use NOMMU cores is Integrator
with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly
others I couldn't immediately find). Do we actually care about
them any more now that all the NOMMU world is ARMv7-M? Are
there any benefits in running an ARM920T or ARM926E core
with MMU disabled, and does this work with your patches?

If not, we could limit it to ARMv7-A/R and possibly ARMv6.
Depending on how the build tests go, a per-platform opt-in
might be easier than having an opt-out for things that
don't work.

	Arnd

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Vladimir Murzin]

On 22/11/16 10:17, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:26:08 AM CET Vladimir Murzin wrote:
>> With this patch applied potentially any platform can be built in NOMMU
>> configurations if CONFIG_EXPERT is selected. However, there is no
>> guaranty that platform can successfully run such Image. So the main
>> motivation behind of this patch:
>> - bring build coverage for NOMMU configurations
>> - allow known working NOMMU platforms (like R-class) to be used
>> - pave a way to add support for single address space (aka 1:1 mapping)
>>   for MMU platforms, so they can be usable in NOMMU configurations
>>
>> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
>> Cc: Ryan Mallon <rmallon@gmail.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> 
> I'd have to give this a spin with my randconfig build setup, I'd
> rather not introduce build regressions. Have you tried an
> allmodconfig build with CONFIG_MMU disabled?

I used defconfigs and just got results for allmodconfig apart of complain on
isb instruction in arch/arm/kernel/head-nommu.S [1] there are several link
time errors [2].

> 
> Can you provide a git tree that I can try pulling in?
> 

Unfortunately, I can't provide you with git tree at the moment I'll try to
do something around this before proposing the next version.

> Another question is what architecture levels and what platforms
> we want to support without MMU. The only ARMv4/v5 platform we
> still have that can actually use NOMMU cores is Integrator
> with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly
> others I couldn't immediately find). Do we actually care about
> them any more now that all the NOMMU world is ARMv7-M? Are
> there any benefits in running an ARM920T or ARM926E core
> with MMU disabled, and does this work with your patches?
> 

I don't have such hardware, so I can't acctually test it - it is why "there is
no guaranty" :( OTOH, if sombody has these platforms these pathces is a good
start to try NOMMU.

> If not, we could limit it to ARMv7-A/R and possibly ARMv6.
> Depending on how the build tests go, a per-platform opt-in
> might be easier than having an opt-out for things that
> don't work.
> 
> 	Arnd
> 

[1]
  AS      arch/arm/kernel/head-nommu.o
arch/arm/kernel/head-nommu.S: Assembler messages:
arch/arm/kernel/head-nommu.S:223: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:231: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:235: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:244: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:248: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:258: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:265: Error: selected processor does not support ARM mode `isb'
make[1]: *** [arch/arm/kernel/head-nommu.o] Error 1

[2]
arch/arm/kernel/head-nommu.o: In function `secondary_startup':
(.text+0x1c): undefined reference to `__setup_mpu'
arch/arm/kernel/head-nommu.o: In function `stext':
(.head.text+0x30): undefined reference to `__setup_mpu'
arch/arm/kernel/built-in.o: In function `setup_arch':
arch/arm/kernel/smccc-call.o:(.init.text+0xa50): undefined reference to `erratum_a15_798181_init'
kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0xd3d9c): undefined reference to `arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0xd4338): undefined reference to `arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_control_pages':
memremap.c:(.text+0xd4ac8): undefined reference to `arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_load_segment':
memremap.c:(.text+0xd4f40): undefined reference to `arch_phys_to_idmap_offset'
kernel/built-in.o: In function `crash_free_reserved_phys_range':
memremap.c:(.text+0xd50bc): undefined reference to `arch_phys_to_idmap_offset'
arch/arm/mach-mediatek/built-in.o: In function `__mtk_smp_prepare_cpus':
mediatek.c:(.init.text+0xe8): undefined reference to `secondary_startup_arm'
arch/arm/mach-qcom/built-in.o: In function `qcom_smp_prepare_cpus':
platsmp.c:(.init.text+0xe8): undefined reference to `secondary_startup_arm'
mm/built-in.o: In function `do_mmu_notifier_register':
usercopy.c:(.text+0x34d10): undefined reference to `mm_take_all_locks'
usercopy.c:(.text+0x34d9c): undefined reference to `mm_drop_all_locks'
usercopy.c:(.text+0x34de4): undefined reference to `mm_take_all_locks'
make: *** [vmlinux] Error 1

Cheers
Vladimir

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Afzal Mohammed]

Hi,

On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:

> I used defconfigs

Which defconfig was used ?

multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,

kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0x4dafc): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4db04): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0x4dbc0): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dbc8): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dc1c): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
references to `arch_phys_to_idmap_offset' follow

multi_v7_defconfig & MMU disabled, stderr was more verbose and was
unhappy with Kconfig dependencies,

warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)

Ulterior motive here is to try !MMU on Cortex A

Regards
afzal

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Vladimir Murzin]

On 23/11/16 15:48, Afzal Mohammed wrote:
> Hi,
> 
> On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
> 
>> I used defconfigs
> 
> Which defconfig was used ?
> 

I had a script to traverse config directory, but seems that I messed
things up.

Now I'm running allmodconfig per Arnd suggestion.

> multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
> 
> kernel/built-in.o: In function `kimage_free_entry':
> memremap.c:(.text+0x4dafc): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4db04): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o: In function `kimage_alloc_page':
> memremap.c:(.text+0x4dbc0): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dbc8): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dc1c): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
> references to `arch_phys_to_idmap_offset' follow

I think this one is fixed by

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8e7496c..c3349b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
 config KEXEC
        bool "Kexec system call (EXPERIMENTAL)"
        depends on (!SMP || PM_SLEEP_SMP)
-       depends on !CPU_V7M
+       depends on MMU
        select KEXEC_CORE
        help
          kexec is a system call that implements the ability to shutdown your

but there are others I'm working on.

> 
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,
> 
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)

These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")

> 
> Ulterior motive here is to try !MMU on Cortex A
> 

Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
and DRAM_SIZE ;)

> Regards
> afzal
> 

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Afzal Mohammed]

Hi,

On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:

> I think this one is fixed by
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8e7496c..c3349b9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
>  config KEXEC
>         bool "Kexec system call (EXPERIMENTAL)"
>         depends on (!SMP || PM_SLEEP_SMP)
> -       depends on !CPU_V7M
> +       depends on MMU

> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")

> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
> and DRAM_SIZE ;)

Thanks for the info.

Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
disabled.

Trying to get something in the console on Cortex A platform.

Regards
afzal

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Vladimir Murzin]

On 24/11/16 17:28, Afzal Mohammed wrote:
> Hi,
> 
> On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:
> 
>> I think this one is fixed by
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 8e7496c..c3349b9 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
>>  config KEXEC
>>         bool "Kexec system call (EXPERIMENTAL)"
>>         depends on (!SMP || PM_SLEEP_SMP)
>> -       depends on !CPU_V7M
>> +       depends on MMU
> 
>> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
> 
>> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
>> and DRAM_SIZE ;)
> 
> Thanks for the info.
> 
> Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
> disabled.
> 
> Trying to get something in the console on Cortex A platform.

Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
proper patch for that here).

Cheers
Vladimir

> 
> Regards
> afzal
> 

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Afzal Mohammed]

Hi,

On Thu, Nov 24, 2016 at 05:33:33PM +0000, Vladimir Murzin wrote:

> Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
> proper patch for that here).

Hmm.., thanks, that is enabled here, will disable it & proceed.

Regards
afzal

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Russell King - ARM Linux]

On Wed, Nov 23, 2016 at 09:18:29PM +0530, Afzal Mohammed wrote:
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,

Well, !MMU and multiplatform _are_ exclusive in reality.  One of the
things we work around in multiplatform is the different physical
address space layouts of the platforms, particularly with where RAM
is located.  That's not possible in !MMU configurations.  A kernel
built to support every platform in multiplatform will not boot on
most of them.

So efforts to make !MMU work with multiplatform are IMHO rather
misguided.

!MMU makes sense with classifications of systems (like the Cortex-M*
based systems) but not everything.

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

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Afzal Mohammed]

Hi,

On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:

> Well, !MMU and multiplatform _are_ exclusive in reality.  One of the
> things we work around in multiplatform is the different physical
> address space layouts of the platforms, particularly with where RAM
> is located.  That's not possible in !MMU configurations.  A kernel
> built to support every platform in multiplatform will not boot on
> most of them.
> 
> So efforts to make !MMU work with multiplatform are IMHO rather
> misguided.
> 
> !MMU makes sense with classifications of systems (like the Cortex-M*
> based systems) but not everything.

Okay, seems you were referring to AUTO_ZRELADDR or if you had
something else in mind, please let me know.

The plan was to use Image instead of zImage. Here there are 2
platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
(vf610) and TI's Sitara siblings (am335x beagle & am437x). It was
thought that though changes might have to be made b/n them, at least
it might be easier using same defconfig, thus went by multi_v7.

Though have been able to build for !MMU, have not yet been successful
in seeing any activity on the console, probably will have to put
printascii() into service.

Regards
afzal

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Russell King - ARM Linux]

On Thu, Nov 24, 2016 at 10:55:35PM +0530, Afzal Mohammed wrote:
> Hi,
> 
> On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:
> 
> > Well, !MMU and multiplatform _are_ exclusive in reality.  One of the
> > things we work around in multiplatform is the different physical
> > address space layouts of the platforms, particularly with where RAM
> > is located.  That's not possible in !MMU configurations.  A kernel
> > built to support every platform in multiplatform will not boot on
> > most of them.
> > 
> > So efforts to make !MMU work with multiplatform are IMHO rather
> > misguided.
> > 
> > !MMU makes sense with classifications of systems (like the Cortex-M*
> > based systems) but not everything.
> 
> Okay, seems you were referring to AUTO_ZRELADDR or if you had
> something else in mind, please let me know.

No, I'm talking about the kernel proper itself.

> The plan was to use Image instead of zImage. Here there are 2
> platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
> (vf610) and TI's Sitara siblings (am335x beagle & am437x).

Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
to be the appropriate size of RAM.

You'll be able to run the same "Image" kernel on the other platforms
_if_ and _only_ _if_ they have RAM covering the same region.

That's my point - the kernel image will be linked to place its
read-write data at a certain location in the address space, and if
you have the MMU disabled (or in 1:1 translation mode) you _must_
have RAM at that location.

The reason multiplatform works is because we use the MMU to abstract
away the differences in the location of RAM on the platform (amongst
other things.)

Also note that Cortex-A class CPUs don't perform well with the MMU
off, because you can't enable the data cache - and you must have the
data cache enabled for SMP to be functional, and it's also required
for exclusives to work.

There's also some cases where "Device, non-shared" must be used to
access some devices, which can only be done with the MMU enabled.

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

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Afzal Mohammed]

Hi,

On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:

> Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> to be the appropriate size of RAM.

Hmm.., i had thought that Vybrid's memory mappings starts from
0x80000000 (same TI Sitara's), just rechecked the older boot logs of
Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
different map.

> Also note that Cortex-A class CPUs don't perform well with the MMU
> off, because you can't enable the data cache - and you must have the
> data cache enabled for SMP to be functional, and it's also required
> for exclusives to work.

Yes, was aware of the performance degradation due to disabled dcache.

Here the platforms at my disposal are all single core - vf610, am335x
& am437x (though strictly speaking 2 of them are ARM SMP
configurations, but with number of cores as 1). Seems at least from
SMP pov, not expecting issues as they are single core (SMP disabled
kernel with MMU enabled works on those)

> There's also some cases where "Device, non-shared" must be used to
> access some devices, which can only be done with the MMU enabled.

Thanks for your valuable feedbacks.

Regards
afzal

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Russell King - ARM Linux]

On Thu, Nov 24, 2016 at 11:37:51PM +0530, Afzal Mohammed wrote:
> Hi,
> 
> On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:
> 
> > Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> > for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> > to be the appropriate size of RAM.
> 
> Hmm.., i had thought that Vybrid's memory mappings starts from
> 0x80000000 (same TI Sitara's), just rechecked the older boot logs of
> Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
> different map.

Right, so if you build a multiplatform kernel which covers TI Sitara
and iMX6, then you have a choice:

- Set DRAM_START to 0x10000000, and have a kernel which will boot on
  iMX6 but fail on TI Sitara.
- Set DRAM_START to 0x80000000, and have a kernel which will boot on
  TI Sitara, but fail on iMX6 with less than 2GiB of memory (0x70000000
  bytes to be exact.)

This is why multiplatform doesn't make sense for noMMU - you can't
actually build a multiplatform kernel that will work across all
these platforms.

You'd have to re-link it (at the very least) to place the data section
elsewhere in physical memory to make it work.

It's this reason that I don't like removing the "depends on MMU" from
multiplatform - it gives the incorrect impression that we _can_ support
a wide range of systems, but what it will lead to is a kernel that will
work on some platforms but not others.  The result will be more "bug"
reports because the kernel fails to boot...

In any case, I think kernelci and similar would first need to be updated
to avoid trying to boot noMMU kernels on hardware which it just can't
boot on - we _really_ do not want to be randomly scribbling into physical
memory, potentially hitting devices, especially with devices that contain
OTP fuses that set options as security features.

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

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Vladimir Murzin]

On 24/11/16 18:45, Russell King - ARM Linux wrote:
> It's this reason that I don't like removing the "depends on MMU" from
> multiplatform - it gives the incorrect impression that we _can_ support
> a wide range of systems, but what it will lead to is a kernel that will
> work on some platforms but not others.  The result will be more "bug"
> reports because the kernel fails to boot...

Do you think extra guarding with CONFIG_EXPERIMENTAL would be appropriate to
reduce number of such reports?

Cheers
Vladimir

[RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU

[Tony Lindgren]

* Vladimir Murzin <vladimir.murzin@arm.com> [161122 08:57]:
> On 22/11/16 10:17, Arnd Bergmann wrote:
> > Another question is what architecture levels and what platforms
> > we want to support without MMU. The only ARMv4/v5 platform we
> > still have that can actually use NOMMU cores is Integrator
> > with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly
> > others I couldn't immediately find). Do we actually care about
> > them any more now that all the NOMMU world is ARMv7-M? Are
> > there any benefits in running an ARM920T or ARM926E core
> > with MMU disabled, and does this work with your patches?
> > 
> 
> I don't have such hardware, so I can't acctually test it - it is why "there is
> no guaranty" :( OTOH, if sombody has these platforms these pathces is a good
> start to try NOMMU.

I believe the reason to run them without MMU might be still
valid if we ever get mainline Linux kernel working on some
3G/LTE modems for latency reasons. Not that I know of any
use cases, but if we have it working we might as well keep
it working.

Regards,

Tony