ARM: nommu: re-enable use of vexpress without ARCH_MULTIPLATFORM

From: Will Deacon <[email protected]>

Since 617276307cd4c ("ARM: vexpress: convert to multi-platform") it has been impossible to select ARCH_VEXPRESS without ARCH_MULTIPLATFORM.

ARCH_MULTIPLATFORM doesn't make sense for NOMMU targets, not least because of the need to hard-code the memory map. However, it should still be possible to run NOMMU kernels on top of the Versatile Express by selecting it as the only platform.

This patch creates a shim ARCH_VEXPRESS_NOMMU config option in the 'choice' for "ARM system type" to make this possible again.

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Jonathan Austin <[email protected]>

CC Nicolas Pitre <[email protected]>

CC Arnd Bergmann <[email protected]>

---

Arnd and Nicolas: I've removed your acks as I've changed the location of the new block (as Nicolas suggested) and ever so slightly tweaked the name of the new option.

 arch/arm/Kconfig |    5 +++++
 1 file changed, 5 insertions(+)

arch/arm/Kconfig +5 -0

index 335e220..3357d0b 100644
@@ -322,6 +322,11 @@ config ARCH_VERSATILE
 	help
 	  This enables support for ARM Ltd Versatile board.
 
+config ARCH_VEXPRESS_NOMMU
+	bool "ARM Ltd. Versatile Express family for NOMMU"
+	depends on !MMU
+	select ARCH_VEXPRESS
+
 config ARCH_AT91
 	bool "Atmel AT91"
 	select ARCH_REQUIRE_GPIOLIB

Signature · 1 line

1.7.9.5

Quoted 1 line · Jonathan Austin

From: Will Deacon <[email protected]>

Did Will actually write the patch? It rather looks like you are the one folloing through, in which case you deserve the credits.

From: Will Deacon <[email protected]>

Since 617276307cd4c ("ARM: vexpress: convert to multi-platform") it has been impossible to select ARCH_VEXPRESS without ARCH_MULTIPLATFORM.

ARCH_MULTIPLATFORM doesn't make sense for NOMMU targets, not least because of the need to hard-code the memory map. However, it should still be possible to run NOMMU kernels on top of the Versatile Express by selecting it as the only platform.

This patch creates a shim ARCH_VEXPRESS_NOMMU config option in the 'choice' for "ARM system type" to make this possible again.

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Jonathan Austin <[email protected]>

CC Nicolas Pitre <[email protected]>

CC Arnd Bergmann <[email protected]>

---

Arnd and Nicolas: I've removed your acks as I've changed the location of the new block (as Nicolas suggested) and ever so slightly tweaked the name of the new option.

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

Quoted 4 lines · Arnd Bergmann

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

The virtual guest platform support that Will and Marc did is small enough that it could always be selected in place of vexpress.

Quoted 9 lines · Nicolas Pitre

Quoted 4 lines · Arnd Bergmann

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

The virtual guest platform support that Will and Marc did is small enough that it could always be selected in place of vexpress.

But that only helps when ARMv7 is selected, unless we want to build it only for ARMv4, v5 or v6 kernels.

Besides, the only reason we can't have a kernel without any platform selected is that the linker script has code in it to intentionally barf on that because it's guaranteed not to boot on any hardware.

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Quoted 14 lines · Arnd Bergmann

Quoted 9 lines · Nicolas Pitre

Quoted 4 lines · Arnd Bergmann

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

The virtual guest platform support that Will and Marc did is small enough that it could always be selected in place of vexpress.

But that only helps when ARMv7 is selected, unless we want to build it only for ARMv4, v5 or v6 kernels.

Quoted 7 lines

Besides, the only reason we can't have a kernel without any platform selected is that the linker script has code in it to intentionally barf on that because it's guaranteed not to boot on any hardware.

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

That patch is already posted, but Russell doesn't like it as you can have a kernel that doesn't boot. You don't like the allno and randconfig failures, so we're stuck. I think there are dozens of config options that will make you not boot on any given platform, so failing to boot because you did not select your machine is a non-issue.

Quoted 23 lines · Rob Herring

Quoted 14 lines · Arnd Bergmann

Quoted 9 lines · Nicolas Pitre

Quoted 4 lines · Arnd Bergmann

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

The virtual guest platform support that Will and Marc did is small enough that it could always be selected in place of vexpress.

But that only helps when ARMv7 is selected, unless we want to build it only for ARMv4, v5 or v6 kernels.

Quoted 7 lines

Besides, the only reason we can't have a kernel without any platform selected is that the linker script has code in it to intentionally barf on that because it's guaranteed not to boot on any hardware.

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Quoted 5 lines

That patch is already posted, but Russell doesn't like it as you can have a kernel that doesn't boot. You don't like the allno and randconfig failures, so we're stuck. I think there are dozens of config options that will make you not boot on any given platform, so failing to boot because you did not select your machine is a non-issue.

