From: vladimir.murzin@arm•com (Vladimir Murzin)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/3] ARM: nommu: R-class fixes
Date: Wed, 27 Apr 2016 10:10:19 +0100 [thread overview]
Message-ID: <572081FB.5090303@arm.com> (raw)
In-Reply-To: <5591261.0X3WRSsdGl@wuerfel>
On 26/04/16 19:12, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:
>> On 26/04/16 12:59, Arnd Bergmann wrote:
>>> On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
>>>> On 26/04/16 10:10, Arnd Bergmann wrote:
>>>>>>> What hardware platform do you use? It would be nice to make it a little
>>>>>>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with
>>>>>>> the MMU disabled.
>>>>>>
>>>>>> Currently I'm dealing mostly with ARMv7-R FVP models which represents
>>>>>> Vexpress with R-class tile (it is why this mini series have MPU
>>>>>> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite
>>>>>> in doubt if it is feasible.
>>>>>
>>>>> What is the difference? I always assumed that ARMv7-R and ARMv7-A are
>>>>> sufficiently close that you can run the same kernel on both as long
>>>>> as you use neither the MMU nor the MPU.
>>>>
>>>> Right they are quite close and shares a lot of code except MMU and MPU,
>>>> and I'd think without MMU/MPU such configurations are limited with UP
>>>> only. I've not though of such option before, so I'd need to try and see.
>>>>
>>>> On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think
>>>> that any ARMv7 platform should be available for selection if CONFIG_MMU
>>>> is deselected. At least such approach gives better build coverage and if
>>>> there are platforms which suffer from such assumption runtime they can
>>>> be guarded with COMPILE_TEST.
>>>
>>> I think one problem is that with MMU disabled ARMv7-A, you implicitly
>>> disable the caches and that is probably what you are thinking of for
>>> SMP support as well (atomic instructions need caches).
>>
>> Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for
>> such builds, but it can be addressed with 1:1 mappings you've described
>> below
>
> But that's not any different between ARMv7-A and ARMv7-R, right?
Right, but it'd make sort of feeling "as soon as I disable MMU it stops
booting" for ARMv7-A where for ARMv7-R it likely won't boot till these
parameters supplied. However, it is not a show stopper, just a reminder
that extra configuration step might be needed.
>
>>> However, this can be worked around using a static page table set up
>>> at boot time that creates hugepage entries with appropriate flags for
>>> RAM and I/O areas. If we ever had a usecase for running this setup
>>> in production, we could even fake an MPU that way.
>>
>> I'd think that support for FDPIC would make it one step closer.
>
> Yes, that would be very useful.
>
>> I conclude that we don't want dedicated option for R-class cores and we
>> start from assumption that NOMMU covers: M-, R- and A- (without MMU or
>> 1:1 mapping) cores. Please, correct me.
>
> I'm still undecided on that. On the one hand it would be nice to support
> building a kernel that can run on both ARMv7-A and ARMv7-R, especially
> when you are talking about pluggable CPU modules on the same baseboard
> in case of RealView and Versatile Express.
>
> On the other hand, separating the two has the advantage of keeping it
> simple, as we don't have to worry about all the ARMv7-A platforms
> and whether we actually want to allow their kernels to be built with
> MMU disabled.
>
Ok, what if we start with your approach explicitly saying which platform
wants to be listed when CONFIG_MMU is deselected (I think R-class is the
first user here) gradually extending such list with ARMv7-A? There is
(little?) chance that at some point we can support kernel which can run
on both configurations.
Vladimir
> Arnd
>
>
next prev parent reply other threads:[~2016-04-27 9:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin
2016-04-22 11:43 ` [PATCH 1/3] ARM: nommu: fix PMSAv7 setup Vladimir Murzin
2016-04-22 11:43 ` [PATCH 2/3] ARM: nommu: change memory reserve for the vectors Vladimir Murzin
2016-04-22 11:43 ` [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard Vladimir Murzin
2016-04-27 10:49 ` [PATCH 3/3] ARM: domain: move {set, get}_domain " Russell King - ARM Linux
2016-04-27 12:16 ` Vladimir Murzin
2016-04-28 13:50 ` Russell King - ARM Linux
2016-04-28 14:44 ` Vladimir Murzin
2016-04-28 14:59 ` Russell King - ARM Linux
2016-04-28 15:06 ` Vladimir Murzin
2016-04-23 6:54 ` [PATCH 0/3] ARM: nommu: R-class fixes Afzal Mohammed
2016-04-25 7:55 ` Vladimir Murzin
2016-04-25 12:59 ` Arnd Bergmann
2016-04-25 13:30 ` Afzal Mohammed
2016-04-26 8:17 ` Vladimir Murzin
2016-04-26 8:17 ` Vladimir Murzin
2016-04-26 9:10 ` Arnd Bergmann
2016-04-26 10:57 ` Vladimir Murzin
2016-04-26 11:59 ` Arnd Bergmann
2016-04-26 12:24 ` Vladimir Murzin
2016-04-26 18:12 ` Arnd Bergmann
2016-04-27 9:10 ` Vladimir Murzin [this message]
2016-04-27 9:50 ` Arnd Bergmann
2016-04-27 10:55 ` Vladimir Murzin
2016-04-27 11:18 ` Arnd Bergmann
2016-04-26 15:23 ` Afzal Mohammed
2016-04-28 9:41 ` Maxime Coquelin
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=572081FB.5090303@arm.com \
--to=vladimir.murzin@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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