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

[Alexander Graf]

On Feb 22, 2016, at 7:12 PM, york sun <york.sun at nxp.com> wrote:

> 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 size is determined dynamically from the memory map using some code that (as Steven found) is not 100% sound, but works well enough so far :).

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

Compatibility with what? Do we really need this in an AArch64 world?

For 32bit code I can definitely understand why you'd want to have phys != virt. But in a pure 64bit world (which this target really is, no?) I see little benefit on it.

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

I might be missing the obvious, but why can't the environmental variables live in high regions?


Alex