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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2015-04-05 18:10, Russell King - ARM Linux wrote:
> On Sat, Apr 04, 2015 at 01:56:20AM +0200, Stefan Agner wrote:
>> 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@xxxxxxxx>
>> >> ---
>> >>  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.
> 
> I think what I'd like to see is, in the top level choice:
> 
> 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?

> 
> 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:
With the introduction of ARCH_MULTI_V7M, we add something like a top
level v7M compliant selection. Due to the !MMU dependencies of all other
CPU families the family selection is minimal (when selecting !MMU):

    *** CPU Core family selection *** 
[*] ARMv7-M based platforms (Cortex-M)

And since ARCH_MULTI_V7M is not part of ARCH_MULTI_V6_V7 or anything,
the whole SoC selection contains only sensible SoC's without further
changes (also within the i.MX family, currently only "Vybrid Family
VF610 support" is selectable):

[ ] MMU-based Paged Memory Management Support                       
    ARM system type (Allow multiple platforms to be selected)  ---> 
    Multiple platform selection  --->                               
[*] Energy Micro efm32                                              
[*] Freescale i.MX family  --->    
    *** Processor Type ***
...

> So, it's very similar to multiplatform in the sense that several SoCs
> can be built together, but we preserve the need not to build
> incompatible stuff together.

As far as I can tell, this is already the case with that patchset.

The differences boil down to on which level we split the v7M CPU
selection apart: On ARCH_* level or ARCH_MULTI_* level. Given that we
allow a multiplatform _v7M kernel, the latter sounds more natural to
me...

Are there arguments to split v7M CPU selection apart on ARCH_* level
which I don't see?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux