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

[york sun]

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

That's the part I can't live with. Since we have very limited on-chip RAM, we
have to know limit the size. But again, I do see the benefit to use unified
structure for the 2nd 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
> 
> Compatibility with what? Do we really need this in an AArch64 world?

It's not up to me. The SoC was designed this way. By the way, this SoC can work
in AArch32 mode.

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

It is in high region. But as I tried to explain, the default physical mapping of
NOR flash (not MMU) is in low region out of reset.

York