devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: shawn.guo@linaro.org, kernel@pengutronix.de,
	u.kleine-koenig@pengutronix.de, jason@lakedaemon.net,
	olof@lixom.net, arnd@arndb.de, daniel.lezcano@linaro.org,
	tglx@linutronix.de, mark.rutland@arm.com, pawel.moll@arm.com,
	robh+dt@kernel.org, ijc+devicetree@hellion.org.uk,
	galak@codeaurora.org, marc.zyngier@arm.com,
	mcoquelin.stm32@gmail.com, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU
Date: Sat, 04 Apr 2015 01:56:20 +0200	[thread overview]
Message-ID: <1f84d767d3bb8a8c470a26064cba454e@agner.ch> (raw)
In-Reply-To: <20150403200931.GD13898@n2100.arm.linux.org.uk>

On 2015-04-03 22:09, Russell King - ARM Linux wrote:
> On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote:
>> In order to support SoC with heterogenous CPU architectures (such
>> as Freescale Vybrid/i.MXSX) it is preferable to use the same
>> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU
>> CPU. Hence allow to select MULTIPLATFORM even without MMU.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>>  arch/arm/Kconfig | 21 ++++++++++-----------
>>  1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 9f1f09a..636cb3f 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -230,7 +230,7 @@ config VECTORS_BASE
>>  	  in size.
>>
>>  config ARM_PATCH_PHYS_VIRT
>> -	bool "Patch physical to virtual translations at runtime" if EMBEDDED
>> +	bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU)
>>  	default y
> 
> This makes no sense.  Multiplatform MMU _requires_ this feature, so why
> offer it to the user when multiplatform is enabled _and_ MMU is enabled?

I see, this is plain wrong. Will replace that with a select ... if MMU
in multiplatform.

> Patch 7817/1 in the patch system tried doing something like you're trying
> to do here - I wonder whether you've reviewed the mailing list for
> previous discussions.

I did some research at RFC/v1 time and mainly looked into Arnd's git
trees. Most patches just open up !MMU for multiplatform. What I'm trying
to do here is to enable !MMU with multiplatform while keeping the impact
as little as possible, e.g. by making all other platforms in
multiplatform dependent on MMU.

See also
https://www.marc.info/?l=linux-kernel&m=141997848124399&w=2

> Given that it's Easter, I'm not going to re-state what I said last time
> this came up, but instead leave you to do some research.  For example,
> reading message id <20130819232411.GX23006@n2100.arm.linux.org.uk>...

Also looked at some other messages about this topic, but I guess quotes
from the message above will do to discuss this further:
> Now, here's the question: can multiplatform ever work properly on nommu?
> 
> We get multiplatform working on MMU by using the MMU to provide a more
> consistent view of the system.  On noMMU, we don't have that.  So if
> your kernel is built to run assuming that it will be located in ram at
> location X on platform Y, that isn't going to work if platform Z doesn't
> have RAM there.

The platforms I primarily have in mind (heterogeneous multi-processing
SoC's with MMU/!MMU processors) would actually allow such a
multiplatform kernel: i.MX6 SoloX as well as Vybrid have the main memory
in the same location, hence one could build a multiplatform !MMU kernel
for this two devices. Of course, this is possible more by chance. I also
did not tried it yet. I don't have a i.MX6 SoloX device.

> My feeling is that the motivation behind this patch is to avoid an
> amount of yuckyness associated with trying to enable Versatile Express
> support outside of the multiplatform container - it's not really about
> being able to build a single zImage which works on all noMMU platforms.
> So, I don't think this is the right solution to this problem.

I must admit that this was the main motivation for me too. My first
approach was to create a set of completely independent config symbols:
http://marc.info/?l=linux-arm-kernel&m=141756604900611&w=2

However, I'm sure this could be done better and with less config
symbols.

So, if you think it would be worth enabling multiplatform for these
devices (Vybrid/i.MX6 SoloX), I would prepare a patchset which does it
while not converting EFM32 to multiplatform (as patch 08/11 currently
does).

If you think it's also not worth for those devices, I will try to enable
ARCH_MXC/SOC_VF610 with !MMU and !MULTIPLATFORM...

--
Stefan

  reply	other threads:[~2015-04-03 23:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03 19:44 [PATCH v4 00/11] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
     [not found] ` <1428090292-21693-1-git-send-email-stefan-XLVq0VzYD2Y@public.gmane.org>
2015-04-03 19:44   ` [PATCH v4 01/11] genirq: generic chip: support hierarchy domain Stefan Agner
2015-04-03 19:44   ` [PATCH v4 02/11] irqchip: nvic: support hierarchy irq domain Stefan Agner
2015-04-03 19:44   ` [PATCH v4 03/11] irqchip: vf610-mscm: support NVIC parent Stefan Agner
2015-04-03 19:44   ` [PATCH v4 04/11] ARM: ARMv7M: define size of vector table for Vybrid Stefan Agner
2015-04-03 19:44   ` [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU Stefan Agner
2015-04-03 20:09     ` Russell King - ARM Linux
2015-04-03 23:56       ` Stefan Agner [this message]
     [not found]         ` <1f84d767d3bb8a8c470a26064cba454e-XLVq0VzYD2Y@public.gmane.org>
2015-04-05 16:10           ` Russell King - ARM Linux
2015-04-05 22:19             ` Stefan Agner
     [not found]               ` <24394c50bcd8000c21aca0360fd20b6f-XLVq0VzYD2Y@public.gmane.org>
2015-04-05 22:44                 ` Russell King - ARM Linux
2015-04-05 23:50                   ` Stefan Agner
2015-04-06  8:15                     ` Russell King - ARM Linux
2015-04-06  8:38                       ` Stefan Agner
2015-04-06  8:54                         ` Russell King - ARM Linux
2015-04-06  9:33                           ` Stefan Agner
2015-04-06 10:13                             ` Russell King - ARM Linux
2015-04-03 19:44   ` [PATCH v4 09/11] ARM: vf610: enable Cortex-M4 on Vybrid SoC Stefan Agner
2015-04-03 19:44 ` [PATCH v4 05/11] clocksource: add dependencies for Vybrid pit clocksource Stefan Agner
2015-04-03 19:44 ` [PATCH v4 06/11] ARM: unify MMU/!MMU addruart calls Stefan Agner
2015-04-03 19:44 ` [PATCH v4 08/11] ARM: efm32: move into multiplatform Stefan Agner
2015-04-03 19:44 ` [PATCH v4 10/11] ARM: dts: add support for Vybrid running on Cortex-M4 Stefan Agner
2015-04-03 19:44 ` [PATCH v4 11/11] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4 Stefan Agner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f84d767d3bb8a8c470a26064cba454e@agner.ch \
    --to=stefan@agner.ch \
    --cc=arnd@arndb.de \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jason@lakedaemon.net \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=shawn.guo@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).