| Message ID | 20180621155906.12821-1-geert+renesas@glider.be |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] arm: Replace "multiple platforms" by "common platform" | expand |
On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > "ARM multiplatform" has actually two meanings: > 1. It groups platforms that follow the "ARM multiplatform" software > framework, > 2. It allows to build a single kernel that can be booted on multiple > platforms. > > Currently support for XIP and/or NOMMU cannot be enabled on platforms > that follow the "ARM multiplatform" framework, without duplicating their > machine selection logic under a new Kconfig symbol. As (in theory) all > platforms can be used with XIP and/or NOMMU, this is not sustainable. The reason for that has nothing to do with the way this option is named, and even after reading your commit message, I can't come up with any reason for this change other than "personally don't like the existing wording" which IMHO is not a good enough reason to randomly go around rewording stuff in the kernel. The reason that XIP and NOMMU can't be enabled with a multi-platform kernel is that there are often issues with different layouts of the physical memory space which can not be taken into account. Multi-platform works around that by (a) using the MMU to abstract away the differences on RAM, and (b) modifying the kernel text to adjust the virtual to physical translations. The latter is not possible with XIP, and the former should not be used with NOMMU. That means the kernel must be built to accomodate the physical layout on the target platform, and so building a kernel supporting multiple platforms with differing memory layouts makes no sense. This is exactly why I really don't like the idea of ARCH_MULTIPLATFORM being hijacked for NOMMU/XIP support. We've worked around the issues with "multi-platform" XIP/NOMMU by using things such as "ARM_SINGLE_V7M" to cover all V7M platforms (which must, by definition) have compatible physical layouts. Exactly the same approach should be adopted for other XIP/NOMMU platforms, and _not_ reusing ARCH_MULTIPLATFORM, which will lead to lots of non-bootable kernels. Another problems for NOMMU is that the kernel has to be linked for a specific _physical_ address. When you have ARCH_MULTIPLATFORM enabled, there is no facility to select that address. Sorry, but reusing ARCH_MULTIPLATFORM is really a non-starter and is confusing.
Hi Russell, Thanks for your comments! On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > > "ARM multiplatform" has actually two meanings: > > 1. It groups platforms that follow the "ARM multiplatform" software > > framework, > > 2. It allows to build a single kernel that can be booted on multiple > > platforms. > > > > Currently support for XIP and/or NOMMU cannot be enabled on platforms > > that follow the "ARM multiplatform" framework, without duplicating their > > machine selection logic under a new Kconfig symbol. As (in theory) all > > platforms can be used with XIP and/or NOMMU, this is not sustainable. > > The reason for that has nothing to do with the way this option is named, > and even after reading your commit message, I can't come up with any > reason for this change other than "personally don't like the existing > wording" which IMHO is not a good enough reason to randomly go around > rewording stuff in the kernel. > > The reason that XIP and NOMMU can't be enabled with a multi-platform > kernel is that there are often issues with different layouts of the > physical memory space which can not be taken into account. > > Multi-platform works around that by (a) using the MMU to abstract > away the differences on RAM, and (b) modifying the kernel text to > adjust the virtual to physical translations. The latter is not > possible with XIP, and the former should not be used with NOMMU. > That means the kernel must be built to accomodate the physical > layout on the target platform, and so building a kernel supporting > multiple platforms with differing memory layouts makes no sense. > > This is exactly why I really don't like the idea of ARCH_MULTIPLATFORM > being hijacked for NOMMU/XIP support. That's multiplatform meaning #2. But as long as MMU=y and XIP_KERNEL=n, nothing would change. > We've worked around the issues with "multi-platform" XIP/NOMMU by > using things such as "ARM_SINGLE_V7M" to cover all V7M platforms > (which must, by definition) have compatible physical layouts. > Exactly the same approach should be adopted for other XIP/NOMMU > platforms, and _not_ reusing ARCH_MULTIPLATFORM, which will lead > to lots of non-bootable kernels. So we need ARM_SINGLE_ARMV7A, and let all subarchitectures depend on ARCH_MULTIPLATFORM || ARM_SINGLE_ARMV7M, to avoid duplicating their SoC entry? I had a quick look. So we have e.g. MACH_STM32F746 under ARM_SINGLE_ARMV7M, and MACH_STM32MP157 under ARCH_MULTI_V7. But according to stm32mp157c-ed1.dts and stm32746g-eval.dts both have memory at the same address, so it should be possible to run the same nommu kernel on the STM32MP157? MACH_STM32F469 is also under ARM_SINGLE_ARMV7M, but according to stm32f469-disco.dts, memory may be at a completely different address? Doesn't that lead to unbootable kernels, too? > Another problems for NOMMU is that the kernel has to be linked for > a specific _physical_ address. When you have ARCH_MULTIPLATFORM > enabled, there is no facility to select that address. That can be easily solved with Kconfig symbols that depend on !MMU, can't it? Gr{oetje,eeting}s, Geert
On Fri, Jun 22, 2018 at 01:41:37PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > Thanks for your comments! > > On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: > > On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > > > "ARM multiplatform" has actually two meanings: > > > 1. It groups platforms that follow the "ARM multiplatform" software > > > framework, > > > 2. It allows to build a single kernel that can be booted on multiple > > > platforms. > > > > > > Currently support for XIP and/or NOMMU cannot be enabled on platforms > > > that follow the "ARM multiplatform" framework, without duplicating their > > > machine selection logic under a new Kconfig symbol. As (in theory) all > > > platforms can be used with XIP and/or NOMMU, this is not sustainable. > > > > The reason for that has nothing to do with the way this option is named, > > and even after reading your commit message, I can't come up with any > > reason for this change other than "personally don't like the existing > > wording" which IMHO is not a good enough reason to randomly go around > > rewording stuff in the kernel. > > > > The reason that XIP and NOMMU can't be enabled with a multi-platform > > kernel is that there are often issues with different layouts of the > > physical memory space which can not be taken into account. > > > > Multi-platform works around that by (a) using the MMU to abstract > > away the differences on RAM, and (b) modifying the kernel text to > > adjust the virtual to physical translations. The latter is not > > possible with XIP, and the former should not be used with NOMMU. > > That means the kernel must be built to accomodate the physical > > layout on the target platform, and so building a kernel supporting > > multiple platforms with differing memory layouts makes no sense. > > > > This is exactly why I really don't like the idea of ARCH_MULTIPLATFORM > > being hijacked for NOMMU/XIP support. > > That's multiplatform meaning #2. > > But as long as MMU=y and XIP_KERNEL=n, nothing would change. > > > We've worked around the issues with "multi-platform" XIP/NOMMU by > > using things such as "ARM_SINGLE_V7M" to cover all V7M platforms > > (which must, by definition) have compatible physical layouts. > > Exactly the same approach should be adopted for other XIP/NOMMU > > platforms, and _not_ reusing ARCH_MULTIPLATFORM, which will lead > > to lots of non-bootable kernels. > > So we need ARM_SINGLE_ARMV7A, and let all subarchitectures depend on > ARCH_MULTIPLATFORM || ARM_SINGLE_ARMV7M, to avoid duplicating > their SoC entry? > > I had a quick look. So we have e.g. MACH_STM32F746 under ARM_SINGLE_ARMV7M, > and MACH_STM32MP157 under ARCH_MULTI_V7. > But according to stm32mp157c-ed1.dts and stm32746g-eval.dts both have > memory at the same address, so it should be possible to run the same nommu > kernel on the STM32MP157? > > MACH_STM32F469 is also under ARM_SINGLE_ARMV7M, but according to > stm32f469-disco.dts, memory may be at a completely different address? > Doesn't that lead to unbootable kernels, too? It's probably an error in the dts. Cortex M7, like previous Cortex M CPUs, has a CPU defined memory layout. This is documented in the Cortex M7 processor reference manual, figure 2.1. As you point out, stm32746g-eval.dts specifies a memory region. This memory region is: memory { reg = <0xc0000000 0x2000000>; }; However, this conflicts with the Cortex M7 processor reference manual, which states that physical addresses between 0xa0000000 and 0xe0000000 are "external device" (that is, they are treated as "device" accesses not "memory" accesses). So, it is highly unlikely that there is memory at the location specified in the DTS. NOMMU kernels are linked at PAGE_OFFSET + TEXT_OFFSET in the same way as MMU kernels are linked, where PAGE_OFFSET comes from CONFIG_PAGE_OFFSET. The difference for NOMMU is that CONFIG_PAGE_OFFSET is the same as CONFIG_PHYS_OFFSET, which is the same as CONFIG_DRAM_BASE. stm32 as a whole defines CONFIG_DRAM_BASE as 0x90000000 which is common to all. It does not appear that we have defconfigs for the V7M AT91 nor iMX kernels, so we can't draw any conclusions about what value this configuration takes, but as 0x90000000 is defined to be "external memory" by the Cortex M7 processor reference manual, I'd expect these to be the same. > > Another problems for NOMMU is that the kernel has to be linked for > > a specific _physical_ address. When you have ARCH_MULTIPLATFORM > > enabled, there is no facility to select that address. > > That can be easily solved with Kconfig symbols that depend on !MMU, > can't it? Given that (as I've illustrated above) modern MMU-less ARM CPUs have well defined memory layouts, how is this any different from our current approach. Yes, we might not be saying "ARM_MACHINES_WITH_DRAM_BASE_90000000" - such a thing would be meaningless to the guy configuring the kernel (could you guess before I sent this email that Cortex M7 should have RAM at that address? - probably not.) So, Kconfig symbols based on RAM addresses don't work.
On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > "ARM multiplatform" has actually two meanings: > 1. It groups platforms that follow the "ARM multiplatform" software > framework, > 2. It allows to build a single kernel that can be booted on multiple > platforms. > > Currently support for XIP and/or NOMMU cannot be enabled on platforms > that follow the "ARM multiplatform" framework, without duplicating their > machine selection logic under a new Kconfig symbol. As (in theory) all > platforms can be used with XIP and/or NOMMU, this is not sustainable. > > Hence clarify the meaning of ARCH_MULTIPLATFORM: > 1. Replace "multiple platforms" by "common platform", as it allows to > select one or more platforms adhering to the common framework, > 2. Note that a single kernel may not boot on all platforms if XIP or > NOMMU is enabled. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > References: > - "[PATCHv4 0/4] arm/versatile: no-MMU support" > (http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/584555.html) > > - "[PATCH 0/2] ARM: ARMv7 (with MMU) XIP without ARCH_MULTIPLATFORM" > (http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486835.html) > > arch/arm/Kconfig | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 54eeb8d00bc62a9f..6b286c018cf748c7 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -329,7 +329,7 @@ choice > default ARCH_MULTIPLATFORM if MMU > > config ARCH_MULTIPLATFORM > - bool "Allow multiple platforms to be selected" > + bool "Common platforms (\"multiplatform\")" > depends on MMU > select ARM_HAS_SG_CHAIN > select ARM_PATCH_PHYS_VIRT > @@ -342,6 +342,13 @@ config ARCH_MULTIPLATFORM > select PCI_DOMAINS if PCI > select SPARSE_IRQ > select USE_OF > + help > + Support for systems implemented using the common "multiplatform" > + framework. > + > + Unless specialized options depending on intimate platform > + details, like XIP or NOMMU, are enabled, this allows to build a > + single kernel that boots on multiple platforms. Hi Geert, I wonder if this might be slightly clearer: Unless specialized options that depend on intimate platform details, such as XIP and NOMMU, are enabled, this allows building a single kernel that boots on multiple platforms. > > config ARM_SINGLE_ARMV7M > bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" > -- > 2.17.1 >
On Friday, June 22, 2018, Russell King - ARM Linux wrote: > We've worked around the issues with "multi-platform" XIP/NOMMU by > using things such as "ARM_SINGLE_V7M" to cover all V7M platforms > (which must, by definition) have compatible physical layouts. > Exactly the same approach should be adopted for other XIP/NOMMU > platforms, and _not_ reusing ARCH_MULTIPLATFORM, which will lead > to lots of non-bootable kernels. FYI, I already submitted at patch like that: https://patchwork.kernel.org/patch/9563975/ Chris
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 54eeb8d00bc62a9f..6b286c018cf748c7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -329,7 +329,7 @@ choice default ARCH_MULTIPLATFORM if MMU config ARCH_MULTIPLATFORM - bool "Allow multiple platforms to be selected" + bool "Common platforms (\"multiplatform\")" depends on MMU select ARM_HAS_SG_CHAIN select ARM_PATCH_PHYS_VIRT @@ -342,6 +342,13 @@ config ARCH_MULTIPLATFORM select PCI_DOMAINS if PCI select SPARSE_IRQ select USE_OF + help + Support for systems implemented using the common "multiplatform" + framework. + + Unless specialized options depending on intimate platform + details, like XIP or NOMMU, are enabled, this allows to build a + single kernel that boots on multiple platforms. config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)"
"ARM multiplatform" has actually two meanings: 1. It groups platforms that follow the "ARM multiplatform" software framework, 2. It allows to build a single kernel that can be booted on multiple platforms. Currently support for XIP and/or NOMMU cannot be enabled on platforms that follow the "ARM multiplatform" framework, without duplicating their machine selection logic under a new Kconfig symbol. As (in theory) all platforms can be used with XIP and/or NOMMU, this is not sustainable. Hence clarify the meaning of ARCH_MULTIPLATFORM: 1. Replace "multiple platforms" by "common platform", as it allows to select one or more platforms adhering to the common framework, 2. Note that a single kernel may not boot on all platforms if XIP or NOMMU is enabled. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- References: - "[PATCHv4 0/4] arm/versatile: no-MMU support" (http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/584555.html) - "[PATCH 0/2] ARM: ARMv7 (with MMU) XIP without ARCH_MULTIPLATFORM" (http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/486835.html) arch/arm/Kconfig | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)