[U-Boot] [PATCH 0/9] arm64: Unify MMU code

[york sun]

On 02/21/2016 05:57 PM, Alexander Graf wrote:
> Howdy,
> 
> Currently on arm64 there is a big pile of mess when it comes to MMU
> support and page tables. Each board does its own little thing and the
> generic code is pretty dumb and nobody actually uses it.
> 
> This patch set tries to clean that up. After this series is applied,
> all boards except for the FSL Layerscape ones are converted to the
> new generic page table logic and have icache+dcache enabled.
> 
> The new code always uses 4k page size. It dynamically allocates 1G or
> 2M pages for ranges that fit. When a dcache attribute request comes in
> that requires a smaller granularity than our previous allocation could
> fulfill, pages get automatically split.
> 
> I have tested and verified the code works on HiKey (bare metal),
> vexpress64 (Foundation Model) and zynqmp (QEMU). The TX1 target is
> untested, but given the simplicity of the maps I doubt it'll break.
> ThunderX in theory should also work, but I haven't tested it. I would
> be very happy if people with access to those system could give the patch
> set a try.
> 
> With this we're a big step closer to a good base line for EFI payload
> support, since we can now just require that all boards always have dcache
> enabled.
> 
> I would also be incredibly happy if some Freescale people could look
> at their MMU code and try to unify it into the now cleaned up generic
> code. I don't think we're far off here.

Alex,

Unified MMU will be great for all of us. The reason we started with our own MMU
table was size and performance. I don't know much about other ARMv8 SoCs. For
our use, we enable cache very early to speed up running, especially for
pre-silicon development on emulators. We don't have DDR to use for the early
stage and we have very limited on-chip SRAM. I believe we can use the unified
structure for our 2nd stage MMU when DDR is up.

York