The current allmodconfig kernel boot fails on OMAP4460. There
are several configuration options that can only work on a subset
of the available machines, and enabling them will break other
machines that may be enabled in a multiplatform kernel.
Now we introduce a CONFIG_ARCH_MULTIPLATFORM_STRICT Kconfig
option that prevent those other options from getting enabled
and get a strict multiplatform kernel.
I am not sure who will pick up this patch set, so I just send
it to [email protected] and rmk.
Xia Kaixu (5):
ARM: introduce a CONFIG_ARCH_MULTIPLATFORM_STRICT Kconfig option
ARM: change the corresponding arm/mach defconfigs
ARM: restrict CPU_BIG_ENDIAN configuration option
ARM: allow errata and XIP options to be enabled without ARCH_MULTIPLATFORM_STRICT
ARM: use early console instead of early debug in allmodconfig kernels
arch/arm/Kconfig | 28 +++++++++++++++++++++-------
arch/arm/Kconfig.debug | 25 ++++++++++++++++++++++++-
arch/arm/configs/bcm2835_defconfig | 1 +
arch/arm/configs/moxart_defconfig | 1 +
arch/arm/configs/s5pv210_defconfig | 1 +
arch/arm/configs/tegra_defconfig | 1 +
arch/arm/mm/Kconfig | 1 +
7 files changed, 50 insertions(+), 8 deletions(-)
--
2.1.1
The current allmodconfig kernel boot fails on OMAP4460. There
are several configuration options that can only work on a subset
of the available machines, and enabling them will break other
machines that may be enabled in a multiplatform kernel.
Now we introduce a CONFIG_ARCH_MULTIPLATFORM_STRICT Kconfig
option that prevent those other options from getting enabled
and get a strict multiplatform kernel.
Signed-off-by: Xia Kaixu <[email protected]>
---
arch/arm/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..50762cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -840,6 +840,20 @@ config ARCH_MULTI_CPU_AUTO
endmenu
+config ARCH_MULTIPLATFORM_STRICT
+ bool "Only allow options that do not break other platforms"
+ depends on ARCH_MULTIPLATFORM
+ default y
+ help
+ There are several configuration options that can only work
+ on a subset of the available machines, and enabling them
+ will break running the kernel on other machines that may be
+ enabled in a multiplatform kernel.
+
+ Enabling ARCH_MULTIPLATFORM_STRICT will prevent those other
+ options from getting enabled, so the kernel should always
+ run on any hardware that is part of the configuration.
+
config ARCH_VIRT
bool "Dummy Virtual Machine" if ARCH_MULTI_V7
select ARM_AMBA
--
2.1.1
The DEBUG_LL will get a dependency on !ARCH_MULTIPLATFORM_STRICT.
So change the corresponding arm/mach defconfigs to disable
ARCH_MULTIPLATFORM_STRICT and avoid break them.
Signed-off-by: Xia Kaixu <[email protected]>
---
arch/arm/configs/bcm2835_defconfig | 1 +
arch/arm/configs/moxart_defconfig | 1 +
arch/arm/configs/s5pv210_defconfig | 1 +
arch/arm/configs/tegra_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 31cb073..e644c8b 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -135,6 +135,7 @@ CONFIG_TEST_KSTRTOX=y
CONFIG_KGDB=y
CONFIG_KGDB_KDB=y
CONFIG_STRICT_DEVMEM=y
+# CONFIG_ARCH_MULTIPLATFORM_STRICT is not set
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
# CONFIG_XZ_DEC_ARM is not set
diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig
index a3cb76c..7ba9343 100644
--- a/arch/arm/configs/moxart_defconfig
+++ b/arch/arm/configs/moxart_defconfig
@@ -140,6 +140,7 @@ CONFIG_DETECT_HUNG_TASK=y
CONFIG_PROVE_LOCKING=y
CONFIG_DMA_API_DEBUG=y
CONFIG_KGDB=y
+# CONFIG_ARCH_MULTIPLATFORM_STRICT is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_8250=y
CONFIG_DEBUG_UART_PHYS=0x98200000
diff --git a/arch/arm/configs/s5pv210_defconfig b/arch/arm/configs/s5pv210_defconfig
index fa98990..bc0cad4 100644
--- a/arch/arm/configs/s5pv210_defconfig
+++ b/arch/arm/configs/s5pv210_defconfig
@@ -67,6 +67,7 @@ CONFIG_DEBUG_INFO=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_ERRORS=y
+# CONFIG_ARCH_MULTIPLATFORM_STRICT is not set
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_S3C_UART=1
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 888fc15..851b80b 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -291,6 +291,7 @@ CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SG=y
+# CONFIG_ARCH_MULTIPLATFORM_STRICT is not set
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
CONFIG_CRYPTO_TWOFISH=y
--
2.1.1
The early debug could break something when booting 'allmodconfig'
kernels. So we use early console instead of early debug.
The early console didn't work yet on OMAP4460 because of missing
earlycon support and I am working on that.
Signed-off-by: Xia Kaixu <[email protected]>
---
arch/arm/Kconfig.debug | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 03dc4c1..897e4ab 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -78,7 +78,7 @@ config DEBUG_USER
# These options are only for real kernel hackers who want to get their hands dirty.
config DEBUG_LL
bool "Kernel low-level debugging functions (read help!)"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !ARCH_MULTIPLATFORM_STRICT
help
Say Y here to include definitions of printascii, printch, printhex
in the kernel. This is helpful if you are debugging code that
@@ -1297,6 +1297,29 @@ config EARLY_PRINTK
kernel low-level debugging functions. Add earlyprintk to your
kernel parameters to enable this console.
+config FORCE_EARLY_CONSOLE
+ bool "Enable all early console drivers"
+ depends on DEBUG_KERNEL && ARCH_MULTIPLATFORM_STRICT
+ select TTY
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select SERIAL_AMBA_PL011
+ select SERIAL_AMBA_PL011_CONSOLE
+ select SERIAL_EARLYCON_ARM_SEMIHOST
+ select SERIAL_MSM
+ select SERIAL_MSM_CONSOLE
+ select SERIAL_XILINX_PS_UART
+ select SERIAL_XILINX_PS_UART_CONSOLE
+ help
+ On strict multiplatform configurations, the early debug code
+ is not available, so the early console code should be used
+ for debugging the startup code.
+ This option ensures that all of the earlycon drivers are enabled,
+ which is mainly useful for booting 'allmodconfig' kernels.
+
+ It is always safe to say 'N' here for a smaller kernel and to
+ select the required options individually.
+
config OC_ETM
bool "On-chip ETM and ETB"
depends on ARM_AMBA
--
2.1.1
With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to
enable the ERRATA options when we know at configuration time that we
don't care about the generic case. The previous configuration makes
XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still
valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and
selecting only the one machine that you want to run on.
So allow ARM_ERRATA and XIP_KERNEL options to be enabled without
ARCH_MULTIPLATFORM_STRICT.
Signed-off-by: Xia Kaixu <[email protected]>
---
arch/arm/Kconfig | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 50762cc..14d0dce 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1091,7 +1091,7 @@ config ARM_ERRATA_430973
config ARM_ERRATA_458693
bool "ARM errata: Processor deadlock when a false hazard is created"
depends on CPU_V7
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 458693 Cortex-A8 (r2p0)
erratum. For very specific sequences of memory operations, it is
@@ -1105,7 +1105,7 @@ config ARM_ERRATA_458693
config ARM_ERRATA_460075
bool "ARM errata: Data written to the L2 cache can be overwritten with stale data"
depends on CPU_V7
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 460075 Cortex-A8 (r2p0)
erratum. Any asynchronous access to the L2 cache may encounter a
@@ -1118,7 +1118,7 @@ config ARM_ERRATA_460075
config ARM_ERRATA_742230
bool "ARM errata: DMB operation may be faulty"
depends on CPU_V7 && SMP
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 742230 Cortex-A9
(r1p0..r2p2) erratum. Under rare circumstances, a DMB instruction
@@ -1131,7 +1131,7 @@ config ARM_ERRATA_742230
config ARM_ERRATA_742231
bool "ARM errata: Incorrect hazard handling in the SCU may lead to data corruption"
depends on CPU_V7 && SMP
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 742231 Cortex-A9
(r2p0..r2p2) erratum. Under certain conditions, specific to the
@@ -1168,7 +1168,7 @@ config ARM_ERRATA_720789
config ARM_ERRATA_743622
bool "ARM errata: Faulty hazard checking in the Store Buffer may lead to data corruption"
depends on CPU_V7
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 743622 Cortex-A9
(r2p*) erratum. Under very rare conditions, a faulty
@@ -1182,7 +1182,7 @@ config ARM_ERRATA_743622
config ARM_ERRATA_751472
bool "ARM errata: Interrupted ICIALLUIS may prevent completion of broadcasted operation"
depends on CPU_V7
- depends on !ARCH_MULTIPLATFORM
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
This option enables the workaround for the 751472 Cortex-A9 (prior
to r3p0) erratum. An interrupted ICIALLUIS operation may prevent the
@@ -1987,7 +1987,7 @@ endchoice
config XIP_KERNEL
bool "Kernel Execute-In-Place from ROM"
- depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+ depends on !ARM_LPAE && !ARCH_MULTIPLATFORM_STRICT
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
--
2.1.1
Some platforms don't work when CPU_BIG_ENDIAN is enabled.
So It can get a dependency on !ARCH_MULTIPLATFORM_STRICT.
Signed-off-by: Xia Kaixu <[email protected]>
---
arch/arm/mm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index ae69809..d510448 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -698,6 +698,7 @@ config SWP_EMULATE
config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
depends on ARCH_SUPPORTS_BIG_ENDIAN
+ depends on !ARCH_MULTIPLATFORM_STRICT
help
Say Y if you plan on running a kernel in big-endian mode.
Note that your board must be properly built and your board
--
2.1.1
On Tue, Oct 28, 2014 at 09:31:33PM +0800, Xia Kaixu wrote:
> Some platforms don't work when CPU_BIG_ENDIAN is enabled.
> So It can get a dependency on !ARCH_MULTIPLATFORM_STRICT.
What if big endian wants to build a multiplatform kernel?
This doesn't look right to me. Instead, we should be arranging for
those which do not work in BE mode to depend on !CPU_BIG_ENDIAN.
Yes, it's a larger patch but IMHO is a much more correct solution.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote:
> With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to
> enable the ERRATA options when we know at configuration time that we
> don't care about the generic case. The previous configuration makes
> XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still
> valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and
> selecting only the one machine that you want to run on.
XIP_KERNEL isn't supported on anything past ARMv5 though.
I don't like the case for errata though - we want these errata to be
handled by the board firmware, not by the kernel, and we don't want
to make it any easier for people to ignore that fact.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tue, Oct 28, 2014 at 09:31:35PM +0800, Xia Kaixu wrote:
> The early debug could break something when booting 'allmodconfig'
> kernels. So we use early console instead of early debug.
>
> The early console didn't work yet on OMAP4460 because of missing
> earlycon support and I am working on that.
No. bloody. way.
> @@ -78,7 +78,7 @@ config DEBUG_USER
> # These options are only for real kernel hackers who want to get their hands dirty.
> config DEBUG_LL
> bool "Kernel low-level debugging functions (read help!)"
> - depends on DEBUG_KERNEL
> + depends on DEBUG_KERNEL && !ARCH_MULTIPLATFORM_STRICT
Firstly, this is well advertised that it can only be applied to a single
configuration. So I don't think we need this dependency here. Even if
you want to build a strict multiplatform kernel, it should still be
possible to enable this for a specific platform.
It's a developer option, one which requires the developer to engage their
brain before using.
> @@ -1297,6 +1297,29 @@ config EARLY_PRINTK
> kernel low-level debugging functions. Add earlyprintk to your
> kernel parameters to enable this console.
>
> +config FORCE_EARLY_CONSOLE
> + bool "Enable all early console drivers"
> + depends on DEBUG_KERNEL && ARCH_MULTIPLATFORM_STRICT
> + select TTY
> + select SERIAL_8250
> + select SERIAL_8250_CONSOLE
> + select SERIAL_AMBA_PL011
> + select SERIAL_AMBA_PL011_CONSOLE
> + select SERIAL_EARLYCON_ARM_SEMIHOST
> + select SERIAL_MSM
> + select SERIAL_MSM_CONSOLE
> + select SERIAL_XILINX_PS_UART
> + select SERIAL_XILINX_PS_UART_CONSOLE
Not only will this be a for-ever expanding list, but it'll also continually
suffer from various problems with dependencies. I absolutely *HATE* the
idea of selecting user visible options like this.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tuesday 28 October 2014 21:31:31 Xia Kaixu wrote:
> endmenu
>
> +config ARCH_MULTIPLATFORM_STRICT
> + bool "Only allow options that do not break other platforms"
> + depends on ARCH_MULTIPLATFORM
> + default y
> + help
> + There are several configuration options that can only work
>
Something seems to be wrong with the whitespace here. Please use tab
characters for indentation like we do elsewhere in the file.
Otherwise looks good, I think this is a good step in the right direction.
Arnd
On Tue, Oct 28, 2014 at 03:18:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 21:31:31 Xia Kaixu wrote:
> > endmenu
> >
> > +config ARCH_MULTIPLATFORM_STRICT
> > + bool "Only allow options that do not break other platforms"
> > + depends on ARCH_MULTIPLATFORM
> > + default y
> > + help
> > + There are several configuration options that can only work
> >
>
> Something seems to be wrong with the whitespace here. Please use tab
> characters for indentation like we do elsewhere in the file.
>
> Otherwise looks good, I think this is a good step in the right direction.
I totally disagree. I've raised individual objections on all uses of
this new symbol in separate emails.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote:
> > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to
> > enable the ERRATA options when we know at configuration time that we
> > don't care about the generic case. The previous configuration makes
> > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still
> > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and
> > selecting only the one machine that you want to run on.
>
> XIP_KERNEL isn't supported on anything past ARMv5 though.
I would really like to get some of the platforms that currently use
XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them
is EFM32, which is ARMv7-M.
> I don't like the case for errata though - we want these errata to be
> handled by the board firmware, not by the kernel, and we don't want
> to make it any easier for people to ignore that fact.
Ok, fair enough.
Arnd
On Tuesday 28 October 2014 14:05:36 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 09:31:35PM +0800, Xia Kaixu wrote:
> > The early debug could break something when booting 'allmodconfig'
> > kernels. So we use early console instead of early debug.
> >
> > The early console didn't work yet on OMAP4460 because of missing
> > earlycon support and I am working on that.
>
> No. bloody. way.
>
> > @@ -78,7 +78,7 @@ config DEBUG_USER
> > # These options are only for real kernel hackers who want to get their hands dirty.
> > config DEBUG_LL
> > bool "Kernel low-level debugging functions (read help!)"
> > - depends on DEBUG_KERNEL
> > + depends on DEBUG_KERNEL && !ARCH_MULTIPLATFORM_STRICT
>
> Firstly, this is well advertised that it can only be applied to a single
> configuration. So I don't think we need this dependency here. Even if
> you want to build a strict multiplatform kernel, it should still be
> possible to enable this for a specific platform.
I've asked Kaixu to do this patch. This is one of the most fundamental
uses of ARCH_MULTIPLATFORM_STRICT: as soon as you turn on DEBUG_LL, the
kernel no longer runs on any other platform, so it can still be built
as a multiplatform kernel, but not a "strict" one that is known to
work on all hardware that is enabled.
> It's a developer option, one which requires the developer to engage their
> brain before using.
Exactly, and I think it's not asking too much from a developer to turn
off ARCH_MULTIPLATFORM_STRICT if they want to turn on DEBUG_LL. Nothing
else should change if you do that.
The main use of the symbol is really to avoid turning on DEBUG_LL is
allmodconfig kernels, which will always enable ARCH_MULTIPLATFORM_STRICT.
Arnd
On Tue, Oct 28, 2014 at 03:24:38PM +0100, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote:
> > On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote:
> > > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to
> > > enable the ERRATA options when we know at configuration time that we
> > > don't care about the generic case. The previous configuration makes
> > > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still
> > > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and
> > > selecting only the one machine that you want to run on.
> >
> > XIP_KERNEL isn't supported on anything past ARMv5 though.
>
> I would really like to get some of the platforms that currently use
> XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them
> is EFM32, which is ARMv7-M.
Right, and on ARMv7-M, the restrictions against XIP_KERNEL don't apply.
The restrictions on XIP_KERNEL only apply with MMU-full kernels, because
of the remapping needed - the kernel is executed from flash, which is
mapped separately, and that mapping needs to be setup in order to turn
the MMU on.
With ARMv7-M, there is no MMU to worry about, no other mappings are
required, so there is no special platform specific setup applicable.
So, I don't see any reason why XIP_KERNEL can't depend on
!ARCH_MULTIPLATFORM || CPU_V7M.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tue, Oct 28, 2014 at 03:29:01PM +0100, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 14:05:36 Russell King - ARM Linux wrote:
> > On Tue, Oct 28, 2014 at 09:31:35PM +0800, Xia Kaixu wrote:
> > > The early debug could break something when booting 'allmodconfig'
> > > kernels. So we use early console instead of early debug.
> > >
> > > The early console didn't work yet on OMAP4460 because of missing
> > > earlycon support and I am working on that.
> >
> > No. bloody. way.
> >
> > > @@ -78,7 +78,7 @@ config DEBUG_USER
> > > # These options are only for real kernel hackers who want to get their hands dirty.
> > > config DEBUG_LL
> > > bool "Kernel low-level debugging functions (read help!)"
> > > - depends on DEBUG_KERNEL
> > > + depends on DEBUG_KERNEL && !ARCH_MULTIPLATFORM_STRICT
> >
> > Firstly, this is well advertised that it can only be applied to a single
> > configuration. So I don't think we need this dependency here. Even if
> > you want to build a strict multiplatform kernel, it should still be
> > possible to enable this for a specific platform.
>
> I've asked Kaixu to do this patch. This is one of the most fundamental
> uses of ARCH_MULTIPLATFORM_STRICT: as soon as you turn on DEBUG_LL, the
> kernel no longer runs on any other platform, so it can still be built
> as a multiplatform kernel, but not a "strict" one that is known to
> work on all hardware that is enabled.
No, that is not correct. You can turn on DEBUG_LL, and a multiplatform
kernel will still run.
The point at which it won't run is if you call the DEBUG_LL function on
a platform it wasn't configured for. That happens if you start using
the printascii() et.al. functions, or (against my better judgement) the
early console support is enabled.
So, as the early console support went against my wishes there, I see
this problem as more of an early console problem than a DEBUG_LL problem.
> Exactly, and I think it's not asking too much from a developer to turn
> off ARCH_MULTIPLATFORM_STRICT if they want to turn on DEBUG_LL. Nothing
> else should change if you do that.
>
> The main use of the symbol is really to avoid turning on DEBUG_LL is
> allmodconfig kernels, which will always enable ARCH_MULTIPLATFORM_STRICT.
It's pointless if that's all that ARCH_MULTIPLATFORM_STRICT ends up
doing. It just needlessly adds extra configuration options. There's
already thousands of kernel options, we don't need any more stupid
idiotic options to clutter the already densely populated forest, and
make it yet harder to work out wtf we're doing with all these options.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tuesday 28 October 2014 14:00:22 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 09:31:33PM +0800, Xia Kaixu wrote:
> > Some platforms don't work when CPU_BIG_ENDIAN is enabled.
> > So It can get a dependency on !ARCH_MULTIPLATFORM_STRICT.
>
> What if big endian wants to build a multiplatform kernel?
They can turn off ARCH_MULTIPLATFORM_STRICT easily.
> This doesn't look right to me. Instead, we should be arranging for
> those which do not work in BE mode to depend on !CPU_BIG_ENDIAN.
> Yes, it's a larger patch but IMHO is a much more correct solution.
I've also asked Kaixu to put this one in, mostly for the side-effect
of getting an allmodconfig kernel to be little-endian, but also
because we don't really know which platforms are ok to run on
big-endian. I would assume that most platforms have at least some
platform-specific drivers that are not endian-clean, and even if
the platform works big-endian in principle, it's unclear if
everything works.
The most important aspect is probably user space though: If you
build a multiplatform kernel (or one for ARMv4/5 and one for ARMv6/7)
that runs on all sorts of machines, you can have a common user space
that is built for ARMv4 little-endian and that will run everywhere.
As soon as you enable big-endian, you have a fundamental ABI change
and nothing works unless you replace the entire user space side.
Arnd
On Tuesday 28 October 2014 14:31:18 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 03:24:38PM +0100, Arnd Bergmann wrote:
> > On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote:
> > > On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote:
> > > > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to
> > > > enable the ERRATA options when we know at configuration time that we
> > > > don't care about the generic case. The previous configuration makes
> > > > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still
> > > > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and
> > > > selecting only the one machine that you want to run on.
> > >
> > > XIP_KERNEL isn't supported on anything past ARMv5 though.
> >
> > I would really like to get some of the platforms that currently use
> > XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them
> > is EFM32, which is ARMv7-M.
>
> Right, and on ARMv7-M, the restrictions against XIP_KERNEL don't apply.
> The restrictions on XIP_KERNEL only apply with MMU-full kernels, because
> of the remapping needed - the kernel is executed from flash, which is
> mapped separately, and that mapping needs to be setup in order to turn
> the MMU on.
>
> With ARMv7-M, there is no MMU to worry about, no other mappings are
> required, so there is no special platform specific setup applicable.
>
> So, I don't see any reason why XIP_KERNEL can't depend on
> !ARCH_MULTIPLATFORM || CPU_V7M.
That would solve the problem for V7M, but I also don't see a reason
to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM.
The main problem is that any ARMv4/v5 platform that currently uses
XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and
I think that is bad.
The same applies to ZBOOT_ROM, which we should probably treat the
same way here. An example for that is the Renesas SH-Mobile SH7372 that
can boot directly from MMC. I really want Renesas to convert
all of their SH-Mobile machines to multiplatform, just like all other
ARMv7 platforms. There is nothing preventing you from running a
multiplatform kernel on SH7372 as long as you don't want to load the
kernel from MMC without a proper bootloader. I also don't see a reason
to take out that feature just because they are migrating to multiplatform
(there may or may not be other reasons to deprecate this feature, but that
is a different matter). At the moment SH-Mobile can be built either
as a standalone platform or as multiplatform, but even now you can build
a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on
SH7372 but includes all other shmobile targets as well.
I don't see anything wrong with that, and I would like to see this
keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the
same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent
this from being selected for a kernel that is supposed to run everywhere.
Arnd
On Tue, Oct 28, 2014 at 03:37:52PM +0100, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 14:00:22 Russell King - ARM Linux wrote:
> > On Tue, Oct 28, 2014 at 09:31:33PM +0800, Xia Kaixu wrote:
> > > Some platforms don't work when CPU_BIG_ENDIAN is enabled.
> > > So It can get a dependency on !ARCH_MULTIPLATFORM_STRICT.
> >
> > What if big endian wants to build a multiplatform kernel?
>
> They can turn off ARCH_MULTIPLATFORM_STRICT easily.
Why should they? Building a kernel for a group of big endian platforms
is no different from building the kernel for a group of little endian
platforms.
Look, think about the set. There are three distinct possibilities.
1. The group of platforms which can be big endian.
2. The group of platforms which can be little endian.
3. The intersection of both groups which can be either endian.
Why should ARCH_MULTIPLATFORM_STRICT effectively platforms falling in
set 1 from being built? What's special about them? The answer is,
absolutely nothing. This has /nothing/ what so ever to do with
multiplatform-ness.
What it does have to do with is whether the platforms can be built with
one endian-ness or the other. That's why I said:
> > This doesn't look right to me. Instead, we should be arranging for
> > those which do not work in BE mode to depend on !CPU_BIG_ENDIAN.
> > Yes, it's a larger patch but IMHO is a much more correct solution.
which means that the platforms which are part of a multiplatform kernel
need to depend on CPU_BIG_ENDIAN, !CPU_BIG_ENDIAN, or nothing depending
on which of the three groups above they belong to.
Making them depend on some weird new "strict" idea is soo absurd it's
broken. It's not looking at the real picture here.
> I've also asked Kaixu to put this one in, mostly for the side-effect
> of getting an allmodconfig kernel to be little-endian, but also
> because we don't really know which platforms are ok to run on
> big-endian.
Why should an allmodconfig kernel be little endian? It's just as valid
to have an allmodconfig big endian kernel.
> I would assume that most platforms have at least some
> platform-specific drivers that are not endian-clean, and even if
> the platform works big-endian in principle, it's unclear if
> everything works.
Right, which means we start off with everything falling into sets (1) or
(2) initially, and if people care about the "either" case, that's up for
them to sort out. Generally, what people care about are the first two
cases, because they specifically intend to run their platform in BE or
LE mode.
It is /very/ rare to decide to switch endianness on a platform from day
to day.
> The most important aspect is probably user space though: If you
> build a multiplatform kernel (or one for ARMv4/5 and one for ARMv6/7)
> that runs on all sorts of machines, you can have a common user space
> that is built for ARMv4 little-endian and that will run everywhere.
> As soon as you enable big-endian, you have a fundamental ABI change
> and nothing works unless you replace the entire user space side.
Correct, which is why people would want to build a _single_ ARMv6/v7
big endian kernel covering multiple platforms, in exactly the same
way that they would build a _single_ ARMv6/v7 little endian kernel
covering multiple platforms.
There's nothing "strict" about either case.
Look at it from the opposite point of view. If you want to build a
multiplatform ARMv6/v7 BE kernel, and you turn off the big endian
option, is that no different from wanting to build a multiplatform
ARMv6/v7 LE kernel, and turning on the big endian option.
There's really no difference between these two cases.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tuesday 28 October 2014 14:35:36 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 03:29:01PM +0100, Arnd Bergmann wrote:
> > On Tuesday 28 October 2014 14:05:36 Russell King - ARM Linux wrote:
> > > On Tue, Oct 28, 2014 at 09:31:35PM +0800, Xia Kaixu wrote:
> > > > The early debug could break something when booting 'allmodconfig'
> > > > kernels. So we use early console instead of early debug.
> > > >
> > > > The early console didn't work yet on OMAP4460 because of missing
> > > > earlycon support and I am working on that.
> > >
> > > No. bloody. way.
> > >
> > > > @@ -78,7 +78,7 @@ config DEBUG_USER
> > > > # These options are only for real kernel hackers who want to get their hands dirty.
> > > > config DEBUG_LL
> > > > bool "Kernel low-level debugging functions (read help!)"
> > > > - depends on DEBUG_KERNEL
> > > > + depends on DEBUG_KERNEL && !ARCH_MULTIPLATFORM_STRICT
> > >
> > > Firstly, this is well advertised that it can only be applied to a single
> > > configuration. So I don't think we need this dependency here. Even if
> > > you want to build a strict multiplatform kernel, it should still be
> > > possible to enable this for a specific platform.
> >
> > I've asked Kaixu to do this patch. This is one of the most fundamental
> > uses of ARCH_MULTIPLATFORM_STRICT: as soon as you turn on DEBUG_LL, the
> > kernel no longer runs on any other platform, so it can still be built
> > as a multiplatform kernel, but not a "strict" one that is known to
> > work on all hardware that is enabled.
>
> No, that is not correct. You can turn on DEBUG_LL, and a multiplatform
> kernel will still run.
>
> The point at which it won't run is if you call the DEBUG_LL function on
> a platform it wasn't configured for. That happens if you start using
> the printascii() et.al. functions, or (against my better judgement) the
> early console support is enabled.
>
> So, as the early console support went against my wishes there, I see
> this problem as more of an early console problem than a DEBUG_LL problem.
Good point, yes.
What about DEBUG_UNCOMPRESS then? It is currently defined as
config DEBUG_UNCOMPRESS
bool
depends on ARCH_MULTIPLATFORM || ARCH_MSM || PLAT_SAMSUNG
default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
(!DEBUG_TEGRA_UART || !ZBOOT_ROM)
so it will be turned on implicitly when DEBUG_LL is set on a
multiplatform kernel. Doesn't that cause an external abort or similar
as soon as you start writing to some random physical address from the
decompressor when running on the wrong platform?
Arnd
On Tue, Oct 28, 2014 at 03:50:31PM +0100, Arnd Bergmann wrote:
> That would solve the problem for V7M, but I also don't see a reason
> to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM.
>
> The main problem is that any ARMv4/v5 platform that currently uses
> XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and
> I think that is bad.
>
> The same applies to ZBOOT_ROM, which we should probably treat the
> same way here. An example for that is the Renesas SH-Mobile SH7372 that
> can boot directly from MMC. I really want Renesas to convert
> all of their SH-Mobile machines to multiplatform, just like all other
> ARMv7 platforms. There is nothing preventing you from running a
> multiplatform kernel on SH7372 as long as you don't want to load the
> kernel from MMC without a proper bootloader. I also don't see a reason
> to take out that feature just because they are migrating to multiplatform
> (there may or may not be other reasons to deprecate this feature, but that
> is a different matter). At the moment SH-Mobile can be built either
> as a standalone platform or as multiplatform, but even now you can build
> a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on
> SH7372 but includes all other shmobile targets as well.
>
> I don't see anything wrong with that, and I would like to see this
> keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the
> same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent
> this from being selected for a kernel that is supposed to run everywhere.
What you're asking for is a multiplatform kernel which can't be run on
multiple platforms. Think about that for a while.
If you're going to be building an ARMv5 XIP kernel, then it needs to only
include support for the ARMv5 SoC which you are targetting. It's no good
to think "oh, we can then include other ARMv5 SoCs too" - you can, but
the kernel will never run there.
That's where the pre-multiplatform setup works well - it ensures that the
correct dependencies are there. What we need to do is to combine these
two properly such that if you want to build with a feature which limits
you to one SoC, then the kernel configuration limits you to exactly that.
That's not done by making some magic Kconfig option which disables a load
of dependencies but still lets you chuck lots of useless stuff in together.
In any case, the thought of an XIP kernel with an allmodconfig config
rather misses one of the fundamental problems with XIP multiplatform. If
you /ever/ want to write to the flash which the XIP kernel is contained,
you must move the interrupt handling code out into RAM, so that when an
interrupt happens, you can talk to the flash chip to make the kernel
readable again. That takes *all* of the initial interrupt handling code
and data into RAM.
What that means is that our current IRQ multi-handler solution doesn't
work there - and we need a set of platform specific assembly fragments
to do this.
As I said previously, there's also the complexity in setting up the XIP
mappings in the assembly code, which takes quite an amount of knowledge
of the physical memory layout on the SoC.
Frankly, I think the idea of XIP and multiplatform is a pipedream.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Tuesday 28 October 2014 15:05:21 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 03:50:31PM +0100, Arnd Bergmann wrote:
> > That would solve the problem for V7M, but I also don't see a reason
> > to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM.
> >
> > The main problem is that any ARMv4/v5 platform that currently uses
> > XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and
> > I think that is bad.
> >
> > The same applies to ZBOOT_ROM, which we should probably treat the
> > same way here. An example for that is the Renesas SH-Mobile SH7372 that
> > can boot directly from MMC. I really want Renesas to convert
> > all of their SH-Mobile machines to multiplatform, just like all other
> > ARMv7 platforms. There is nothing preventing you from running a
> > multiplatform kernel on SH7372 as long as you don't want to load the
> > kernel from MMC without a proper bootloader. I also don't see a reason
> > to take out that feature just because they are migrating to multiplatform
> > (there may or may not be other reasons to deprecate this feature, but that
> > is a different matter). At the moment SH-Mobile can be built either
> > as a standalone platform or as multiplatform, but even now you can build
> > a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on
> > SH7372 but includes all other shmobile targets as well.
> >
> > I don't see anything wrong with that, and I would like to see this
> > keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the
> > same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent
> > this from being selected for a kernel that is supposed to run everywhere.
>
> What you're asking for is a multiplatform kernel which can't be run on
> multiple platforms. Think about that for a while.
>
> If you're going to be building an ARMv5 XIP kernel, then it needs to only
> include support for the ARMv5 SoC which you are targetting. It's no good
> to think "oh, we can then include other ARMv5 SoCs too" - you can, but
> the kernel will never run there.
>
> That's where the pre-multiplatform setup works well - it ensures that the
> correct dependencies are there. What we need to do is to combine these
> two properly such that if you want to build with a feature which limits
> you to one SoC, then the kernel configuration limits you to exactly that.
> That's not done by making some magic Kconfig option which disables a load
> of dependencies but still lets you chuck lots of useless stuff in together.
Part of the underlying problem here is really that Kconfig isn't able
to express the set of dependencies. It already fails to do that for
a platform that supports multiple boards and you want to build an XIP
kernel for one of the boards.
What you would want to express is that either
- as soon as XIP_KERNEL is set, you can only enable boards that have
the exact same ROM address for running the kernel from (usually
just one board), or
- the XIP_KERNEL option disappears when you enable multiple boards
that are mutually incompatible whenever XIP is enabled.
We don't do either at the moment, and I've tried to come up with
a way to express this in Kconfig and haven't found one. Allowing
the multiple mach-* directories to behave the same way as multiple
boards in a single platform do today is not a fundamental change,
but more a consequence of generally being able to build them together.
> In any case, the thought of an XIP kernel with an allmodconfig config
> rather misses one of the fundamental problems with XIP multiplatform.
I never said anything about running an XIP kernel with allmodconfig,
or even an XIP kernel with more than one platform enabled. What I want
is to be able to turn on XIP_KERNEL in a configuration that has exactly
one machine enabled, but not requiring that machine to have a separate
entry in the "ARM system type" choice statement.
The fact that it allows one to also set silly configurations is unfortunate,
but there are lots of silly configurations that one can enable today.
> If you /ever/ want to write to the flash which the XIP kernel is contained,
> you must move the interrupt handling code out into RAM, so that when an
> interrupt happens, you can talk to the flash chip to make the kernel
> readable again. That takes *all* of the initial interrupt handling code
> and data into RAM.
>
> What that means is that our current IRQ multi-handler solution doesn't
> work there - and we need a set of platform specific assembly fragments
> to do this.
This would be imply ARCH_MTD_XIP, which is currently not allowed for
anything that is part of ARCH_MULTIPLATFORM, and this patch doesn't
change that. If we ever want to allow it, I think you are right
that it would require significant extra work for abstracting xip_irqpending,
xip_currtime, xip_elapsed_since and xip_cpu_idle to build with more
than one platform enabled.
> As I said previously, there's also the complexity in setting up the XIP
> mappings in the assembly code, which takes quite an amount of knowledge
> of the physical memory layout on the SoC.
>
> Frankly, I think the idea of XIP and multiplatform is a pipedream.
What about MMU-less systems then? The underlying problem is similar:
when we converted ARCH_VEXPRESS to multiplatform, we lost the ability
to run the Cortex-R4 tiles, or to run the ARMv7-A tiles with the MMU
disabled, which apparently were either working out of the box, or
required only a small set of patches on top.
Arnd
On Tuesday 28 October 2014 14:53:19 Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 03:37:52PM +0100, Arnd Bergmann wrote:
> > On Tuesday 28 October 2014 14:00:22 Russell King - ARM Linux wrote:
> > > On Tue, Oct 28, 2014 at 09:31:33PM +0800, Xia Kaixu wrote:
> > > > Some platforms don't work when CPU_BIG_ENDIAN is enabled.
> > > > So It can get a dependency on !ARCH_MULTIPLATFORM_STRICT.
> > >
> > > What if big endian wants to build a multiplatform kernel?
> >
> > They can turn off ARCH_MULTIPLATFORM_STRICT easily.
>
> Why should they? Building a kernel for a group of big endian platforms
> is no different from building the kernel for a group of little endian
> platforms.
>
> Look, think about the set. There are three distinct possibilities.
>
> 1. The group of platforms which can be big endian.
> 2. The group of platforms which can be little endian.
> 3. The intersection of both groups which can be either endian.
>
> Why should ARCH_MULTIPLATFORM_STRICT effectively platforms falling in
> set 1 from being built? What's special about them? The answer is,
> absolutely nothing. This has /nothing/ what so ever to do with
> multiplatform-ness.
It's an empty set at the moment. Nobody has built an ARM CPU core that
is big-endian only, at least none that we support.
All platforms support little-endian, and some platforms have at least
some drivers that work when building for big-endian.
> What it does have to do with is whether the platforms can be built with
> one endian-ness or the other. That's why I said:
>
> > > This doesn't look right to me. Instead, we should be arranging for
> > > those which do not work in BE mode to depend on !CPU_BIG_ENDIAN.
> > > Yes, it's a larger patch but IMHO is a much more correct solution.
>
> which means that the platforms which are part of a multiplatform kernel
> need to depend on CPU_BIG_ENDIAN, !CPU_BIG_ENDIAN, or nothing depending
> on which of the three groups above they belong to.
>
> Making them depend on some weird new "strict" idea is soo absurd it's
> broken. It's not looking at the real picture here.
I prototyped an earlier version of this path that had a
BROKEN_MULTIPLATFORM option with the opposite meaning of
ARCH_MULTIPLATFORM_STRICT. I liked the old naming a little better,
because writing
config MMU
bool "MMU-based Paged Memory Management Support" if !BROKEN_MULTIPLATFORM
default y
seemed to be a clearer wording, but having the positive logic made
it easier to have the defaults I wanted for allmodconfig.
My earlier patch also didn't include CPU_BIG_ENDIAN in the dependencies,
because as you say it's not a hardware dependency, but I still think
it's not too much of a stretch.
> > I've also asked Kaixu to put this one in, mostly for the side-effect
> > of getting an allmodconfig kernel to be little-endian, but also
> > because we don't really know which platforms are ok to run on
> > big-endian.
>
> Why should an allmodconfig kernel be little endian? It's just as valid
> to have an allmodconfig big endian kernel.
Because it would be extremely helpful to be able to test an allmodconfig
kernel easily. I know you can do it with KCONFIG_ALLCONFIG=
but I think it's valuable if a lot of people can do a very simple
test by building an allmodconfig kernel and running it in qemu (or
a random piece of ARMv7 hardware) with their own kernel changes and a
prebuilt user space image that contains the kselftest binaries.
We talked a lot about simplifying this kind of automated regression
testing at the kernel summit, and the main message was to make it
as simple as humanly possible if we want people to run it.
> > I would assume that most platforms have at least some
> > platform-specific drivers that are not endian-clean, and even if
> > the platform works big-endian in principle, it's unclear if
> > everything works.
>
> Right, which means we start off with everything falling into sets (1) or
> (2) initially, and if people care about the "either" case, that's up for
> them to sort out. Generally, what people care about are the first two
> cases, because they specifically intend to run their platform in BE or
> LE mode.
>
> It is /very/ rare to decide to switch endianness on a platform from day
> to day.
The people that are interested in big-endian builds usually just use
a platform that is otherwise used in little-endian mode, and they care
about only a small subset of the drivers, so it's safe to assume that
a large chunk of all ARM specific drivers are broken.
When the goal is testing for regressions, we have to start out with
the largest possible subset of the kernel that actually works.
There is also value in building a big-endian kernel and testing that
on a large set of machines (which Kevin also does with multi_v7_defconfig),
but I don't think it's useful to make that the default.
Arnd