What I actually suggested is that we should be aiming for the DT side of things to get to the point where DT is just another _single_ platform as far as that code goes, and that DT should describe the hardware sufficiently well that we don't have multiple machine_desc things to select via DT - so a DT kernel would have exactly one machine_desc (or maybe even zero! - with the linker script check conditional on !CONFIG_OF)

That then gets rid of the issue entirely.

Quoted 8 lines

What I actually suggested is that we should be aiming for the DT side of things to get to the point where DT is just another single platform as far as that code goes, and that DT should describe the hardware sufficiently well that we don't have multiple machine_desc things to select via DT - so a DT kernel would have exactly one machine_desc (or maybe even zero! - with the linker script check conditional on !CONFIG_OF)

Quoted 1 line

That then gets rid of the issue entirely.

I agree completely. I look at mach-highbank (and mach-virt) as what else needs to be done in terms of refactoring or moving to DT.

That's certainly a long term goal, but what is the short term solution?

I'd certainly be happy with

* removing the intentional build error for ARCH_MULTIPLATFORM, but leaving it in for !ARCH_MULTIPLATFORM
* having mach-virt enabled by default on ARCH_MULTIPLATFORM, and only visible for EXPERT.
* making mach-virt compatible with all CPUs starting with ARM7.

That would make allnoconfig, allyesconfig and allmodconfig work (besides all the other bugs) on qemu at least, avoid build errors with randconfig and make it hard enough to build a kernel that doesn't run on anything.

On 01/10/2013 05:16 AM, Arnd Bergmann wrote:

[...]

Quoted 11 lines

I'd certainly be happy with

* removing the intentional build error for ARCH_MULTIPLATFORM, but leaving it in for !ARCH_MULTIPLATFORM
* having mach-virt enabled by default on ARCH_MULTIPLATFORM, and only visible for EXPERT.
* making mach-virt compatible with all CPUs starting with ARM7.

That would make allnoconfig, allyesconfig and allmodconfig work (besides all the other bugs) on qemu at least, avoid build errors with randconfig and make it hard enough to build a kernel that doesn't run on anything.

If this is going to be the approach, I would like to once again suggest that paths, configuration options, and compatibility strings along the lines of "mach-genericarmv7", "Generic ARMv7 Machine", and "linux,genericarmv7" be considered in place of "mach-virt", "Dummy Virtual Machine" and "linux,dummy-virt", respectively.

Virtualization may have been the initial motivation for creating mach-virt, but the code is clearly also immediately applicable to other environments such as simulation/emulation, and sticking to a name like "Dummy Virtual Machine" makes it sound like such usage is erroneous.

That patch is already posted, but Russell doesn't like it as you can have a kernel that doesn't boot. You don't like the allno and randconfig failures, so we're stuck. I think there are dozens of config options that will make you not boot on any given platform, so failing to boot because you did not select your machine is a non-issue.

Quoted 7 lines · Nicolas Pitre

Quoted 4 lines · Arnd Bergmann

On a related topic, I still think we should fix ARCH_MULTI_V7 not to select ARCH_VEXPRESS unconditionally and come up with a better way to avoid having an empty platform list to make 'allnoconfig' still work.

Quoted 2 lines

The virtual guest platform support that Will and Marc did is small enough that it could always be selected in place of vexpress.

But that only helps when ARMv7 is selected, unless we want to build it only for ARMv4, v5 or v6 kernels.

Besides, the only reason we can't have a kernel without any platform selected is that the linker script has code in it to intentionally barf on that because it's guaranteed not to boot on any hardware.

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Quoted 2 lines

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Is it expected for allnoconfig kernels to still boot on other architectures? If so I think we should try to still provide a valid config even in the allnoconfig case.

Quoted 6 lines · Nicolas Pitre

Quoted 2 lines

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Is it expected for allnoconfig kernels to still boot on other architectures? If so I think we should try to still provide a valid config even in the allnoconfig case.

The practical use of a kernel without any device drivers or file systems is pretty low, I would not expect such a kernel to be any useful.

Quoted 11 lines · Arnd Bergmann

Quoted 6 lines · Nicolas Pitre

Quoted 2 lines

If we decide that building an allnoconfig without any platform is actually ok, we could just as well rip out that error statement.

Is it expected for allnoconfig kernels to still boot on other architectures? If so I think we should try to still provide a valid config even in the allnoconfig case.

The practical use of a kernel without any device drivers or file systems is pretty low, I would not expect such a kernel to be any useful.

I didn't say "useful". But at least "booting" e.g. to print out a kernel oops because no root filesystem is available or the like should be a minimum. Having the wrong platform configured in might prevent even that from working, but at least we shouldn't allow for a kernel config that we know in advance has no chance of ever executing anywhere.