Skip to contentSkip to conversation

ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

PATCH Superseded Fabio Estevam 4 participants 8 messages Nov 20, 2012 – Jan 2, 2013

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

From: Fabio Estevam <[email protected]>

When building a kernel using imx_v6_v7_defconfig, it is not possible to unselect ARCH_VEXPRESS due to the fact that it is automatically selected by ARCH_MULTI_V7.

This is not good when someone wants to create a minimal kernel build, so let multi_v7_defconfig select ARCH_VEXPRESS instead.

Also avoid build breakage when randconfig selects no platform.

---
Changes since v1:
- Avoid build breakage on randconfig for the case that no platform is selected.

 arch/arm/Kconfig                    |    2 +-
 arch/arm/configs/multi_v7_defconfig |    1 +
 arch/arm/kernel/vmlinux.lds.S       |    2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)
arch/arm/Kconfig +1 -1
index 14f8160..372cb4e 100644
@@ -267,6 +267,7 @@ choice
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
 	depends on MMU
+	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_PATCH_PHYS_VIRT
 	select AUTO_ZRELADDR
 	select COMMON_CLK
@@ -1000,7 +1001,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
arch/arm/configs/multi_v7_defconfig +1 -0
index 159f75f..531c538 100644
@@ -6,6 +6,7 @@ CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_SOCFPGA=y
+CONFIG_ARCH_VEXPRESS=y
 # CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
 CONFIG_ARM_ERRATA_754322=y
 CONFIG_SMP=y
arch/arm/kernel/vmlinux.lds.S +2 -0
index b9f38e3..aa46be8 100644
@@ -310,4 +310,6 @@ SECTIONS
  * binutils is too old (for other reasons as well)
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
+#ifndef CONFIG_ARCH_MULTIPLATFORM
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+#endif
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

Hi Rob,

Quoted 8 lines · Fabio Estevam

From: Fabio Estevam <[email protected]>

When building a kernel using imx_v6_v7_defconfig, it is not possible to unselect ARCH_VEXPRESS due to the fact that it is automatically selected by ARCH_MULTI_V7.

This is not good when someone wants to create a minimal kernel build, so let multi_v7_defconfig select ARCH_VEXPRESS instead.

Quoted 6 lines

Also avoid build breakage when randconfig selects no platform.

---
Changes since v1:
- Avoid build breakage on randconfig for the case that no platform is selected.

Does this version look good?

Regards,

Fabio Estevam

#2 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

Quoted 11 lines · Fabio Estevam

Hi Rob,

Quoted 8 lines · Fabio Estevam

From: Fabio Estevam <[email protected]>

When building a kernel using imx_v6_v7_defconfig, it is not possible to unselect ARCH_VEXPRESS due to the fact that it is automatically selected by ARCH_MULTI_V7.

This is not good when someone wants to create a minimal kernel build, so let multi_v7_defconfig select ARCH_VEXPRESS instead.

Quoted 8 lines
Quoted 6 lines

Also avoid build breakage when randconfig selects no platform.

---
Changes since v1:
- Avoid build breakage on randconfig for the case that no platform is selected.

Does this version look good?

Yes.

Quoted 5 lines

Regards,

Fabio Estevam

#3 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

Russell,

Quoted 5 lines · Rob Herring
Quoted 1 line

Does this version look good?

Yes.

Should I submit this one to the patch system?

Regards,

Fabio Estevam

#4 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

In reply to Fabio Estevam
Quoted 7 lines · Fabio Estevam

From: Fabio Estevam <[email protected]>

When building a kernel using imx_v6_v7_defconfig, it is not possible to unselect ARCH_VEXPRESS due to the fact that it is automatically selected by ARCH_MULTI_V7.

This is not good when someone wants to create a minimal kernel build, so let multi_v7_defconfig select ARCH_VEXPRESS instead.

This patch solves one aspect of a problem previously discussed for !MMU [1], but we still have the dependency of ARCH_MULTI_V7 for ARCH_VEXPRESS. ARCH_MULTI_V7 doesn't make very much sense without an MMU because we need to hardcode things like PHYS_OFFSET and the vectors.

Looking back though the log, I can't see quite why we need this dependency. With Fabio's patch that selects ARCH_VEXPRESS in the defconfig, is it still required?

How do people feel about something like the patch below, to allow NOMMU things to use Versatile Express without MULTI_V7?

Jonny [1]http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129976.html

-----8<-----------

arch/arm/mach-vexpress/Kconfig +1 -1
index c952960..7d3fff4 100644
@@ -1,5 +1,5 @@
 config ARCH_VEXPRESS
-       bool "ARM Ltd. Versatile Express family" if ARCH_MULTI_V7
+       bool "ARM Ltd. Versatile Express family" if (ARCH_MULTI_V7 || !MMU)
        select ARCH_WANT_OPTIONAL_GPIOLIB
        select ARM_AMBA
        select ARM_GIC
#5 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

In reply to Fabio Estevam

arch/arm/kernel/vmlinux.lds.S SECTIONS · line 315

Quoted 11 lines · Fabio Estevam
arch/arm/kernel/vmlinux.lds.S +2 -0
index b9f38e3..aa46be8 100644
@@ -310,4 +310,6 @@ SECTIONS
  * binutils is too old (for other reasons as well)
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
+#ifndef CONFIG_ARCH_MULTIPLATFORM
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+#endif

This is wrong. So you want a kernel build which produces an unbootable kernel (because it contains absolutely no platform support of any kind, not even any DT platform support) to succeed?

#6 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

Quoted 16 lines · Russell King - ARM Linux

arch/arm/kernel/vmlinux.lds.S SECTIONS · line 315

Quoted 11 lines · Fabio Estevam
arch/arm/kernel/vmlinux.lds.S +2 -0
index b9f38e3..aa46be8 100644
@@ -310,4 +310,6 @@ SECTIONS
  * binutils is too old (for other reasons as well)
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
+#ifndef CONFIG_ARCH_MULTIPLATFORM
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+#endif

This is wrong. So you want a kernel build which produces an unbootable kernel (because it contains absolutely no platform support of any kind, not even any DT platform support) to succeed?

Ok, what about the first version?
https://patchwork.kernel.org/patch/1774521/

Regards,

Fabio Estevam

#7 lore raw

PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7

Quoted 19 lines · Fabio Estevam
Quoted 16 lines · Russell King - ARM Linux

arch/arm/kernel/vmlinux.lds.S SECTIONS · line 315

Quoted 11 lines · Fabio Estevam
arch/arm/kernel/vmlinux.lds.S +2 -0
index b9f38e3..aa46be8 100644
@@ -310,4 +310,6 @@ SECTIONS
  * binutils is too old (for other reasons as well)
  */
 ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
+#ifndef CONFIG_ARCH_MULTIPLATFORM
 ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
+#endif

This is wrong. So you want a kernel build which produces an unbootable kernel (because it contains absolutely no platform support of any kind, not even any DT platform support) to succeed?

Quoted 2 lines

Ok, what about the first version?
https://patchwork.kernel.org/patch/1774521/

That seems to be better because it leaves the desire for an unbootable kernel to be a build failure.

However, it allows the multi-platform case to end up with a configuration where such a kernel can be generated, which is something Arnd wants to avoid as it messes up allnoconfig and randconfig builds.

What we need to come up with is some kind of "default platform" which is always built into the kernel. Will had some ideas about that for the virtualization stuff, but I think there were objections to that over it being modelled on Versatile Express. If that can be sorted, then we have a solution to this problem.

We _should_ be aiming to get to that state anyway, where the kernel doesn't need to know about platform X, Y or Z but just uses the description in DT which tells it where devices A, B, and C are and how they relate to the rest of the system.