On Feb 22, 2016, at 7:12 PM, york sun <york....@nxp.com> wrote: > On 02/22/2016 10:02 AM, Alexander Graf wrote: >> >> >>> Am 22.02.2016 um 18:37 schrieb york sun <york....@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
