ARM: nommu: R-class fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] ARM: nommu: R-class fixes
Quoted 31 lines · Arnd Bergmann
Quoted 30 lines · On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote:
Quoted 28 lines · Arnd Bergmann
Quoted 18 lines · On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote:
Quoted 4 lines · Arnd Bergmann
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 5 lines
On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if
CONFIG_MMUis deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded withCOMPILE_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).
Quoted 5 lines
Quoted 3 lines
Another problem is that we need to provide
DRAM_BASEandDRAM_SIZEfor such builds, but it can be addressed with 1:1 mappings you've described belowBut 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.
Quoted 19 lines
Quoted 7 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 3 lines
Arnd