* Building for MMU-less vexpress targets @ 2012-11-05 17:36 Will Deacon 2012-11-05 18:03 ` Pawel Moll 2012-11-05 19:08 ` Arnd Bergmann 0 siblings, 2 replies; 23+ messages in thread From: Will Deacon @ 2012-11-05 17:36 UTC (permalink / raw) To: linux-arm-kernel Hi guys, I was playing around with !CONFIG_MMU today and to my dismay noticed that you can't select ARCH_VEXPRESS without CONFIG_MMU=y! This is because ARCH_VEXPRESS is only selectable via ARCH_MULTI_V7, which depends on ARCH_MULTIPLATFORM which in turn depends on MMU. I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7 dependency dropped) but I wondered if you'd got any better ideas? Cheers, Will ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-05 17:36 Building for MMU-less vexpress targets Will Deacon @ 2012-11-05 18:03 ` Pawel Moll 2012-11-05 18:13 ` Will Deacon 2012-11-05 19:08 ` Arnd Bergmann 1 sibling, 1 reply; 23+ messages in thread From: Pawel Moll @ 2012-11-05 18:03 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2012-11-05 at 17:36 +0000, Will Deacon wrote: > I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on > !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7 > dependency dropped) ... depends on !ARCH_MULTIPLATFORM or maybe rather !MMU? (I assume you want to add an extra dummy position in the choice section, where options are mutually exclusive anyway?) Pawe? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-05 18:03 ` Pawel Moll @ 2012-11-05 18:13 ` Will Deacon 0 siblings, 0 replies; 23+ messages in thread From: Will Deacon @ 2012-11-05 18:13 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 05, 2012 at 06:03:20PM +0000, Pawel Moll wrote: > On Mon, 2012-11-05 at 17:36 +0000, Will Deacon wrote: > > I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on > > !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7 > > dependency dropped) > > ... depends on !ARCH_MULTIPLATFORM or maybe rather !MMU? (I assume you > want to add an extra dummy position in the choice section, where options > are mutually exclusive anyway?) Yeah, you could do something like the following but it just feels a bit nasty: Will --->8 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 335e220..0561d87 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -305,6 +305,11 @@ config ARCH_REALVIEW help This enables support for ARM Ltd RealView boards. +config ARCH_VEXPRESS_NOMMU + bool "ARM Ltd. Versatile Express family (nommu)" + depends on !MMU + select ARCH_VEXPRESS + config ARCH_VERSATILE bool "ARM Ltd. Versatile family" select ARCH_WANT_OPTIONAL_GPIOLIB ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-05 17:36 Building for MMU-less vexpress targets Will Deacon 2012-11-05 18:03 ` Pawel Moll @ 2012-11-05 19:08 ` Arnd Bergmann 2012-11-06 12:20 ` Will Deacon 1 sibling, 1 reply; 23+ messages in thread From: Arnd Bergmann @ 2012-11-05 19:08 UTC (permalink / raw) To: linux-arm-kernel On Monday 05 November 2012, Will Deacon wrote: > I was playing around with !CONFIG_MMU today and to my dismay noticed that > you can't select ARCH_VEXPRESS without CONFIG_MMU=y! This is because > ARCH_VEXPRESS is only selectable via ARCH_MULTI_V7, which depends on > ARCH_MULTIPLATFORM which in turn depends on MMU. > > I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on > !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7 > dependency dropped) but I wondered if you'd got any better ideas? > I don't actually remember what the reason for making ARCH_MULTIPLATFORM depend on MMU was. Maybe it just works if you drop the dependency. Presumably it's related to ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR not working on NOMMU, but if that's the case, we could make it ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" select ARM_PATCH_PHYS_VIRT if !MMU select AUTO_ZRELADDR if !MMU but maybe those actually work without MMU as well. I have never looked too closely at NOMMU configurations, every time I tried, they were broken in combination with something else I wanted to enable. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-05 19:08 ` Arnd Bergmann @ 2012-11-06 12:20 ` Will Deacon 2012-11-06 17:33 ` Arnd Bergmann 0 siblings, 1 reply; 23+ messages in thread From: Will Deacon @ 2012-11-06 12:20 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 05, 2012 at 07:08:34PM +0000, Arnd Bergmann wrote: > On Monday 05 November 2012, Will Deacon wrote: > > I was playing around with !CONFIG_MMU today and to my dismay noticed that > > you can't select ARCH_VEXPRESS without CONFIG_MMU=y! This is because > > ARCH_VEXPRESS is only selectable via ARCH_MULTI_V7, which depends on > > ARCH_MULTIPLATFORM which in turn depends on MMU. > > > > I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on > > !ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7 > > dependency dropped) but I wondered if you'd got any better ideas? > > > > I don't actually remember what the reason for making ARCH_MULTIPLATFORM > depend on MMU was. Maybe it just works if you drop the dependency. > > Presumably it's related to ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR not > working on NOMMU, but if that's the case, we could make it > > > ARCH_MULTIPLATFORM > bool "Allow multiple platforms to be selected" > select ARM_PATCH_PHYS_VIRT if !MMU > select AUTO_ZRELADDR if !MMU you mean if MMU, right? > but maybe those actually work without MMU as well. I have never looked too > closely at NOMMU configurations, every time I tried, they were broken in > combination with something else I wanted to enable. ARM_PATCH_PHYS_VIRT wouldn't make any sense, but I can't see why AUTO_ZRELADDR wouldn't be ok. nommu-XIP kernels are a different kettle of fish, but we don't care about a decompressor there. The real problem will hit with things like CONFIG_DRAM_BASE, where !MMU can't realistically support multiple platforms, so allowing ARCH_MULTIPLATFORM doesn't feel quite right either... Will ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 12:20 ` Will Deacon @ 2012-11-06 17:33 ` Arnd Bergmann 2012-11-06 18:34 ` Will Deacon 2012-11-06 20:58 ` Nicolas Pitre 0 siblings, 2 replies; 23+ messages in thread From: Arnd Bergmann @ 2012-11-06 17:33 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 06 November 2012, Will Deacon wrote: > > ARCH_MULTIPLATFORM > > bool "Allow multiple platforms to be selected" > > select ARM_PATCH_PHYS_VIRT if !MMU > > select AUTO_ZRELADDR if !MMU > > you mean if MMU, right? Yes. > > but maybe those actually work without MMU as well. I have never looked too > > closely at NOMMU configurations, every time I tried, they were broken in > > combination with something else I wanted to enable. > > ARM_PATCH_PHYS_VIRT wouldn't make any sense, but I can't see why > AUTO_ZRELADDR wouldn't be ok. Ok. > nommu-XIP kernels are a different kettle > of fish, but we don't care about a decompressor there. XIP is only supported on ARCH_PXA and ARCH_SA1100. I don't see either of them moving to CONFIG_MULTIPLATFORM any time soon, given how much work that would be. ARCH_MMP should be possible in the future, but has never supported XIP so far. > The real problem will hit with things like CONFIG_DRAM_BASE, where !MMU > can't realistically support multiple platforms, so allowing > ARCH_MULTIPLATFORM doesn't feel quite right either... Anybody who wants to build a !MMU kernel already needs to tweak the configuration quite a lot and usually knows more about the system than a typical end user. Having to pick the correct DRAM_BASE probably isn't too bad in that case, as long as the kernels actually build. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 17:33 ` Arnd Bergmann @ 2012-11-06 18:34 ` Will Deacon 2012-11-06 20:35 ` Arnd Bergmann 2012-11-06 20:58 ` Nicolas Pitre 1 sibling, 1 reply; 23+ messages in thread From: Will Deacon @ 2012-11-06 18:34 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 06, 2012 at 05:33:44PM +0000, Arnd Bergmann wrote: > On Tuesday 06 November 2012, Will Deacon wrote: > > nommu-XIP kernels are a different kettle > > of fish, but we don't care about a decompressor there. > > XIP is only supported on ARCH_PXA and ARCH_SA1100. I don't see either > of them moving to CONFIG_MULTIPLATFORM any time soon, given how much > work that would be. ARCH_MMP should be possible in the future, but > has never supported XIP so far. Indeed, although I expect systems with M-class CPUs to make more use of XIP (I believe Uwe's board does this and uses the framebuffer for main memory). > > The real problem will hit with things like CONFIG_DRAM_BASE, where !MMU > > can't realistically support multiple platforms, so allowing > > ARCH_MULTIPLATFORM doesn't feel quite right either... > > Anybody who wants to build a !MMU kernel already needs to tweak the > configuration quite a lot and usually knows more about the system than > a typical end user. Having to pick the correct DRAM_BASE probably > isn't too bad in that case, as long as the kernels actually build. Ok, that's fair enough. Patch below. Cheers, Will --->8 ARM: nommu: remove MMU dependency from ARCH_MULTIPLATFORM ARCH_MULTIPLATFORM is the only way to select ARCH_VEXPRESS, so remove the dependency on MMU and instead use it to predicate the selection of ARM_PATCH_PHYS_VIRT. Although running a multi-platform kernel on a selection of MMU-less targets might not yet be possible, the thing should build and targetting a nommu platform is already a fairly involved exercise. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Pawel Moll <Pawel.Moll@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 335e220..5758cfb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -264,8 +264,7 @@ choice config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU - select ARM_PATCH_PHYS_VIRT + select ARM_PATCH_PHYS_VIRT if MMU select AUTO_ZRELADDR select COMMON_CLK select MULTI_IRQ_HANDLER ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 18:34 ` Will Deacon @ 2012-11-06 20:35 ` Arnd Bergmann 0 siblings, 0 replies; 23+ messages in thread From: Arnd Bergmann @ 2012-11-06 20:35 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 06 November 2012, Will Deacon wrote: > ARM: nommu: remove MMU dependency from ARCH_MULTIPLATFORM > > ARCH_MULTIPLATFORM is the only way to select ARCH_VEXPRESS, so remove > the dependency on MMU and instead use it to predicate the selection of > ARM_PATCH_PHYS_VIRT. > > Although running a multi-platform kernel on a selection of MMU-less > targets might not yet be possible, the thing should build and targetting > a nommu platform is already a fairly involved exercise. > > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Pawel Moll <Pawel.Moll@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > Acked-by: Arnd Bergmann <arnd@arndb.de> Before we apply this, I should probably do a round of randconfig tests. Right now, I have a series that fixes all build errors we currently get from randconfig (which always selects MULTIPLATFORM since it doesn't randomize choice statements), but I am pretty sure that adding NOMMU into the mix gives us a lot of new errors. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 17:33 ` Arnd Bergmann 2012-11-06 18:34 ` Will Deacon @ 2012-11-06 20:58 ` Nicolas Pitre 2012-11-06 21:14 ` Arnd Bergmann 2012-11-06 22:51 ` Jamie Lokier 1 sibling, 2 replies; 23+ messages in thread From: Nicolas Pitre @ 2012-11-06 20:58 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Nov 2012, Arnd Bergmann wrote: > On Tuesday 06 November 2012, Will Deacon wrote: > > nommu-XIP kernels are a different kettle > > of fish, but we don't care about a decompressor there. > > XIP is only supported on ARCH_PXA and ARCH_SA1100. I don't see either > of them moving to CONFIG_MULTIPLATFORM any time soon, given how much > work that would be. ARCH_MMP should be possible in the future, but > has never supported XIP so far. XIP kernels (CONFIG_XIP_KERNEL) are supported on any architecture. This doesn't require any platform specific support. You just need a range of physical memory addresses where to get the kernel text from (that could even be unmapped RAM if you wanted to play with it on a platform with no NOR flash). The prospect of PRAM usage might renew interest in a XIP kernel. Maybe you are confused by CONFIG_ARCH_MTD_XIP where special support is needed in order to make writable MTD devices compatible with a XIP kernel located on them. That is indeed only available for ARCH_PXA and ARCH_SA1100. > > The real problem will hit with things like CONFIG_DRAM_BASE, where !MMU > > can't realistically support multiple platforms, so allowing > > ARCH_MULTIPLATFORM doesn't feel quite right either... > > Anybody who wants to build a !MMU kernel already needs to tweak the > configuration quite a lot and usually knows more about the system than > a typical end user. Having to pick the correct DRAM_BASE probably > isn't too bad in that case, as long as the kernels actually build. I really think that it makes no sense at all to support !MMU kernels in a multi-platform kernel build, even if the set of included platforms were all !MMU. The kernel has to be linked for the physical address of the target and not a common invariant virtual address. Nicolas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 20:58 ` Nicolas Pitre @ 2012-11-06 21:14 ` Arnd Bergmann 2012-11-06 22:14 ` Russell King - ARM Linux 2012-11-06 23:14 ` Nicolas Pitre 2012-11-06 22:51 ` Jamie Lokier 1 sibling, 2 replies; 23+ messages in thread From: Arnd Bergmann @ 2012-11-06 21:14 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 06 November 2012, Nicolas Pitre wrote: > Maybe you are confused by CONFIG_ARCH_MTD_XIP where special support is > needed in order to make writable MTD devices compatible with a XIP > kernel located on them. That is indeed only available for ARCH_PXA and > ARCH_SA1100. Ok, I see. > I really think that it makes no sense at all to support !MMU kernels in > a multi-platform kernel build, even if the set of included platforms > were all !MMU. The kernel has to be linked for the physical address of > the target and not a common invariant virtual address. There are two separate aspects here: One is to run a kernel on !MMU that is built to support multiple platforms. I agree that this is rather pointless and not interesting. The other point is being able to build such a kernel, and this is what Will seems to be interested in more. We have made VEXPRESS depend on MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel, and I think we should fix that. The two options are either to make vexpress be single-platform when building for !MMU, or to allow multiplatform kernels to be built without MMU support in principle. I think the second option is more logical and avoids complex Kconfig constructs. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 21:14 ` Arnd Bergmann @ 2012-11-06 22:14 ` Russell King - ARM Linux 2012-11-06 22:59 ` Rob Herring 2012-11-07 12:59 ` Arnd Bergmann 2012-11-06 23:14 ` Nicolas Pitre 1 sibling, 2 replies; 23+ messages in thread From: Russell King - ARM Linux @ 2012-11-06 22:14 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote: > The other point is being able to build such a kernel, and this is what Will > seems to be interested in more. We have made VEXPRESS depend on > MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel, > and I think we should fix that. The two options are either to make > vexpress be single-platform when building for !MMU, or to allow multiplatform > kernels to be built without MMU support in principle. I think the second > option is more logical and avoids complex Kconfig constructs. The other thing here is... why does a platform which _was_ able to be built in isolation from every other platform suddenly become incapable of being so when they join the multiplatform conglomerate? This just sounds totally perverse and wrong. Surely it should be: platforms _not_ yet converted to multiplatform can't be selected with multi-platform support enabled? So, maybe the _proper_ solution here is: - change the big choice to be: config SINGLE_xxx - these select config MACH_FOO / PLAT_FOO / ARCH_FOO eg, config SINGLE_FOO bool "Support for foo platforms in single kernel" select MACH_FOO - add a final option: config MULTIPLATFORM - then add: config MULTI_FOO bool "Include support for foo platforms" select MACH_FOO depends on MULTIPLATFORM || !MMU ... config MACH_FOO bool Now, we don't _have_ to have the single and multi variants if they aren't appropriate for the platform, but we can cover all the cases: a platform where it's part of the multi-platform kernel when built for MMU, but is incapable of being a multi-platform kernel when built without MMU. And we can do it without _too_ much Kconfig pain, and certainly without having to delve into anything beyond arch/arm/Kconfig. I'd suggest at that point we separate out this stuff into a separate file - arch/arm/Kconfig.mach, which contains all the platform selection stuff. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 22:14 ` Russell King - ARM Linux @ 2012-11-06 22:59 ` Rob Herring 2012-11-07 12:59 ` Arnd Bergmann 1 sibling, 0 replies; 23+ messages in thread From: Rob Herring @ 2012-11-06 22:59 UTC (permalink / raw) To: linux-arm-kernel On 11/06/2012 04:14 PM, Russell King - ARM Linux wrote: > On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote: >> The other point is being able to build such a kernel, and this is what Will >> seems to be interested in more. We have made VEXPRESS depend on >> MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel, >> and I think we should fix that. The two options are either to make >> vexpress be single-platform when building for !MMU, or to allow multiplatform >> kernels to be built without MMU support in principle. I think the second >> option is more logical and avoids complex Kconfig constructs. > > The other thing here is... why does a platform which _was_ able to be > built in isolation from every other platform suddenly become incapable > of being so when they join the multiplatform conglomerate? This just > sounds totally perverse and wrong. Arnd and I discussed this some at Connect regarding VExpress being selected. This is only to prevent the warning that no machine is enabled in a randconfig or user error case. We could simply remove this error or make it a warning instead. Then selecting a single platform is a matter of only selecting 1 platform. > Surely it should be: platforms _not_ yet converted to multiplatform > can't be selected with multi-platform support enabled? > > So, maybe the _proper_ solution here is: > > - change the big choice to be: config SINGLE_xxx > - these select config MACH_FOO / PLAT_FOO / ARCH_FOO > eg, > config SINGLE_FOO > bool "Support for foo platforms in single kernel" > select MACH_FOO > - add a final option: config MULTIPLATFORM > - then add: > > config MULTI_FOO > bool "Include support for foo platforms" > select MACH_FOO > depends on MULTIPLATFORM || !MMU > ... > > config MACH_FOO > bool > I'd rather see less xxx_FOO config symbols rather than more. Wouldn't this break defconfigs? Rob > Now, we don't _have_ to have the single and multi variants if they aren't > appropriate for the platform, but we can cover all the cases: a platform > where it's part of the multi-platform kernel when built for MMU, but is > incapable of being a multi-platform kernel when built without MMU. > > And we can do it without _too_ much Kconfig pain, and certainly without > having to delve into anything beyond arch/arm/Kconfig. > > I'd suggest at that point we separate out this stuff into a separate > file - arch/arm/Kconfig.mach, which contains all the platform selection > stuff. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 22:14 ` Russell King - ARM Linux 2012-11-06 22:59 ` Rob Herring @ 2012-11-07 12:59 ` Arnd Bergmann 2012-11-07 13:39 ` Russell King - ARM Linux 1 sibling, 1 reply; 23+ messages in thread From: Arnd Bergmann @ 2012-11-07 12:59 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 06 November 2012, Russell King - ARM Linux wrote: > On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote: > > The other point is being able to build such a kernel, and this is what Will > > seems to be interested in more. We have made VEXPRESS depend on > > MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel, > > and I think we should fix that. The two options are either to make > > vexpress be single-platform when building for !MMU, or to allow multiplatform > > kernels to be built without MMU support in principle. I think the second > > option is more logical and avoids complex Kconfig constructs. > > The other thing here is... why does a platform which _was_ able to be > built in isolation from every other platform suddenly become incapable > of being so when they join the multiplatform conglomerate? This just > sounds totally perverse and wrong. > > Surely it should be: platforms _not_ yet converted to multiplatform > can't be selected with multi-platform support enabled? > > So, maybe the _proper_ solution here is: > > - change the big choice to be: config SINGLE_xxx > - these select config MACH_FOO / PLAT_FOO / ARCH_FOO > eg, > config SINGLE_FOO > bool "Support for foo platforms in single kernel" > select MACH_FOO > - add a final option: config MULTIPLATFORM > - then add: > > config MULTI_FOO > bool "Include support for foo platforms" > select MACH_FOO > depends on MULTIPLATFORM || !MMU > ... > > config MACH_FOO > bool A few platforms are doing this. E.g. the vt8500 platform currently allows both, and the at91 will only allow multiplatform to be selected for the DT-aware systems, while the single-platform still allows both DT and non-DT. In general, I'm fine with either approach (multiplatform only or mixed) and I'd like to leave that choice to the platform maintainers. > Now, we don't _have_ to have the single and multi variants if they aren't > appropriate for the platform, but we can cover all the cases: a platform > where it's part of the multi-platform kernel when built for MMU, but is > incapable of being a multi-platform kernel when built without MMU. > > And we can do it without _too_ much Kconfig pain, and certainly without > having to delve into anything beyond arch/arm/Kconfig. Sure, that works. My point was just that I think it would be simpler to keep vexpress multiplatform-only if there are no reasons that prevent us from doing that. I also hope that we can at some point in the future get all ARMv6 and ARMv7 platforms to be multiplatform-only, while leaving each ARMv4/ARMv5 to be any of single, multi, or mixed. > I'd suggest at that point we separate out this stuff into a separate > file - arch/arm/Kconfig.mach, which contains all the platform selection > stuff. Good idea, I like that. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-07 12:59 ` Arnd Bergmann @ 2012-11-07 13:39 ` Russell King - ARM Linux 0 siblings, 0 replies; 23+ messages in thread From: Russell King - ARM Linux @ 2012-11-07 13:39 UTC (permalink / raw) To: linux-arm-kernel On Wed, Nov 07, 2012 at 12:59:14PM +0000, Arnd Bergmann wrote: > On Tuesday 06 November 2012, Russell King - ARM Linux wrote: > > Now, we don't _have_ to have the single and multi variants if they aren't > > appropriate for the platform, but we can cover all the cases: a platform > > where it's part of the multi-platform kernel when built for MMU, but is > > incapable of being a multi-platform kernel when built without MMU. > > > > And we can do it without _too_ much Kconfig pain, and certainly without > > having to delve into anything beyond arch/arm/Kconfig. > > Sure, that works. My point was just that I think it would be simpler > to keep vexpress multiplatform-only if there are no reasons that prevent > us from doing that. > > I also hope that we can at some point in the future get all ARMv6 and ARMv7 > platforms to be multiplatform-only, while leaving each ARMv4/ARMv5 to be > any of single, multi, or mixed. Except... we have one report where this approach already doesn't work, where we have what is essentially an ARMv7 platform needing to be built outside the multiplatform stuff... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 21:14 ` Arnd Bergmann 2012-11-06 22:14 ` Russell King - ARM Linux @ 2012-11-06 23:14 ` Nicolas Pitre 2012-11-07 10:21 ` Will Deacon ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Nicolas Pitre @ 2012-11-06 23:14 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Nov 2012, Arnd Bergmann wrote: > On Tuesday 06 November 2012, Nicolas Pitre wrote: > > I really think that it makes no sense at all to support !MMU kernels in > > a multi-platform kernel build, even if the set of included platforms > > were all !MMU. The kernel has to be linked for the physical address of > > the target and not a common invariant virtual address. > > There are two separate aspects here: One is to run a kernel on !MMU that is > built to support multiple platforms. I agree that this is rather pointless > and not interesting. > > The other point is being able to build such a kernel, and this is what Will > seems to be interested in more. What's the point of building a pointless and uninteresting kernel? Sure, wide build coverage is good. But pointless builds are not. Comes a point where Kconfig should serve its purpose i.e. help the user make a valid kernel configuration for himself. And I really think that multi-platform and !MMU together don't make for a valid configuration anymore. > We have made VEXPRESS depend on MULTIPLATFORM, which broke support for > building a non-MMU vexpress kernel, and I think we should fix that. No argument there. > The two options are either to make > vexpress be single-platform when building for !MMU, or to allow multiplatform > kernels to be built without MMU support in principle. I think the second > option is more logical and avoids complex Kconfig constructs. Well, I'd rather prefer to think that the first option is the most logical between those 2 options, regardless of Kconfig complexity issues. I didn't look, but just making MULTIPLATFORM depend on !MMU, and VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is needed, no? Nicolas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 23:14 ` Nicolas Pitre @ 2012-11-07 10:21 ` Will Deacon 2012-11-07 13:29 ` Arnd Bergmann 2013-01-08 19:01 ` Jonathan Austin 2 siblings, 0 replies; 23+ messages in thread From: Will Deacon @ 2012-11-07 10:21 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 06, 2012 at 11:14:06PM +0000, Nicolas Pitre wrote: > On Tue, 6 Nov 2012, Arnd Bergmann wrote: > > > On Tuesday 06 November 2012, Nicolas Pitre wrote: > > > I really think that it makes no sense at all to support !MMU kernels in > > > a multi-platform kernel build, even if the set of included platforms > > > were all !MMU. The kernel has to be linked for the physical address of > > > the target and not a common invariant virtual address. > > > > There are two separate aspects here: One is to run a kernel on !MMU that is > > built to support multiple platforms. I agree that this is rather pointless > > and not interesting. > > > > The other point is being able to build such a kernel, and this is what Will > > seems to be interested in more. > > What's the point of building a pointless and uninteresting kernel? > > Sure, wide build coverage is good. But pointless builds are not. > Comes a point where Kconfig should serve its purpose i.e. help the user > make a valid kernel configuration for himself. And I really think that > multi-platform and !MMU together don't make for a valid configuration > anymore. If it's just the physical memory map that gets in the way for multiplatform !MMU, it's probably worth me pointing out that for PMSAv7 (i.e. R-class cores) there is a mandated default memory map, which does make this problem largely disappear. All said and done, I don't see anybody ever using the option though -- distributions will likely never ship nommu kernels and they typically get deployed in one place only with an emphasis on keeping the thing small. Will ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 23:14 ` Nicolas Pitre 2012-11-07 10:21 ` Will Deacon @ 2012-11-07 13:29 ` Arnd Bergmann 2013-01-08 19:01 ` Jonathan Austin 2 siblings, 0 replies; 23+ messages in thread From: Arnd Bergmann @ 2012-11-07 13:29 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 06 November 2012, Nicolas Pitre wrote: > On Tue, 6 Nov 2012, Arnd Bergmann wrote: > > > On Tuesday 06 November 2012, Nicolas Pitre wrote: > > > I really think that it makes no sense at all to support !MMU kernels in > > > a multi-platform kernel build, even if the set of included platforms > > > were all !MMU. The kernel has to be linked for the physical address of > > > the target and not a common invariant virtual address. > > > > There are two separate aspects here: One is to run a kernel on !MMU that is > > built to support multiple platforms. I agree that this is rather pointless > > and not interesting. > > > > The other point is being able to build such a kernel, and this is what Will > > seems to be interested in more. > > What's the point of building a pointless and uninteresting kernel? Built-time coverage is the only one I can think of, but I think it's a good reason. Being able to build an "allyesconfig" with MMU disabled sounds like a good sniff test to see if something broke and is much faster than building all the defconfigs. > > The two options are either to make > > vexpress be single-platform when building for !MMU, or to allow multiplatform > > kernels to be built without MMU support in principle. I think the second > > option is more logical and avoids complex Kconfig constructs. > > Well, I'd rather prefer to think that the first option is the most > logical between those 2 options, regardless of Kconfig complexity > issues. > > I didn't look, but just making MULTIPLATFORM depend on !MMU, and > VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is > needed, no? Fine with me too. I suppose you just made the same logic error that I had earlier in this thread and meant !MMU where you wrote MMU. Arnd ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 23:14 ` Nicolas Pitre 2012-11-07 10:21 ` Will Deacon 2012-11-07 13:29 ` Arnd Bergmann @ 2013-01-08 19:01 ` Jonathan Austin 2013-01-08 19:11 ` Arnd Bergmann 2 siblings, 1 reply; 23+ messages in thread From: Jonathan Austin @ 2013-01-08 19:01 UTC (permalink / raw) To: linux-arm-kernel Nicolas, On 06/11/12 23:14, Nicolas Pitre wrote: > On Tue, 6 Nov 2012, Arnd Bergmann wrote: > >> On Tuesday 06 November 2012, Nicolas Pitre wrote: > >> The two options are either to make >> vexpress be single-platform when building for !MMU, or to allow multiplatform >> kernels to be built without MMU support in principle. I think the second >> option is more logical and avoids complex Kconfig constructs. > > Well, I'd rather prefer to think that the first option is the most > logical between those 2 options, regardless of Kconfig complexity > issues. > > I didn't look, but just making MULTIPLATFORM depend on !MMU, and > VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is > needed, no? > I've spent a little bit of time trying this, as both Arnd and you seemed to be happy with a solution along these lines. However, I can't seem to make it fall out quite so trivially so I wonder if you'd mind clarifying what you were expecting: The problem that I see when I try to do this is that ARCH_VEXPRESS no longer exists in the 'choice' for "ARM system type" in arch/arm/Kconfig. A solution that allows selection of VEXPRESS as a single platform (!MMU) and multi-platform (MMU) appears to need an entry in that 'choice' for the single platform case, and a config option in arch/arm/mach-vexpress/Kconfig for the multiplatform one. So it seems to me we need a shim in one of those two locations... As Will suggested a while back, the shim in arch/arm/Kconfig could look like: ---8<--- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 335e220..0561d87 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -305,6 +305,11 @@ config ARCH_REALVIEW help This enables support for ARM Ltd RealView boards. +config ARCH_VEXPRESS_NOMMU + bool "ARM Ltd. Versatile Express family (nommu)" + depends on !MMU + select ARCH_VEXPRESS + config ARCH_VERSATILE bool "ARM Ltd. Versatile family" select ARCH_WANT_OPTIONAL_GPIOLIB ---->8---- With the other perhaps being to merge the ARCH_VEXPRESS option back in to the 'choice' and create a ARCH_VEXPRESS_MULTI elsewhere... Is that the sort of thing you had in mind, or is there another way around that I'm missing? Thanks, Jonny ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2013-01-08 19:01 ` Jonathan Austin @ 2013-01-08 19:11 ` Arnd Bergmann 2013-01-08 19:22 ` Nicolas Pitre 0 siblings, 1 reply; 23+ messages in thread From: Arnd Bergmann @ 2013-01-08 19:11 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 08 January 2013, Jonathan Austin wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 335e220..0561d87 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -305,6 +305,11 @@ config ARCH_REALVIEW > help > This enables support for ARM Ltd RealView boards. > > +config ARCH_VEXPRESS_NOMMU > + bool "ARM Ltd. Versatile Express family (nommu)" > + depends on !MMU > + select ARCH_VEXPRESS > + > config ARCH_VERSATILE > bool "ARM Ltd. Versatile family" > select ARCH_WANT_OPTIONAL_GPIOLIB > ---->8---- Yes, I think this is the right approach. > With the other perhaps being to merge the ARCH_VEXPRESS option back in > to the 'choice' and create a ARCH_VEXPRESS_MULTI elsewhere... That would needlessly break 'make oldconfig' for people that have CONFIG_ARCH_VEXPRESS in their .config files or other scripts. > Is that the sort of thing you had in mind, or is there another way > around that I'm missing? I think it's good. Acked-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2013-01-08 19:11 ` Arnd Bergmann @ 2013-01-08 19:22 ` Nicolas Pitre 0 siblings, 0 replies; 23+ messages in thread From: Nicolas Pitre @ 2013-01-08 19:22 UTC (permalink / raw) To: linux-arm-kernel On Tue, 8 Jan 2013, Arnd Bergmann wrote: > On Tuesday 08 January 2013, Jonathan Austin wrote: > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 335e220..0561d87 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -305,6 +305,11 @@ config ARCH_REALVIEW > > help > > This enables support for ARM Ltd RealView boards. > > > > +config ARCH_VEXPRESS_NOMMU > > + bool "ARM Ltd. Versatile Express family (nommu)" > > + depends on !MMU > > + select ARCH_VEXPRESS > > + > > config ARCH_VERSATILE > > bool "ARM Ltd. Versatile family" > > select ARCH_WANT_OPTIONAL_GPIOLIB > > ---->8---- > > Yes, I think this is the right approach. > > > With the other perhaps being to merge the ARCH_VEXPRESS option back in > > to the 'choice' and create a ARCH_VEXPRESS_MULTI elsewhere... > > That would needlessly break 'make oldconfig' for people that have > CONFIG_ARCH_VEXPRESS in their .config files or other scripts. > > > Is that the sort of thing you had in mind, or is there another way > > around that I'm missing? > > I think it's good. > > Acked-by: Arnd Bergmann <arnd@arndb.de> Looks fine to me too. Perhaps the vexpress option would logically fit better if located after versatile instead of being in the middle of realview and versatile. Other than that: Acked-by: Nicolas Pitre <nico@linaro.org> Nicolas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 20:58 ` Nicolas Pitre 2012-11-06 21:14 ` Arnd Bergmann @ 2012-11-06 22:51 ` Jamie Lokier 2012-11-06 23:40 ` Nicolas Pitre 1 sibling, 1 reply; 23+ messages in thread From: Jamie Lokier @ 2012-11-06 22:51 UTC (permalink / raw) To: linux-arm-kernel Nicolas Pitre wrote: > I really think that it makes no sense at all to support !MMU kernels in > a multi-platform kernel build, even if the set of included platforms > were all !MMU. The kernel has to be linked for the physical address of > the target and not a common invariant virtual address. Although there's likely to be approximately zero interest in multi-platform !MMU, relocating at boot time doesn't sound onerous, should it be needed. x86 kernels already do that. Maybe ARM kernels will eventually do that anyway for the same reason as x86. -- Jamie ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 22:51 ` Jamie Lokier @ 2012-11-06 23:40 ` Nicolas Pitre 2012-11-06 23:46 ` Jamie Lokier 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Pitre @ 2012-11-06 23:40 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Nov 2012, Jamie Lokier wrote: > Nicolas Pitre wrote: > > I really think that it makes no sense at all to support !MMU kernels in > > a multi-platform kernel build, even if the set of included platforms > > were all !MMU. The kernel has to be linked for the physical address of > > the target and not a common invariant virtual address. > > Although there's likely to be approximately zero interest in > multi-platform !MMU, relocating at boot time doesn't sound onerous, > should it be needed. x86 kernels already do that. Maybe ARM kernels > will eventually do that anyway for the same reason as x86. We already have something similar but simpler: CONFIG_ARM_PATCH_PHYS_VIRT. Except that the virtual address the kernel is using always remains the same, even if the physical address can move. Although this is not the case at the moment, the ARM kdump implementation could take advantage of this ability and avoid the copying of memory around. Nicolas ^ permalink raw reply [flat|nested] 23+ messages in thread
* Building for MMU-less vexpress targets 2012-11-06 23:40 ` Nicolas Pitre @ 2012-11-06 23:46 ` Jamie Lokier 0 siblings, 0 replies; 23+ messages in thread From: Jamie Lokier @ 2012-11-06 23:46 UTC (permalink / raw) To: linux-arm-kernel Nicolas Pitre wrote: > On Tue, 6 Nov 2012, Jamie Lokier wrote: > > > Nicolas Pitre wrote: > > > I really think that it makes no sense at all to support !MMU kernels in > > > a multi-platform kernel build, even if the set of included platforms > > > were all !MMU. The kernel has to be linked for the physical address of > > > the target and not a common invariant virtual address. > > > > Although there's likely to be approximately zero interest in > > multi-platform !MMU, relocating at boot time doesn't sound onerous, > > should it be needed. x86 kernels already do that. Maybe ARM kernels > > will eventually do that anyway for the same reason as x86. > > We already have something similar but simpler: CONFIG_ARM_PATCH_PHYS_VIRT. > Except that the virtual address the kernel is using always remains the > same, even if the physical address can move. Although this is not the > case at the moment, the ARM kdump implementation could take advantage of > this ability and avoid the copying of memory around. I wonder why x86 didn't go that route. Not that it matters. -- Jamie ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-01-08 19:22 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-05 17:36 Building for MMU-less vexpress targets Will Deacon 2012-11-05 18:03 ` Pawel Moll 2012-11-05 18:13 ` Will Deacon 2012-11-05 19:08 ` Arnd Bergmann 2012-11-06 12:20 ` Will Deacon 2012-11-06 17:33 ` Arnd Bergmann 2012-11-06 18:34 ` Will Deacon 2012-11-06 20:35 ` Arnd Bergmann 2012-11-06 20:58 ` Nicolas Pitre 2012-11-06 21:14 ` Arnd Bergmann 2012-11-06 22:14 ` Russell King - ARM Linux 2012-11-06 22:59 ` Rob Herring 2012-11-07 12:59 ` Arnd Bergmann 2012-11-07 13:39 ` Russell King - ARM Linux 2012-11-06 23:14 ` Nicolas Pitre 2012-11-07 10:21 ` Will Deacon 2012-11-07 13:29 ` Arnd Bergmann 2013-01-08 19:01 ` Jonathan Austin 2013-01-08 19:11 ` Arnd Bergmann 2013-01-08 19:22 ` Nicolas Pitre 2012-11-06 22:51 ` Jamie Lokier 2012-11-06 23:40 ` Nicolas Pitre 2012-11-06 23:46 ` Jamie Lokier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).