[PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU

[Stefan Agner]

On 2015-04-06 00:44, Russell King - ARM Linux wrote:
> On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote:
>> On 2015-04-05 18:10, Russell King - ARM Linux wrote:
>> > config ARM_SINGLE_ARMV7M
>> > 	bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC"
>> > 	depends on !MMU
>> > 	select ARM_NVIC
>> > 	... etc ...
>>
>> I guess that would be ARCH_SINGLE_ARMV7M?
> 
> No, I meant ARM_SINGLE_xxx
> 
>> > which then allows a /multiplatform/ v7M kernel to be built, allowing the
>> > selection of EFM32, SOC_VF610, and any other v7M compliant SoC.
>>
>> In my view, that wouldn't end up being much different than what that
>> patchset is doing:
> 
> It's different.  It's different because we are _not_ enabling multiplatform.
> Multiplatform brings with it all the MMU-full stuff that we don't want on
> !MMU.

You mean config symbols? There are 2-3 config symbols we don't want with
ARCH_MULTI_V7M and we have to exclude. But there would be also a
duplication of some already given by multiplatform when creating a new
top level config symbol...
 
> You're thinking far too specifically about V7M here.  We have other !MMU
> CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs.
> 
> The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5
> CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and
> ARCH_MULTI_V5.  If we did that, we'll allow _every_ V4T and V5
> multiplatform to be selected, whether they're compatible with nommu
> or not - and whether they're compatible with each other or not.

Just from a selection view, ARM946 and ARM940 would still _not_ be
selectable because this change makes ARCH_MULTI_V4T/V5 being dependent
on MMU.

> 
> So, that kind of solution _doesn't_ scale to what we _once_ already
> allowed.
> 
>> As far as I can tell, this is already the case with that patchset.
> 
> What I'm trying to do here is to fix the cockup that the multiplatform
> conversion has created with previous generation noMMU and restore it
> back to where it should be without excluding the newer stuff from it.

Would be a partial revert (remove ARCH_MULTI_* from CPU_ARM940T and
CPU_ARM946E) of dc680b989d51 ("ARM: fix multiplatform allmodcompile") be
the right thing to do then? Given that ARCH_MULTI_V4T/V5 is MMU
dependent, those CPU's will not be selected even when building the
integrator multiplatform image... However, due to the selection
limitations outlined above, this would only be cosmetic anyway.
 
> What you're interested in is just the newer stuff.  You're approaching
> the problem from a different angle and thinking that your solution is
> the best.  I'm saying it has deficiencies.

When keeping the old CPU's out of multiplatform game properly, what
would speak against ARCH_MULTI_V7M? I still think if we allow a
multiplatform v7M image, it is cleaner to align that to the MMU
multiplatform stuff.

Maybe I don't really get the grasp of ARM_SINGLE_ARMV7M. In my
understanding it would be a new top level config symbol which kind of
merges ARCH_MULTIPLATFORM and ARCH_MULTI_V7M.

It is not my goal to enable !MMU on MULTIARCH per se. It's just that
when enabling V7M with ARCH_MULTIPLATFORM, it makes it easier to enable
the Cortex-M4 for the HMP platforms on those multiplatform only SoC's.
When creating a new config symbol on a high level, this advantage is
gone... I then could also create a top level ARCH_MXCV7M, which selects
multiplatform only ARCH_MXC.

--
Stefan