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

[york sun]

On 02/22/2016 10:02 AM, Alexander Graf wrote:
> 
> 
>> 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.

What's the size for the MMU tables? I think it may be simpler to use static
tables for our early stage.

> 
> 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.
>
True. We have some complication on the address mapping. For compatibility, each
device is mapped (partially) under 32-bit space. If the device is too large to
fit, the rest is mapped to high regions. I remember one particular case on top
of my head. It is the NOR flash we use for environmental variables. U-boot uses
that address for saving, but also uses that for loading during booting. For our
case, the NOR flash doesn't fit well in the low region, so it is remapped to
high region after booting. To make the environmental variables accessible during
boot, we mapped the high region phys with different virt, so u-boot doesn't have
to know the low region address.

York