Date:	Mon, 6 Apr 2015 09:15:23 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Stefan Agner <stefan@...er.ch>
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 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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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