ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7
Subsystems (3)
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
@@ -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
@@ -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
@@ -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
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 unselectARCH_VEXPRESSdue to the fact that it is automatically selected byARCH_MULTI_V7.This is not good when someone wants to create a minimal kernel build, so let
multi_v7_defconfigselectARCH_VEXPRESSinstead.
Quoted 6 lines
Also avoid build breakage when randconfig selects no platform.
Signed-off-by Fabio Estevam <[email protected]>---
Changes since v1:
- Avoid build breakage on randconfig for the case that no platform is selected.
Does this version look good?
Regards,
Fabio Estevam
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 unselectARCH_VEXPRESSdue to the fact that it is automatically selected byARCH_MULTI_V7.This is not good when someone wants to create a minimal kernel build, so let
multi_v7_defconfigselectARCH_VEXPRESSinstead.
Quoted 8 lines
Quoted 6 lines
Also avoid build breakage when randconfig selects no platform.
Signed-off-by Fabio Estevam <[email protected]>---
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
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.
Acked-by Rob Herring <[email protected]>
Should I submit this one to the patch system?
Regards,
Fabio Estevam
PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7
In reply to Fabio EstevamQuoted 7 lines · Fabio Estevam
From: Fabio Estevam <[email protected]>
When building a kernel using
imx_v6_v7_defconfig, it is not possible to unselectARCH_VEXPRESSdue to the fact that it is automatically selected byARCH_MULTI_V7.This is not good when someone wants to create a minimal kernel build, so let
multi_v7_defconfigselectARCH_VEXPRESSinstead.
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
@@ -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
PATCH v2 1/1 ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7
In reply to Fabio Estevamarch/arm/kernel/vmlinux.lds.S SECTIONS · line 315
Quoted 11 lines · Fabio Estevam
arch/arm/kernel/vmlinux.lds.S +2
-0@@ -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?
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@@ -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") +#endifThis 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
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@@ -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") +#endifThis 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.