Allow NOMMU for MULTIPLATFORM

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 <[email protected]>

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

---
 arch/arm/include/asm/fixmap.h |    6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/include/asm/fixmap.h +6 -0

index 5c17d2d..0bfc2e3 100644
@@ -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

Signature · 1 line

1.7.9.5

Quoted 15 lines · 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

Quoted 4 lines

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

Cc Russell King <[email protected]>

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

Quoted 26 lines

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

---
 arch/arm/include/asm/fixmap.h |    6 ++++++
 1 file changed, 6 insertions(+)

arch/arm/include/asm/fixmap.h +6 -0

index 5c17d2d..0bfc2e3 100644
@@ -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

Signature · 1 line

1.7.9.5

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.

Quoted 4 lines · 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.

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.

Quoted 13 lines · Russell King - ARM Linux

Quoted 4 lines · 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.

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.

Quoted 2 lines

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 <[email protected]>

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

Cc Thierry Reding <[email protected]>

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

Quoted 6 lines · CET Vladimir Murzin

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

Cc Thierry Reding <[email protected]>

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

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

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

Arnd

Quoted 11 lines · Arnd Bergmann

Quoted 6 lines · CET Vladimir Murzin

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

Cc Thierry Reding <[email protected]>

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

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 |

Quoted 27 lines · CET Vladimir Murzin

Quoted 11 lines · Arnd Bergmann

Quoted 6 lines · CET Vladimir Murzin

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

Cc Thierry Reding <[email protected]>

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

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:

Quoted 3 lines

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

Quoted 27 lines · CET Vladimir Murzin

Quoted 11 lines · Arnd Bergmann

Quoted 6 lines · CET Vladimir Murzin

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

Cc Thierry Reding <[email protected]>

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

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:

Quoted 3 lines

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.

Quoted 35 lines · Arnd Bergmann

Quoted 27 lines · CET Vladimir Murzin

Quoted 11 lines · Arnd Bergmann

Quoted 6 lines · CET Vladimir Murzin

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

Cc Thierry Reding <[email protected]>

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

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:

Quoted 3 lines

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.

Quoted 8 lines

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

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

Quoted 2 lines · Vladimir Murzin

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.

Quoted 6 lines · CET Stephen Warren

Quoted 2 lines · Vladimir Murzin

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?

Quoted 8 lines · Arnd Bergmann

Quoted 6 lines · CET Stephen Warren

Quoted 2 lines · Vladimir Murzin

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.

Quoted 1 line

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.

It can be referenced in UP case as well.

Cc Russell King <[email protected]>

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

---
 arch/arm/include/asm/tlbflush.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/include/asm/tlbflush.h +1 -1

index def9e57..d9a6e2e 100644
@@ -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__
 

Signature · 1 line

1.7.9.5

Quoted 1 line · Vladimir Murzin

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.

Quoted 23 lines

Cc Russell King <[email protected]>

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

---
 arch/arm/include/asm/tlbflush.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/include/asm/tlbflush.h +1 -1

index def9e57..d9a6e2e 100644
@@ -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__
 

Signature · 1 line

1.7.9.5

Quoted 5 lines · Russell King - ARM Linux

Quoted 1 line · Vladimir Murzin

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

Quoted 15 lines

Quoted 15 lines

Cc Russell King <[email protected]>

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

---
 arch/arm/include/asm/tlbflush.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/include/asm/tlbflush.h +0 -0

index def9e57..d9a6e2e 100644
@@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
 
 #endif
 

Quoted 9 lines

Quoted 8 lines

arch/arm/include/asm/tlbflush.h +1 -1

-#elif defined(CONFIG_SMP)	/* !CONFIG_MMU */
+#else /* !CONFIG_MMU */
 
 #ifndef __ASSEMBLY__
 

Signature · 1 line

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

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

Cc Russell King <[email protected]>

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

---
 arch/arm/include/asm/pgtable-nommu.h |    5 +++++
 1 file changed, 5 insertions(+)

arch/arm/include/asm/pgtable-nommu.h +5 -0

index add094d..9115801 100644
@@ -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)

Signature · 1 line

1.7.9.5

Quoted 1 line · Vladimir Murzin

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

This needs more detail.

Quoted 26 lines

Cc Russell King <[email protected]>

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

---
 arch/arm/include/asm/pgtable-nommu.h |    5 +++++
 1 file changed, 5 insertions(+)

arch/arm/include/asm/pgtable-nommu.h +5 -0

index add094d..9115801 100644
@@ -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)

Signature · 1 line

1.7.9.5

Quoted 5 lines · Russell King - ARM Linux

Quoted 1 line · Vladimir Murzin

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

Quoted 9 lines · Vladimir Murzin

Quoted 5 lines · Russell King - ARM Linux

Quoted 1 line · Vladimir Murzin

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

This needs more detail.

It comes from

Quoted 8 lines

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.

Quoted 19 lines · Russell King - ARM Linux

Quoted 9 lines · Vladimir Murzin

Quoted 5 lines · Russell King - ARM Linux

Quoted 1 line · Vladimir Murzin

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

This needs more detail.

It comes from

Quoted 8 lines

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

Quoted 9 lines

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

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

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 <[email protected]>

Cc Ryan Mallon <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Thierry Reding <[email protected]>

Cc Russell King <[email protected]>

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

Quoted 9 lines · CET 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

Quoted 6 lines

Cc Hartley Sweeten <[email protected]>

Cc Ryan Mallon <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Thierry Reding <[email protected]>

Cc Russell King <[email protected]>

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

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

I used defconfigs

Hi,

Quoted 1 line · Vladimir Murzin

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

I think this one is fixed by

arch/arm/Kconfig +1 -1

index 8e7496c..c3349b9 100644
@@ -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 ;)

Hi,

Quoted 15 lines · Vladimir Murzin

I think this one is fixed by

arch/arm/Kconfig +1 -1

index 8e7496c..c3349b9 100644
@@ -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")
 

Quoted 2 lines

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

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

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.

Hi,

Quoted 7 lines · Russell King - ARM Linux

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.

Quoted 5 lines

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

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.

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.

Hi,

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

Quoted 3 lines

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.

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

Quoted 9 lines · Arnd Bergmann

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.