Message-ID: <8737db3eea65563054df98c932870590@agner.ch>
Date:	Mon, 06 Apr 2015 10:38:10 +0200
From:	Stefan Agner <stefan@...er.ch>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	shawn.guo@...aro.org, kernel@...gutronix.de,
	u.kleine-koenig@...gutronix.de, jason@...edaemon.net,
	olof@...om.net, arnd@...db.de, daniel.lezcano@...aro.org,
	tglx@...utronix.de, mark.rutland@....com, pawel.moll@....com,
	robh+dt@...nel.org, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, marc.zyngier@....com,
	mcoquelin.stm32@...il.com, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU

On 2015-04-06 10:15, Russell King - ARM Linux wrote:
> On Mon, Apr 06, 2015 at 01:50:17AM +0200, Stefan Agner wrote:
>> 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...
> 
> Let me repeat: enabling multiplatform with !MMU is wrong.  It allows
> you to build totally incompatible machines together that will never
> boot.  It will cause users headaches when they try to build for something
> only to find that they've got a bunch if incompatible other platforms
> or other symbols enabled too.  Then they've got to work out how to
> disable those, and that's not easy with the abuse that "select" gets.
> 
>> > 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.
> 
> Thanks for telling me something I already know, and already have a patch
> to fix.
> 
>> > 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.
> 
> You've identified the problem that I ran into... I already have this
> fixed, thanks.
> 
>> > 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.
> 
> Exactly, but without the ability to select the other ARCH_MULTI_* symbols
> along with 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.
> 
> No, you'd have a top level ARCH_SINGLE_ARMV7M.  You would then be
> able to select the MXC V7M platforms along side any other V7M platform
> because the V7M platforms share the same basic memory layout.
>
> What you couldn't do is include _both_ support for Cortex-A9 and
> Cortex-M4 in one image - the two are incompatible because they have
> different physical address space layouts.

We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And
so we would do with V7M too. Just because it's in multiplatform doesn't
mean we need to mix things up.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists