[PATCH 0/3] ARM: nommu: R-class fixes

[Vladimir Murzin]

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
> 
>