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

Alexander Graf agraf at suse.de
Mon Feb 22 19:02:49 CET 2016



> Am 22.02.2016 um 18:37 schrieb york sun <york.sun at nxp.com>:
> 
>> 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.

Yup, and I think it should be fairly doable to move the early generation into the same table format - maybe even fully reuse the generic code.

The thing that I tripped over while attempting conversion was that you don't always map phys==virt, unless other boards, and I didn't fully understand why.

Alex



More information about the U-Boot mailing list