Building for MMU-less vexpress targets

Building for MMU-less vexpress targets

[Will Deacon]

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

Building for MMU-less vexpress targets

[Pawel Moll]

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?

Building for MMU-less vexpress targets

[Will Deacon]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Will Deacon]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Will Deacon]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Nicolas Pitre]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Russell King - ARM Linux]

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.

Building for MMU-less vexpress targets

[Jamie Lokier]

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

Building for MMU-less vexpress targets

[Rob Herring]

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
> 

Building for MMU-less vexpress targets

[Nicolas Pitre]

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

Building for MMU-less vexpress targets

[Nicolas Pitre]

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

Building for MMU-less vexpress targets

[Jamie Lokier]

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

Building for MMU-less vexpress targets

[Will Deacon]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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

Building for MMU-less vexpress targets

[Russell King - ARM Linux]

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...

Building for MMU-less vexpress targets

[Jonathan Austin]

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

Building for MMU-less vexpress targets

[Arnd Bergmann]

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>

Building for MMU-less vexpress targets

[Nicolas Pitre]

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