[PATCHv4 0/4] arm/versatile: no-MMU support

[PATCHv4 0/4] arm/versatile: no-MMU support

[Greg Ungerer]

This is a rebased resend of the no-MMU patches to support the Versatile
platform. It incorporates changes suggested by Russell (don't use a
multiplatorm arrangement) and rebased onto 4.17.

The following patches support configuring and building the versatile
machine with a no-MMU kernel.

There is only a few minor changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.

One patch is a fix for address translation (broken in older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actual configuration changes needed.

The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled in qemu.

Russell: is this something you would take via your patch tracker?

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/arm/Kconfig                       |   11 +++++++++++
 arch/arm/Kconfig.debug                 |    3 ++-
 arch/arm/include/asm/mach/map.h        |    1 +
 arch/arm/mach-versatile/Kconfig        |    5 +++--
 arch/arm/mach-versatile/Makefile.boot  |    3 +++
 arch/arm/mach-versatile/versatile_dt.c |    4 ++++
 6 files changed, 24 insertions(+), 3 deletions(-)

[PATCHv4 1/4] ARM: versatile: support no-MMU mode addressing

[Greg Ungerer]

Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.

For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/arm/mach-versatile/versatile_dt.c | 4 ++++
 1 file changed, 4 insertions(+)

v2: no change
v3: rebase on top of linux-4.10
v4: rebase on top of linux-4.17

diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c12909..8cfa05a37295 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
 #include <asm/mach/map.h>
 
 /* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
 #define IO_ADDRESS(x)		(((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x)		(x)
+#endif
 #define __io_address(n)		((void __iomem __force *)IO_ADDRESS(n))
 
 /*
-- 
2.17.1

[PATCHv4 2/4] ARM: versatile: define empty debug_ll_io_init() for no-MMU

[Greg Ungerer]

No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.

But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:

  CC      arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
  debug_ll_io_init();
  ^

Fix by adding a macro for it to the !CONFIG_MMU path in map.h.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 arch/arm/include/asm/mach/map.h | 1 +
 1 file changed, 1 insertion(+)

v2: no change
v3: rebase on top of linux-4.10
v4: rebase in top of linux-4.17

diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328fb207..b1fe9c8b5c3e 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ 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
-- 
2.17.1

[PATCHv4 3/4] ARM: versatile: empty Makefile.boot needed for no-MMU compile

[Greg Ungerer]

To compile the arm versatile board with the MMU disabled (!CONFIG_MMU)
a Makefile.boot is required. Without it you get:

  SYSMAP  System.map
arch/arm/boot/Makefile:15: arch/arm/mach-versatile//Makefile.boot: No such file or directory
make[2]: *** No rule to make target `arch/arm/mach-versatile//Makefile.boot'.  Stop.

Create an empty Makefile.boot for the versatile machine. This is a
copy of the other empty machine Makefile.boot files. (A few have this
same commented empty file: stm32, ep93xx, lpc18xx, efm32 and vexpress).

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/arm/mach-versatile/Makefile.boot | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 arch/arm/mach-versatile/Makefile.boot

v2: no change
v3: rebase on top of linux-4.10
v3: rebase on top of linux-4.17

diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
new file mode 100644
index 000000000000..eacfc3f5c33e
--- /dev/null
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
-- 
2.17.1

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Greg Ungerer]

Allow the arm versatile machine to be configured for no-MMU operation.

Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).

The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.

This patch adds a versatile platform selection in the upper level arm
system type menu - where it appeared in older kernel versions - when
configuring for the no-MMU case. There is no visible change to the way
versatile is selected for the MMU enabled case.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/arm/Kconfig                | 11 +++++++++++
 arch/arm/Kconfig.debug          |  3 ++-
 arch/arm/mach-versatile/Kconfig |  5 +++--
 3 files changed, 16 insertions(+), 3 deletions(-)

v2: don't use a multiplatform setup, move versatile choice to top level menu
v3: rebase on top of linux-4.10
v3: rebase on top of linux-4.17

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..0608a6a32fac 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M
 	select SPARSE_IRQ
 	select USE_OF
 
+config ARM_SINGLE_ARCH_VERSATILE
+	bool "ARM Ltd. Versatile family"
+	depends on !MMU
+	select AUTO_ZRELADDR
+	select CLKSRC_OF
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select GPIOLIB
+	select SPARSE_IRQ
+	select USE_OF
+
 config ARCH_EBSA110
 	bool "EBSA-110"
 	select ARCH_USES_GETTIMEOFFSET
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 693f84392f1b..242a0f744c8a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS
 config UNCOMPRESS_INCLUDE
 	string
 	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
-					PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+					PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+					ARM_SINGLE_ARCH_VERSATILE
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index f5c275434d6c..06ad999d5978 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,7 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 config ARCH_VERSATILE
-	bool "ARM Ltd. Versatile family"
-	depends on ARCH_MULTI_V5
+	bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+	depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
+	default y if ARM_SINGLE_ARCH_VERSATILE
 	select ARM_AMBA
 	select ARM_TIMER_SP804
 	select ARM_VIC
-- 
2.17.1

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Greg,

CC Chris, Arnd, Nicolas

On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote:
> Allow the arm versatile machine to be configured for no-MMU operation.
>
> Older kernels had the ability to build the versatile machine with the MMU
> disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
> to device tree lost this ability. (Although older kernels could be built
> they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
>
> The motivation for this is that the versatile machine is well supported
> in qemu. And this provides an excellent platform for development and
> testing no-MMU support on ARM in general.
>
> This patch adds a versatile platform selection in the upper level arm
> system type menu - where it appeared in older kernel versions - when
> configuring for the no-MMU case. There is no visible change to the way
> versatile is selected for the MMU enabled case.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>

Thanks for your patch! I'm happy to see nommu spreading ;-)


> ---
>  arch/arm/Kconfig                | 11 +++++++++++
>  arch/arm/Kconfig.debug          |  3 ++-
>  arch/arm/mach-versatile/Kconfig |  5 +++--
>  3 files changed, 16 insertions(+), 3 deletions(-)
>
> v2: don't use a multiplatform setup, move versatile choice to top level menu
> v3: rebase on top of linux-4.10
> v3: rebase on top of linux-4.17
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 54eeb8d00bc6..0608a6a32fac 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M
>         select SPARSE_IRQ
>         select USE_OF
>
> +config ARM_SINGLE_ARCH_VERSATILE
> +       bool "ARM Ltd. Versatile family"
> +       depends on !MMU
> +       select AUTO_ZRELADDR
> +       select CLKSRC_OF
> +       select COMMON_CLK
> +       select GENERIC_CLOCKEVENTS
> +       select GPIOLIB
> +       select SPARSE_IRQ
> +       select USE_OF
> +

I'm afraid adding (duplicating) machine entries for nommu support is not a
sustainable solutions. Any machine can run a nommu kernel, in theory.

I'm aware of the objection "but you cannot build a nommu kernel that can
boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
same). So don't do that.

All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
One more reason not to have this duplication.

The current "ARM multiplatform" has actually two meanings:
  1. It groups platforms that follow the "ARM multiplatform" framework,
  2. It allows to build a single kernel that can be booted on multiple
     platforms.
To avoid the duplication, I think 2 should be relaxed when specialized
options like XIP or NOMMU are selected.

I've just sent a patch to do that.

>  config ARCH_EBSA110
>         bool "EBSA-110"
>         select ARCH_USES_GETTIMEOFFSET
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 693f84392f1b..242a0f744c8a 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS
>  config UNCOMPRESS_INCLUDE
>         string
>         default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
> -                                       PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
> +                                       PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
> +                                       ARM_SINGLE_ARCH_VERSATILE
>         default "mach/uncompress.h"
>
>  config EARLY_PRINTK
> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
> index f5c275434d6c..06ad999d5978 100644
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -1,7 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0
>  config ARCH_VERSATILE
> -       bool "ARM Ltd. Versatile family"
> -       depends on ARCH_MULTI_V5
> +       bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
> +       depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
> +       default y if ARM_SINGLE_ARCH_VERSATILE
>         select ARM_AMBA
>         select ARM_TIMER_SP804
>         select ARM_VIC

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

[ adding linux-kbuild for their input ]

On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:

> I'm afraid adding (duplicating) machine entries for nommu support is not a
> sustainable solutions. Any machine can run a nommu kernel, in theory.
> 
> I'm aware of the objection "but you cannot build a nommu kernel that can
> boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> same). So don't do that.
> 
> All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> One more reason not to have this duplication.
> 
> The current "ARM multiplatform" has actually two meanings:
>   1. It groups platforms that follow the "ARM multiplatform" framework,
>   2. It allows to build a single kernel that can be booted on multiple
>      platforms.
> To avoid the duplication, I think 2 should be relaxed when specialized
> options like XIP or NOMMU are selected.
> 
> I've just sent a patch to do that.

Your patch isn't wrong per se.  But it is not enough. The issue here 
would be easily fixed with some kconfig extension so that:

- If XIP or NOMMU is selected then only one target in the multiplatform 
  set can be selected, basically turning it into a choice menu.

- If more than one multiplatform targets is selected then XIP and NOMMU 
  can no longere be selected.

I don't know how this could be expressed but the implementation might 
not be that hard.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

[ adding linux-kbuild for their input ]

On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:

> I'm afraid adding (duplicating) machine entries for nommu support is not a
> sustainable solutions. Any machine can run a nommu kernel, in theory.
> 
> I'm aware of the objection "but you cannot build a nommu kernel that can
> boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> same). So don't do that.
> 
> All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> One more reason not to have this duplication.
> 
> The current "ARM multiplatform" has actually two meanings:
>   1. It groups platforms that follow the "ARM multiplatform" framework,
>   2. It allows to build a single kernel that can be booted on multiple
>      platforms.
> To avoid the duplication, I think 2 should be relaxed when specialized
> options like XIP or NOMMU are selected.
> 
> I've just sent a patch to do that.

Your patch isn't wrong per se.  But it is not enough. The issue here 
would be easily fixed with some kconfig extension so that:

- If XIP or NOMMU is selected then only one target in the multiplatform 
  set can be selected, basically turning it into a choice menu.

- If more than one multiplatform targets is selected then XIP and NOMMU 
  can no longere be selected.

I don't know how this could be expressed but the implementation might 
not be that hard.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform
>   set can be selected, basically turning it into a choice menu.
> 
> - If more than one multiplatform targets is selected then XIP and NOMMU
>   can no longere be selected.
>

Over the years I tried to tackle this issue in multiple different ways, 
while still staying in the limitations of kbuild.
Basically, everything was shot down for one reason or another (or the 
only way to do it is really ugly...so I didn't even ask).

kbuild doesn't really have a mutually exclusive property that can be 
dynamically set/cleared.


In the end, I saw only 2 paths for adding XIP to ARM MMU builds:

1) Modify kbuild to give the ability as stated above.

2) Make XIP builds somehow be able to run at multiple physical address 
by modifying the binaries post-build (Arnd's suggestion).


What I have been doing is simply applying this patch to arch/arm/Kconifg
before every XIP KERNEL build:

 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on !ARM_LPAE
 	help
 	  Execute-In-Place allows the kernel to run from non-volatile storage
 	  directly addressable by the CPU, such as NOR flash. This saves RAM



Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform
>   set can be selected, basically turning it into a choice menu.
> 
> - If more than one multiplatform targets is selected then XIP and NOMMU
>   can no longere be selected.
>

Over the years I tried to tackle this issue in multiple different ways, 
while still staying in the limitations of kbuild.
Basically, everything was shot down for one reason or another (or the 
only way to do it is really ugly...so I didn't even ask).

kbuild doesn't really have a mutually exclusive property that can be 
dynamically set/cleared.


In the end, I saw only 2 paths for adding XIP to ARM MMU builds:

1) Modify kbuild to give the ability as stated above.

2) Make XIP builds somehow be able to run at multiple physical address 
by modifying the binaries post-build (Arnd's suggestion).


What I have been doing is simply applying this patch to arch/arm/Kconifg
before every XIP KERNEL build:

 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on !ARM_LPAE
 	help
 	  Execute-In-Place allows the kernel to run from non-volatile storage
 	  directly addressable by the CPU, such as NOR flash. This saves RAM



Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jun 21, 2018 at 6:45 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > > I've just sent a patch to do that.
> >
> > Your patch isn't wrong per se.  But it is not enough. The issue here
> > would be easily fixed with some kconfig extension so that:
> >
> > - If XIP or NOMMU is selected then only one target in the multiplatform
> >   set can be selected, basically turning it into a choice menu.
> >
> > - If more than one multiplatform targets is selected then XIP and NOMMU
> >   can no longere be selected.
>
> Over the years I tried to tackle this issue in multiple different ways,
> while still staying in the limitations of kbuild.
> Basically, everything was shot down for one reason or another (or the
> only way to do it is really ugly...so I didn't even ask).
>
> kbuild doesn't really have a mutually exclusive property that can be
> dynamically set/cleared.
>
> In the end, I saw only 2 paths for adding XIP to ARM MMU builds:
>
> 1) Modify kbuild to give the ability as stated above.

Would that actually help, or would it only give you a false feeling of safety?
Most "multiplatform" sub-architectures (like iMX or "shmobile") still have
multiple families and SoCs, so you have to repeat the exercise at that level.

Still, even when configuring a kernel for a single SoC, the final board
selection is at the DTS level.

Conclusion: If you want NOMMU and/or XIP, you have to know what you're doing,
and hand-holding at whatever level may not save you from making mistakes.

> 2) Make XIP builds somehow be able to run at multiple physical address
> by modifying the binaries post-build (Arnd's suggestion).

That's actually an interesting one: no manual configuration (iff parameters
would be extracted from the DTB), so nothing can go wrong ;-)
I guess it applies to NOMMU, too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jun 21, 2018 at 6:45 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > > I've just sent a patch to do that.
> >
> > Your patch isn't wrong per se.  But it is not enough. The issue here
> > would be easily fixed with some kconfig extension so that:
> >
> > - If XIP or NOMMU is selected then only one target in the multiplatform
> >   set can be selected, basically turning it into a choice menu.
> >
> > - If more than one multiplatform targets is selected then XIP and NOMMU
> >   can no longere be selected.
>
> Over the years I tried to tackle this issue in multiple different ways,
> while still staying in the limitations of kbuild.
> Basically, everything was shot down for one reason or another (or the
> only way to do it is really ugly...so I didn't even ask).
>
> kbuild doesn't really have a mutually exclusive property that can be
> dynamically set/cleared.
>
> In the end, I saw only 2 paths for adding XIP to ARM MMU builds:
>
> 1) Modify kbuild to give the ability as stated above.

Would that actually help, or would it only give you a false feeling of safety?
Most "multiplatform" sub-architectures (like iMX or "shmobile") still have
multiple families and SoCs, so you have to repeat the exercise at that level.

Still, even when configuring a kernel for a single SoC, the final board
selection is at the DTS level.

Conclusion: If you want NOMMU and/or XIP, you have to know what you're doing,
and hand-holding at whatever level may not save you from making mistakes.

> 2) Make XIP builds somehow be able to run at multiple physical address
> by modifying the binaries post-build (Arnd's suggestion).

That's actually an interesting one: no manual configuration (iff parameters
would be extracted from the DTB), so nothing can go wrong ;-)
I guess it applies to NOMMU, too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

Hi Geert,

On Friday, June 22, 2018, Geert Uytterhoeven wrote:
> > 1) Modify kbuild to give the ability as stated above.
> 
> Would that actually help, or would it only give you a false feeling of
> safety?

Yup!
But I don't really care about safty. I just want to be able to build my images without having to hack Kconfig.


> Conclusion: If you want NOMMU and/or XIP, you have to know what you're
> doing,
> and hand-holding at whatever level may not save you from making mistakes.

I agree.
And, you'll require your own kernel config in order to cut out all the 
extra stuff that your system doesn't need.


> > 2) Make XIP builds somehow be able to run at multiple physical address
> > by modifying the binaries post-build (Arnd's suggestion).
> 
> That's actually an interesting one: no manual configuration (iff
> parameters
> would be extracted from the DTB), so nothing can go wrong ;-)
> I guess it applies to NOMMU, too.

For the hard coded memory address, it's only need at the very beginning 
of boot in order to set up a temporary stack, but soon the DTB is read 
and life is good. So in theory, the memory address could be passed in 
with a register.

For the hard coded ROM address, that needs to be available at run time 
in order to do the virt_to_phys translation. But, the idea is to change 
that from a #define to a global variable.

It sounded like it might work...although I never got around to hacking 
the code to see if it would or not because at the end of the day, it 
didn't provide any real value to ab XIP Linux system.


Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

Hi Geert,

On Friday, June 22, 2018, Geert Uytterhoeven wrote:
> > 1) Modify kbuild to give the ability as stated above.
> 
> Would that actually help, or would it only give you a false feeling of
> safety?

Yup!
But I don't really care about safty. I just want to be able to build my images without having to hack Kconfig.


> Conclusion: If you want NOMMU and/or XIP, you have to know what you're
> doing,
> and hand-holding at whatever level may not save you from making mistakes.

I agree.
And, you'll require your own kernel config in order to cut out all the 
extra stuff that your system doesn't need.


> > 2) Make XIP builds somehow be able to run at multiple physical address
> > by modifying the binaries post-build (Arnd's suggestion).
> 
> That's actually an interesting one: no manual configuration (iff
> parameters
> would be extracted from the DTB), so nothing can go wrong ;-)
> I guess it applies to NOMMU, too.

For the hard coded memory address, it's only need at the very beginning 
of boot in order to set up a temporary stack, but soon the DTB is read 
and life is good. So in theory, the memory address could be passed in 
with a register.

For the hard coded ROM address, that needs to be available at run time 
in order to do the virt_to_phys translation. But, the idea is to change 
that from a #define to a global variable.

It sounded like it might work...although I never got around to hacking 
the code to see if it would or not because at the end of the day, it 
didn't provide any real value to ab XIP Linux system.


Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> [ adding linux-kbuild for their input ]
> 
> On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> 
> > I'm afraid adding (duplicating) machine entries for nommu support is not a
> > sustainable solutions. Any machine can run a nommu kernel, in theory.
> > 
> > I'm aware of the objection "but you cannot build a nommu kernel that can
> > boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> > same). So don't do that.
> > 
> > All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> > One more reason not to have this duplication.
> > 
> > The current "ARM multiplatform" has actually two meanings:
> >   1. It groups platforms that follow the "ARM multiplatform" framework,
> >   2. It allows to build a single kernel that can be booted on multiple
> >      platforms.
> > To avoid the duplication, I think 2 should be relaxed when specialized
> > options like XIP or NOMMU are selected.
> > 
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here 
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform 
>   set can be selected, basically turning it into a choice menu.

I don't think that's how it should work.  Consider the V7M case, where
we have better standardisation of the physical address layout than
previous ARM devices.  We have three platforms which are V7M compliant:

- AT91
- iMX
- STM32

These have separate symbols:

menuconfig ARCH_AT91
	bool "AT91/Microchip SoCs"
	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_MXC
	bool "Freescale i.MX family"
	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_STM32
	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7

With your suggestion, you would become only build a kernel for one of
these, but that is not the case today: it's possible to build a single
kernel which supports all these platforms.

So, I don't think we want your suggestion.

What we have today is flexible enough that we can have the best of
multiplatform vs the restrictions caused by the variance in hardware.
IOW, what we have is a compromise, which I believe is a reasonable,
functional, and good compromise that fits the real world physical
conditions with the least amount of overhead.

Every other suggestion I've seen posted has drawbacks, from artificially
restricting what can be selected (eg, as in your case) to allowing more
platforms to be selected thereby creating non-bootable kernels (eg, as
in Geert's case.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> [ adding linux-kbuild for their input ]
> 
> On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> 
> > I'm afraid adding (duplicating) machine entries for nommu support is not a
> > sustainable solutions. Any machine can run a nommu kernel, in theory.
> > 
> > I'm aware of the objection "but you cannot build a nommu kernel that can
> > boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> > same). So don't do that.
> > 
> > All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> > One more reason not to have this duplication.
> > 
> > The current "ARM multiplatform" has actually two meanings:
> >   1. It groups platforms that follow the "ARM multiplatform" framework,
> >   2. It allows to build a single kernel that can be booted on multiple
> >      platforms.
> > To avoid the duplication, I think 2 should be relaxed when specialized
> > options like XIP or NOMMU are selected.
> > 
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here 
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform 
>   set can be selected, basically turning it into a choice menu.

I don't think that's how it should work.  Consider the V7M case, where
we have better standardisation of the physical address layout than
previous ARM devices.  We have three platforms which are V7M compliant:

- AT91
- iMX
- STM32

These have separate symbols:

menuconfig ARCH_AT91
	bool "AT91/Microchip SoCs"
	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_MXC
	bool "Freescale i.MX family"
	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_STM32
	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7

With your suggestion, you would become only build a kernel for one of
these, but that is not the case today: it's possible to build a single
kernel which supports all these platforms.

So, I don't think we want your suggestion.

What we have today is flexible enough that we can have the best of
multiplatform vs the restrictions caused by the variance in hardware.
IOW, what we have is a compromise, which I believe is a reasonable,
functional, and good compromise that fits the real world physical
conditions with the least amount of overhead.

Every other suggestion I've seen posted has drawbacks, from artificially
restricting what can be selected (eg, as in your case) to allowing more
platforms to be selected thereby creating non-bootable kernels (eg, as
in Geert's case.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > [ adding linux-kbuild for their input ]
> > 
> > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > 
> > > I've just sent a patch to do that.
> > 
> > Your patch isn't wrong per se.  But it is not enough. The issue here 
> > would be easily fixed with some kconfig extension so that:
> > 
> > - If XIP or NOMMU is selected then only one target in the multiplatform 
> >   set can be selected, basically turning it into a choice menu.
> 
> I don't think that's how it should work.  Consider the V7M case, where
> we have better standardisation of the physical address layout than
> previous ARM devices.  We have three platforms which are V7M compliant:
> 
> - AT91
> - iMX
> - STM32
> 
> These have separate symbols:
> 
> menuconfig ARCH_AT91
> 	bool "AT91/Microchip SoCs"
> 	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_MXC
> 	bool "Freescale i.MX family"
> 	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_STM32
> 	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> 
> With your suggestion, you would become only build a kernel for one of
> these, but that is not the case today: it's possible to build a single
> kernel which supports all these platforms.

That is still something that could be accommodated if the kconfig 
language was more accommodating. The problem comes from the fact that 
some options are mutually exclusive, like platforms with conflicting 
memory maps and XIP.

Leaving your example above aside for the moment, let's just pick the 
ARCH_MULTIPLATFORM group which is always the problematic one in 
practice. We need a way to limit platform selection within that set to 
only one platform among them all if XIP_KERNEL is set. And that is 
impossible to express with the kconfig language today.

So, my assertion is that, unless someone volunteers a solution to the 
kconfig language to express mutual exclusion between symbols, this issue 
just can't be fixed properly.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > [ adding linux-kbuild for their input ]
> > 
> > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > 
> > > I've just sent a patch to do that.
> > 
> > Your patch isn't wrong per se.  But it is not enough. The issue here 
> > would be easily fixed with some kconfig extension so that:
> > 
> > - If XIP or NOMMU is selected then only one target in the multiplatform 
> >   set can be selected, basically turning it into a choice menu.
> 
> I don't think that's how it should work.  Consider the V7M case, where
> we have better standardisation of the physical address layout than
> previous ARM devices.  We have three platforms which are V7M compliant:
> 
> - AT91
> - iMX
> - STM32
> 
> These have separate symbols:
> 
> menuconfig ARCH_AT91
> 	bool "AT91/Microchip SoCs"
> 	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_MXC
> 	bool "Freescale i.MX family"
> 	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_STM32
> 	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> 
> With your suggestion, you would become only build a kernel for one of
> these, but that is not the case today: it's possible to build a single
> kernel which supports all these platforms.

That is still something that could be accommodated if the kconfig 
language was more accommodating. The problem comes from the fact that 
some options are mutually exclusive, like platforms with conflicting 
memory maps and XIP.

Leaving your example above aside for the moment, let's just pick the 
ARCH_MULTIPLATFORM group which is always the problematic one in 
practice. We need a way to limit platform selection within that set to 
only one platform among them all if XIP_KERNEL is set. And that is 
impossible to express with the kconfig language today.

So, my assertion is that, unless someone volunteers a solution to the 
kconfig language to express mutual exclusion between symbols, this issue 
just can't be fixed properly.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Nicolas,

On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > [ adding linux-kbuild for their input ]
> > >
> > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > I've just sent a patch to do that.
> > >
> > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > would be easily fixed with some kconfig extension so that:
> > >
> > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > >   set can be selected, basically turning it into a choice menu.
> >
> > I don't think that's how it should work.  Consider the V7M case, where
> > we have better standardisation of the physical address layout than
> > previous ARM devices.  We have three platforms which are V7M compliant:
> >
> > - AT91
> > - iMX
> > - STM32
> >
> > These have separate symbols:
> >
> > menuconfig ARCH_AT91
> >       bool "AT91/Microchip SoCs"
> >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_MXC
> >       bool "Freescale i.MX family"
> >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_STM32
> >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> >
> > With your suggestion, you would become only build a kernel for one of
> > these, but that is not the case today: it's possible to build a single
> > kernel which supports all these platforms.
>
> That is still something that could be accommodated if the kconfig
> language was more accommodating. The problem comes from the fact that
> some options are mutually exclusive, like platforms with conflicting
> memory maps and XIP.
>
> Leaving your example above aside for the moment, let's just pick the
> ARCH_MULTIPLATFORM group which is always the problematic one in
> practice. We need a way to limit platform selection within that set to
> only one platform among them all if XIP_KERNEL is set. And that is
> impossible to express with the kconfig language today.
>
> So, my assertion is that, unless someone volunteers a solution to the
> kconfig language to express mutual exclusion between symbols, this issue
> just can't be fixed properly.

Even that would not be sufficient, as these days the final target platform
selection is not by a Kconfig symbol, but by a DT[SB] file.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Nicolas,

On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > [ adding linux-kbuild for their input ]
> > >
> > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > I've just sent a patch to do that.
> > >
> > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > would be easily fixed with some kconfig extension so that:
> > >
> > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > >   set can be selected, basically turning it into a choice menu.
> >
> > I don't think that's how it should work.  Consider the V7M case, where
> > we have better standardisation of the physical address layout than
> > previous ARM devices.  We have three platforms which are V7M compliant:
> >
> > - AT91
> > - iMX
> > - STM32
> >
> > These have separate symbols:
> >
> > menuconfig ARCH_AT91
> >       bool "AT91/Microchip SoCs"
> >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_MXC
> >       bool "Freescale i.MX family"
> >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_STM32
> >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> >
> > With your suggestion, you would become only build a kernel for one of
> > these, but that is not the case today: it's possible to build a single
> > kernel which supports all these platforms.
>
> That is still something that could be accommodated if the kconfig
> language was more accommodating. The problem comes from the fact that
> some options are mutually exclusive, like platforms with conflicting
> memory maps and XIP.
>
> Leaving your example above aside for the moment, let's just pick the
> ARCH_MULTIPLATFORM group which is always the problematic one in
> practice. We need a way to limit platform selection within that set to
> only one platform among them all if XIP_KERNEL is set. And that is
> impossible to express with the kconfig language today.
>
> So, my assertion is that, unless someone volunteers a solution to the
> kconfig language to express mutual exclusion between symbols, this issue
> just can't be fixed properly.

Even that would not be sufficient, as these days the final target platform
selection is not by a Kconfig symbol, but by a DT[SB] file.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > > [ adding linux-kbuild for their input ]
> > > >
> > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > > I've just sent a patch to do that.
> > > >
> > > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > > would be easily fixed with some kconfig extension so that:
> > > >
> > > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > > >   set can be selected, basically turning it into a choice menu.
> > >
> > > I don't think that's how it should work.  Consider the V7M case, where
> > > we have better standardisation of the physical address layout than
> > > previous ARM devices.  We have three platforms which are V7M compliant:
> > >
> > > - AT91
> > > - iMX
> > > - STM32
> > >
> > > These have separate symbols:
> > >
> > > menuconfig ARCH_AT91
> > >       bool "AT91/Microchip SoCs"
> > >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_MXC
> > >       bool "Freescale i.MX family"
> > >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_STM32
> > >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> > >
> > > With your suggestion, you would become only build a kernel for one of
> > > these, but that is not the case today: it's possible to build a single
> > > kernel which supports all these platforms.
> >
> > That is still something that could be accommodated if the kconfig
> > language was more accommodating. The problem comes from the fact that
> > some options are mutually exclusive, like platforms with conflicting
> > memory maps and XIP.
> >
> > Leaving your example above aside for the moment, let's just pick the
> > ARCH_MULTIPLATFORM group which is always the problematic one in
> > practice. We need a way to limit platform selection within that set to
> > only one platform among them all if XIP_KERNEL is set. And that is
> > impossible to express with the kconfig language today.
> >
> > So, my assertion is that, unless someone volunteers a solution to the
> > kconfig language to express mutual exclusion between symbols, this issue
> > just can't be fixed properly.
> 
> Even that would not be sufficient, as these days the final target platform
> selection is not by a Kconfig symbol, but by a DT[SB] file.

That is no longer a kernel config/build issue if you the system 
integrator put an XIP kernel on a target with the wrong DT.

The XIP kernel does require that you provide the actual memory base 
address as a constant to the build system but that could be extracted 
directly from the DT data if having a kconfig prompt for that is too 
unwieldy. The new kconfig macro language in mainline could even be 
leveraged to do that at config time.

All that is possible already. But config symbol mutual exclusion is not.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > > [ adding linux-kbuild for their input ]
> > > >
> > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > > I've just sent a patch to do that.
> > > >
> > > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > > would be easily fixed with some kconfig extension so that:
> > > >
> > > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > > >   set can be selected, basically turning it into a choice menu.
> > >
> > > I don't think that's how it should work.  Consider the V7M case, where
> > > we have better standardisation of the physical address layout than
> > > previous ARM devices.  We have three platforms which are V7M compliant:
> > >
> > > - AT91
> > > - iMX
> > > - STM32
> > >
> > > These have separate symbols:
> > >
> > > menuconfig ARCH_AT91
> > >       bool "AT91/Microchip SoCs"
> > >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_MXC
> > >       bool "Freescale i.MX family"
> > >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_STM32
> > >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> > >
> > > With your suggestion, you would become only build a kernel for one of
> > > these, but that is not the case today: it's possible to build a single
> > > kernel which supports all these platforms.
> >
> > That is still something that could be accommodated if the kconfig
> > language was more accommodating. The problem comes from the fact that
> > some options are mutually exclusive, like platforms with conflicting
> > memory maps and XIP.
> >
> > Leaving your example above aside for the moment, let's just pick the
> > ARCH_MULTIPLATFORM group which is always the problematic one in
> > practice. We need a way to limit platform selection within that set to
> > only one platform among them all if XIP_KERNEL is set. And that is
> > impossible to express with the kconfig language today.
> >
> > So, my assertion is that, unless someone volunteers a solution to the
> > kconfig language to express mutual exclusion between symbols, this issue
> > just can't be fixed properly.
> 
> Even that would not be sufficient, as these days the final target platform
> selection is not by a Kconfig symbol, but by a DT[SB] file.

That is no longer a kernel config/build issue if you the system 
integrator put an XIP kernel on a target with the wrong DT.

The XIP kernel does require that you provide the actual memory base 
address as a constant to the build system but that could be extracted 
directly from the DT data if having a kconfig prompt for that is too 
unwieldy. The new kconfig macro language in mainline could even be 
leveraged to do that at config time.

All that is possible already. But config symbol mutual exclusion is not.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> That is no longer a kernel config/build issue if you the system 
> integrator put an XIP kernel on a target with the wrong DT.
> 
> The XIP kernel does require that you provide the actual memory base 
> address as a constant to the build system but that could be extracted 
> directly from the DT data if having a kconfig prompt for that is too 
> unwieldy. The new kconfig macro language in mainline could even be 
> leveraged to do that at config time.

That is actually incorrect - you're too used to the dynamic fixup of
virt_to_phys() and friends now!

Given that XIP is typically used in environments where the kernel text
is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
disabled, we use a constant translation, based upon the build-time
CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

The early assembler relies upon these settings - which must be known
before we enable the MMU.  As such, DT parsing is not available to us
at that point (as we can't run any C code, because we won't be calling
it at the address it was linked for.)

I suppose someone who was sufficiently motivated could write assembly-
based parsing of DT to extract the memory regions and work out what the
right settings are.  Is there really the motivation to do that - there
was a burst of XIP interest a few releases ago but it seems to have
tailed off.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> That is no longer a kernel config/build issue if you the system 
> integrator put an XIP kernel on a target with the wrong DT.
> 
> The XIP kernel does require that you provide the actual memory base 
> address as a constant to the build system but that could be extracted 
> directly from the DT data if having a kconfig prompt for that is too 
> unwieldy. The new kconfig macro language in mainline could even be 
> leveraged to do that at config time.

That is actually incorrect - you're too used to the dynamic fixup of
virt_to_phys() and friends now!

Given that XIP is typically used in environments where the kernel text
is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
disabled, we use a constant translation, based upon the build-time
CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

The early assembler relies upon these settings - which must be known
before we enable the MMU.  As such, DT parsing is not available to us
at that point (as we can't run any C code, because we won't be calling
it at the address it was linked for.)

I suppose someone who was sufficiently motivated could write assembly-
based parsing of DT to extract the memory regions and work out what the
right settings are.  Is there really the motivation to do that - there
was a burst of XIP interest a few releases ago but it seems to have
tailed off.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> > That is no longer a kernel config/build issue if you the system 
> > integrator put an XIP kernel on a target with the wrong DT.
> > 
> > The XIP kernel does require that you provide the actual memory base 
> > address as a constant to the build system but that could be extracted 
> > directly from the DT data if having a kconfig prompt for that is too 
> > unwieldy. The new kconfig macro language in mainline could even be 
> > leveraged to do that at config time.
> 
> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> 
> The early assembler relies upon these settings - which must be known
> before we enable the MMU.  As such, DT parsing is not available to us
> at that point (as we can't run any C code, because we won't be calling
> it at the address it was linked for.)

I think you got me wrong.  I meant DT parsing at config or build time, 
not at run time.

Latest mainline allows kconfig files to call out to external programs 
now.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> > That is no longer a kernel config/build issue if you the system 
> > integrator put an XIP kernel on a target with the wrong DT.
> > 
> > The XIP kernel does require that you provide the actual memory base 
> > address as a constant to the build system but that could be extracted 
> > directly from the DT data if having a kconfig prompt for that is too 
> > unwieldy. The new kconfig macro language in mainline could even be 
> > leveraged to do that at config time.
> 
> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> 
> The early assembler relies upon these settings - which must be known
> before we enable the MMU.  As such, DT parsing is not available to us
> at that point (as we can't run any C code, because we won't be calling
> it at the address it was linked for.)

I think you got me wrong.  I meant DT parsing at config or build time, 
not at run time.

Latest mainline allows kconfig files to call out to external programs 
now.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > That is actually incorrect - you're too used to the dynamic fixup of
> > virt_to_phys() and friends now!
> > 
> > Given that XIP is typically used in environments where the kernel text
> > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > disabled, we use a constant translation, based upon the build-time
> > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > 
> > The early assembler relies upon these settings - which must be known
> > before we enable the MMU.  As such, DT parsing is not available to us
> > at that point (as we can't run any C code, because we won't be calling
> > it at the address it was linked for.)
> 
> I think you got me wrong.  I meant DT parsing at config or build time, 
> not at run time.

That seems backwards and complicated.  It seems this would end up
with:

- you configure the kernel
- build the dtb files
- reconfigure parsing a specific dtb file built in the previous step
- build the kernel proper

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > That is actually incorrect - you're too used to the dynamic fixup of
> > virt_to_phys() and friends now!
> > 
> > Given that XIP is typically used in environments where the kernel text
> > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > disabled, we use a constant translation, based upon the build-time
> > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > 
> > The early assembler relies upon these settings - which must be known
> > before we enable the MMU.  As such, DT parsing is not available to us
> > at that point (as we can't run any C code, because we won't be calling
> > it at the address it was linked for.)
> 
> I think you got me wrong.  I meant DT parsing at config or build time, 
> not at run time.

That seems backwards and complicated.  It seems this would end up
with:

- you configure the kernel
- build the dtb files
- reconfigure parsing a specific dtb file built in the previous step
- build the kernel proper

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > That is actually incorrect - you're too used to the dynamic fixup of
> > > virt_to_phys() and friends now!
> > > 
> > > Given that XIP is typically used in environments where the kernel text
> > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > disabled, we use a constant translation, based upon the build-time
> > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > 
> > > The early assembler relies upon these settings - which must be known
> > > before we enable the MMU.  As such, DT parsing is not available to us
> > > at that point (as we can't run any C code, because we won't be calling
> > > it at the address it was linked for.)
> > 
> > I think you got me wrong.  I meant DT parsing at config or build time, 
> > not at run time.
> 
> That seems backwards and complicated.  It seems this would end up
> with:
> 
> - you configure the kernel
> - build the dtb files
> - reconfigure parsing a specific dtb file built in the previous step
> - build the kernel proper

... or just stick the right value manually when prompting for 
XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
the conversation away from the actual kconfig language limitation that 
needs to be overcome.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > That is actually incorrect - you're too used to the dynamic fixup of
> > > virt_to_phys() and friends now!
> > > 
> > > Given that XIP is typically used in environments where the kernel text
> > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > disabled, we use a constant translation, based upon the build-time
> > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > 
> > > The early assembler relies upon these settings - which must be known
> > > before we enable the MMU.  As such, DT parsing is not available to us
> > > at that point (as we can't run any C code, because we won't be calling
> > > it at the address it was linked for.)
> > 
> > I think you got me wrong.  I meant DT parsing at config or build time, 
> > not at run time.
> 
> That seems backwards and complicated.  It seems this would end up
> with:
> 
> - you configure the kernel
> - build the dtb files
> - reconfigure parsing a specific dtb file built in the previous step
> - build the kernel proper

... or just stick the right value manually when prompting for 
XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
the conversation away from the actual kconfig language limitation that 
needs to be overcome.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> 
> > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > virt_to_phys() and friends now!
> > > > 
> > > > Given that XIP is typically used in environments where the kernel text
> > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > disabled, we use a constant translation, based upon the build-time
> > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > 
> > > > The early assembler relies upon these settings - which must be known
> > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > at that point (as we can't run any C code, because we won't be calling
> > > > it at the address it was linked for.)
> > > 
> > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > not at run time.
> > 
> > That seems backwards and complicated.  It seems this would end up
> > with:
> > 
> > - you configure the kernel
> > - build the dtb files
> > - reconfigure parsing a specific dtb file built in the previous step
> > - build the kernel proper
> 
> ... or just stick the right value manually when prompting for 
> XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> the conversation away from the actual kconfig language limitation that 
> needs to be overcome.

Which is _exactly_ what we do today, so I don't see what point you're
making in this sub-thread.

I thought we were discussing about getting Kconfig to obtain settings
from dtb files.  If you have a point to make, please don't make the
discussion impossible by changing your point, it makes it a waste of
time trying to have a discussion.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> 
> > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > virt_to_phys() and friends now!
> > > > 
> > > > Given that XIP is typically used in environments where the kernel text
> > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > disabled, we use a constant translation, based upon the build-time
> > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > 
> > > > The early assembler relies upon these settings - which must be known
> > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > at that point (as we can't run any C code, because we won't be calling
> > > > it at the address it was linked for.)
> > > 
> > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > not at run time.
> > 
> > That seems backwards and complicated.  It seems this would end up
> > with:
> > 
> > - you configure the kernel
> > - build the dtb files
> > - reconfigure parsing a specific dtb file built in the previous step
> > - build the kernel proper
> 
> ... or just stick the right value manually when prompting for 
> XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> the conversation away from the actual kconfig language limitation that 
> needs to be overcome.

Which is _exactly_ what we do today, so I don't see what point you're
making in this sub-thread.

I thought we were discussing about getting Kconfig to obtain settings
from dtb files.  If you have a point to make, please don't make the
discussion impossible by changing your point, it makes it a waste of
time trying to have a discussion.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > 
> > > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > > virt_to_phys() and friends now!
> > > > > 
> > > > > Given that XIP is typically used in environments where the kernel text
> > > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > > disabled, we use a constant translation, based upon the build-time
> > > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > > 
> > > > > The early assembler relies upon these settings - which must be known
> > > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > > at that point (as we can't run any C code, because we won't be calling
> > > > > it at the address it was linked for.)
> > > > 
> > > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > > not at run time.
> > > 
> > > That seems backwards and complicated.  It seems this would end up
> > > with:
> > > 
> > > - you configure the kernel
> > > - build the dtb files
> > > - reconfigure parsing a specific dtb file built in the previous step
> > > - build the kernel proper
> > 
> > ... or just stick the right value manually when prompting for 
> > XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> > the conversation away from the actual kconfig language limitation that 
> > needs to be overcome.
> 
> Which is _exactly_ what we do today, so I don't see what point you're
> making in this sub-thread.

I was merely trying to show Geert that DT dependencies are not an issue 
after he brought that as an argument.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > 
> > > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > > virt_to_phys() and friends now!
> > > > > 
> > > > > Given that XIP is typically used in environments where the kernel text
> > > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > > disabled, we use a constant translation, based upon the build-time
> > > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > > 
> > > > > The early assembler relies upon these settings - which must be known
> > > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > > at that point (as we can't run any C code, because we won't be calling
> > > > > it at the address it was linked for.)
> > > > 
> > > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > > not at run time.
> > > 
> > > That seems backwards and complicated.  It seems this would end up
> > > with:
> > > 
> > > - you configure the kernel
> > > - build the dtb files
> > > - reconfigure parsing a specific dtb file built in the previous step
> > > - build the kernel proper
> > 
> > ... or just stick the right value manually when prompting for 
> > XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> > the conversation away from the actual kconfig language limitation that 
> > needs to be overcome.
> 
> Which is _exactly_ what we do today, so I don't see what point you're
> making in this sub-thread.

I was merely trying to show Geert that DT dependencies are not an issue 
after he brought that as an argument.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

CONFIG_PHYS_OFFSET (RAM address) and CONFIG_XIP_PHYS_ADDR (ROM address) 
are set today in kconfig.

Instead of having them hard coded, they could be global variables set 
during boot.

CONFIG_XIP_PHYS_ADDR could be determined by looking at the value of the 
PC.

CONFIG_PHYS_OFFSET is still the issue because that has to be passed in 
via boot register.


> I suppose someone who was sufficiently motivated could write assembly-
> based parsing of DT to extract the memory regions and work out what the
> right settings are.  Is there really the motivation to do that - there
> was a burst of XIP interest a few releases ago but it seems to have
> tailed off.

Because at least for me, by simply removing the !ARCH_MULTIPLATFORM 
dependency for setting XIP_KERNEL works perfectly fine for building and 
running kernels.

So, it's hard to justify doing a lot more work than what can be done 
today with just 1 line edit.

I still test every kernel release to make XIP_KERNEL still works.

Actually, I just tested 4.18.0-rc1 this morning.


Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

CONFIG_PHYS_OFFSET (RAM address) and CONFIG_XIP_PHYS_ADDR (ROM address) 
are set today in kconfig.

Instead of having them hard coded, they could be global variables set 
during boot.

CONFIG_XIP_PHYS_ADDR could be determined by looking at the value of the 
PC.

CONFIG_PHYS_OFFSET is still the issue because that has to be passed in 
via boot register.


> I suppose someone who was sufficiently motivated could write assembly-
> based parsing of DT to extract the memory regions and work out what the
> right settings are.  Is there really the motivation to do that - there
> was a burst of XIP interest a few releases ago but it seems to have
> tailed off.

Because at least for me, by simply removing the !ARCH_MULTIPLATFORM 
dependency for setting XIP_KERNEL works perfectly fine for building and 
running kernels.

So, it's hard to justify doing a lot more work than what can be done 
today with just 1 line edit.

I still test every kernel release to make XIP_KERNEL still works.

Actually, I just tested 4.18.0-rc1 this morning.


Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> All that is possible already. But config symbol mutual exclusion is not.

I still don't understand why we need some false sense of security for 
only selecting 1 platform.

There are probably plenty of kernel config options that you could enable
that would break any number of systems.

So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
it?

Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> All that is possible already. But config symbol mutual exclusion is not.

I still don't understand why we need some false sense of security for 
only selecting 1 platform.

There are probably plenty of kernel config options that you could enable
that would break any number of systems.

So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
it?

Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> > All that is possible already. But config symbol mutual exclusion is not.
> 
> I still don't understand why we need some false sense of security for 
> only selecting 1 platform.

Because that's the right thing to do. Small hacks are nice, but when 
they accumulate (and they always do over time) then maintainability 
suffers. This is why you may do whatever small hacks in your own copy of 
the kernel code and that might be good enough, but the mainline source 
tree should be held to higher standards.

> There are probably plenty of kernel config options that you could enable
> that would break any number of systems.

That's no excuse to add more of them. Many people are constantly working 
to move things in the other direction.

> So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
> it?

Because we simply try not to create invalid kernel configurations. 
XIP_KERNEL is not more special than other symbols in that respect.

And if the kconfig language has to be extended for proper configurations 
to be produced then that's what it is, and trying to cheat around that 
fact won't produce any good.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> > All that is possible already. But config symbol mutual exclusion is not.
> 
> I still don't understand why we need some false sense of security for 
> only selecting 1 platform.

Because that's the right thing to do. Small hacks are nice, but when 
they accumulate (and they always do over time) then maintainability 
suffers. This is why you may do whatever small hacks in your own copy of 
the kernel code and that might be good enough, but the mainline source 
tree should be held to higher standards.

> There are probably plenty of kernel config options that you could enable
> that would break any number of systems.

That's no excuse to add more of them. Many people are constantly working 
to move things in the other direction.

> So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
> it?

Because we simply try not to create invalid kernel configurations. 
XIP_KERNEL is not more special than other symbols in that respect.

And if the kconfig language has to be extended for proper configurations 
to be produced then that's what it is, and trying to cheat around that 
fact won't produce any good.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Nicolas Pitre wrote:
> > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > it?
> 
> Because we simply try not to create invalid kernel configurations.
> XIP_KERNEL is not more special than other symbols in that respect.

Then here's a question.

To be clear, the discussion is around

  "Being able to build a kernel that will not boot"

So which one of these is more important: build or boot?

Meaning what if you can select multiple platforms in kconfig, but then 
there is a .c file that does more sanity checking that then prevents the 
full build using a #error.

In that case you can never "build" a kernel that has no chance of 
booting on all the selected platforms.

There are configs options today that you can select, but unless some 
external criteria is  met during build time, the build will fail (like
with a "missing .h file" message or something)


Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Nicolas Pitre wrote:
> > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > it?
> 
> Because we simply try not to create invalid kernel configurations.
> XIP_KERNEL is not more special than other symbols in that respect.

Then here's a question.

To be clear, the discussion is around

  "Being able to build a kernel that will not boot"

So which one of these is more important: build or boot?

Meaning what if you can select multiple platforms in kconfig, but then 
there is a .c file that does more sanity checking that then prevents the 
full build using a #error.

In that case you can never "build" a kernel that has no chance of 
booting on all the selected platforms.

There are configs options today that you can select, but unless some 
external criteria is  met during build time, the build will fail (like
with a "missing .h file" message or something)


Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018, Nicolas Pitre wrote:
> > > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > > it?
> > 
> > Because we simply try not to create invalid kernel configurations.
> > XIP_KERNEL is not more special than other symbols in that respect.
> 
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

Obviously both. Most people are ultimately interested in kernels that 
can boot.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

Sorry, that is still cheating around the actual issue, which is the 
inability to properly express mutually exclusive config symbols in 
kconfig.


Nicolas

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018, Nicolas Pitre wrote:
> > > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > > it?
> > 
> > Because we simply try not to create invalid kernel configurations.
> > XIP_KERNEL is not more special than other symbols in that respect.
> 
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

Obviously both. Most people are ultimately interested in kernels that 
can boot.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

Sorry, that is still cheating around the actual issue, which is the 
inability to properly express mutually exclusive config symbols in 
kconfig.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 05:23:09PM +0000, Chris Brandt wrote:
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

We care about both.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

... which is not acceptable.  We have a lot of automated build
infrastructure to build almost every commit in the mainline kernel
against almost every build configuration that is present in the
kernel and every architecture that is present in the mainline kernel.
We also have people that build random configurations and fix any
build failures and warnings which result from that.

I also build randconfigs here.

> In that case you can never "build" a kernel that has no chance of 
> booting on all the selected platforms.
> 
> There are configs options today that you can select, but unless some 
> external criteria is  met during build time, the build will fail (like
> with a "missing .h file" message or something)

Such as?  I don't think that's found by the randconfig builders - I've
never noticed any such failures on ARM.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 05:23:09PM +0000, Chris Brandt wrote:
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

We care about both.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

... which is not acceptable.  We have a lot of automated build
infrastructure to build almost every commit in the mainline kernel
against almost every build configuration that is present in the
kernel and every architecture that is present in the mainline kernel.
We also have people that build random configurations and fix any
build failures and warnings which result from that.

I also build randconfigs here.

> In that case you can never "build" a kernel that has no chance of 
> booting on all the selected platforms.
> 
> There are configs options today that you can select, but unless some 
> external criteria is  met during build time, the build will fail (like
> with a "missing .h file" message or something)

Such as?  I don't think that's found by the randconfig builders - I've
never noticed any such failures on ARM.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > There are configs options today that you can select, but unless some
> > external criteria is  met during build time, the build will fail (like
> > with a "missing .h file" message or something)
> 
> Such as?  I don't think that's found by the randconfig builders - I've
> never noticed any such failures on ARM.

I got this set once by accident after a kernel update

   CONFIG_SYSTEM_TRUSTED_KEYRING=y

which then let me to this error:

  HOSTCC  scripts/extract-cert
../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
compilation terminated.



Regardless, I take your opinion as valid.


Chris

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > There are configs options today that you can select, but unless some
> > external criteria is  met during build time, the build will fail (like
> > with a "missing .h file" message or something)
> 
> Such as?  I don't think that's found by the randconfig builders - I've
> never noticed any such failures on ARM.

I got this set once by accident after a kernel update

   CONFIG_SYSTEM_TRUSTED_KEYRING=y

which then let me to this error:

  HOSTCC  scripts/extract-cert
../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
compilation terminated.



Regardless, I take your opinion as valid.


Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Fri, Jun 22, 2018 at 10:25 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> >
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
>
> I got this set once by accident after a kernel update
>
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
>
> which then let me to this error:
>
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Which just means libssl-dev became a build dependency.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Fri, Jun 22, 2018 at 10:25 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> >
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
>
> I got this set once by accident after a kernel update
>
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
>
> which then let me to this error:
>
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Which just means libssl-dev became a build dependency.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 08:25:06PM +0000, Chris Brandt wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> > 
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
> 
> I got this set once by accident after a kernel update
> 
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
> 
> which then let me to this error:
> 
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Hmm.  Is that a problem if the documented minimum requirements to build
the kernel are violated?  It seems the openssl 1.0.0 development package
is required to build kernels v4.3 and beyond.

Here's what Documentation/process/changes.rst has to say about it:

Current Minimal Requirements
****************************
...
====================== ===============  ========================================
        Program        Minimal version       Command to check the version
====================== ===============  ========================================
openssl & libcrypto    1.0.0            openssl version
...
OpenSSL
-------

Module signing and external certificate handling use the OpenSSL program and
crypto library to do key creation and signature generation.

You will need openssl to build kernels 3.7 and higher if module signing is
enabled.  You will also need openssl development packages to build kernels 4.3
and higher.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 08:25:06PM +0000, Chris Brandt wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> > 
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
> 
> I got this set once by accident after a kernel update
> 
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
> 
> which then let me to this error:
> 
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Hmm.  Is that a problem if the documented minimum requirements to build
the kernel are violated?  It seems the openssl 1.0.0 development package
is required to build kernels v4.3 and beyond.

Here's what Documentation/process/changes.rst has to say about it:

Current Minimal Requirements
****************************
...
====================== ===============  ========================================
        Program        Minimal version       Command to check the version
====================== ===============  ========================================
openssl & libcrypto    1.0.0            openssl version
...
OpenSSL
-------

Module signing and external certificate handling use the OpenSSL program and
crypto library to do key creation and signature generation.

You will need openssl to build kernels 3.7 and higher if module signing is
enabled.  You will also need openssl development packages to build kernels 4.3
and higher.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Greg Ungerer]

Hi Geert,

On 22/06/18 01:59, Geert Uytterhoeven wrote:
> CC Chris, Arnd, Nicolas
> On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote:
>> Allow the arm versatile machine to be configured for no-MMU operation.
>>
>> Older kernels had the ability to build the versatile machine with the MMU
>> disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
>> to device tree lost this ability. (Although older kernels could be built
>> they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
>>
>> The motivation for this is that the versatile machine is well supported
>> in qemu. And this provides an excellent platform for development and
>> testing no-MMU support on ARM in general.
>>
>> This patch adds a versatile platform selection in the upper level arm
>> system type menu - where it appeared in older kernel versions - when
>> configuring for the no-MMU case. There is no visible change to the way
>> versatile is selected for the MMU enabled case.
>>
>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> 
> Thanks for your patch! I'm happy to see nommu spreading ;-)

Not sure if it is a good thing or not :-)


>> ---
>>   arch/arm/Kconfig                | 11 +++++++++++
>>   arch/arm/Kconfig.debug          |  3 ++-
>>   arch/arm/mach-versatile/Kconfig |  5 +++--
>>   3 files changed, 16 insertions(+), 3 deletions(-)
>>
>> v2: don't use a multiplatform setup, move versatile choice to top level menu
>> v3: rebase on top of linux-4.10
>> v3: rebase on top of linux-4.17
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 54eeb8d00bc6..0608a6a32fac 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M
>>          select SPARSE_IRQ
>>          select USE_OF
>>
>> +config ARM_SINGLE_ARCH_VERSATILE
>> +       bool "ARM Ltd. Versatile family"
>> +       depends on !MMU
>> +       select AUTO_ZRELADDR
>> +       select CLKSRC_OF
>> +       select COMMON_CLK
>> +       select GENERIC_CLOCKEVENTS
>> +       select GPIOLIB
>> +       select SPARSE_IRQ
>> +       select USE_OF
>> +
> 
> I'm afraid adding (duplicating) machine entries for nommu support is not a
> sustainable solutions. Any machine can run a nommu kernel, in theory.

I don't disagree with you, my first patch for this did not duplicate
the machine type:

   https://patchwork.kernel.org/patch/9350033/

Vladimir Murzin had an alternative that also didn't duplicate machines:

   https://www.spinics.net/lists/arm-kernel/msg546837.html

But subsequent discussions didn't really get to a final solution:

   https://patchwork.kernel.org/patch/9464017/

Regards
Greg


> I'm aware of the objection "but you cannot build a nommu kernel that can
> boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> same). So don't do that.
> 
> All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> One more reason not to have this duplication.
> 
> The current "ARM multiplatform" has actually two meanings:
>    1. It groups platforms that follow the "ARM multiplatform" framework,
>    2. It allows to build a single kernel that can be booted on multiple
>       platforms.
> To avoid the duplication, I think 2 should be relaxed when specialized
> options like XIP or NOMMU are selected.
> 
> I've just sent a patch to do that.
> 
>>   config ARCH_EBSA110
>>          bool "EBSA-110"
>>          select ARCH_USES_GETTIMEOFFSET
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 693f84392f1b..242a0f744c8a 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS
>>   config UNCOMPRESS_INCLUDE
>>          string
>>          default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
>> -                                       PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
>> +                                       PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
>> +                                       ARM_SINGLE_ARCH_VERSATILE
>>          default "mach/uncompress.h"
>>
>>   config EARLY_PRINTK
>> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
>> index f5c275434d6c..06ad999d5978 100644
>> --- a/arch/arm/mach-versatile/Kconfig
>> +++ b/arch/arm/mach-versatile/Kconfig
>> @@ -1,7 +1,8 @@
>>   # SPDX-License-Identifier: GPL-2.0
>>   config ARCH_VERSATILE
>> -       bool "ARM Ltd. Versatile family"
>> -       depends on ARCH_MULTI_V5
>> +       bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
>> +       depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
>> +       default y if ARM_SINGLE_ARCH_VERSATILE
>>          select ARM_AMBA
>>          select ARM_TIMER_SP804
>>          select ARM_VIC
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> 

[PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Thu, Jun 21, 2018 at 05:59:54PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> CC Chris, Arnd, Nicolas
> 
> On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote:
> > Allow the arm versatile machine to be configured for no-MMU operation.
> >
> > Older kernels had the ability to build the versatile machine with the MMU
> > disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
> > to device tree lost this ability. (Although older kernels could be built
> > they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
> >
> > The motivation for this is that the versatile machine is well supported
> > in qemu. And this provides an excellent platform for development and
> > testing no-MMU support on ARM in general.
> >
> > This patch adds a versatile platform selection in the upper level arm
> > system type menu - where it appeared in older kernel versions - when
> > configuring for the no-MMU case. There is no visible change to the way
> > versatile is selected for the MMU enabled case.
> >
> > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> 
> Thanks for your patch! I'm happy to see nommu spreading ;-)
> 
> 
> > ---
> >  arch/arm/Kconfig                | 11 +++++++++++
> >  arch/arm/Kconfig.debug          |  3 ++-
> >  arch/arm/mach-versatile/Kconfig |  5 +++--
> >  3 files changed, 16 insertions(+), 3 deletions(-)
> >
> > v2: don't use a multiplatform setup, move versatile choice to top level menu
> > v3: rebase on top of linux-4.10
> > v3: rebase on top of linux-4.17
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 54eeb8d00bc6..0608a6a32fac 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M
> >         select SPARSE_IRQ
> >         select USE_OF
> >
> > +config ARM_SINGLE_ARCH_VERSATILE
> > +       bool "ARM Ltd. Versatile family"
> > +       depends on !MMU
> > +       select AUTO_ZRELADDR
> > +       select CLKSRC_OF
> > +       select COMMON_CLK
> > +       select GENERIC_CLOCKEVENTS
> > +       select GPIOLIB
> > +       select SPARSE_IRQ
> > +       select USE_OF
> > +
> 
> I'm afraid adding (duplicating) machine entries for nommu support is not a
> sustainable solutions. Any machine can run a nommu kernel, in theory.

Sorry, I strongly disagree.  You may be right "in theory" but theory
is useless when in practice you _can't_ because of the radically
different physical memory layouts.

I don't care about "but in theory" crap - we have to deal with
reality, and the reality is that ARM platforms are diverse in their
physical memory layouts.

So, violent NAK on reusing MULTIPLATFORM for XIP/NOMMU.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up