arm64: Unify MMU code
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest9 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/9 | arm64: Make full va map code more dynamic | +0 | 1 reply | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 0 replies | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 1 reply | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 1 reply | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 1 reply | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 1 reply | |
| 2/9 | arm64: Make full va map code more dynamic | +0 | 0 replies | |
| 4/9 | tegra: Replace home grown mmu code with generic table approach | +0 | 2 replies | |
| 4/9 | tegra: Replace home grown mmu code with generic table approach | +0 | 0 replies |
Reviews trailers per patch
None of the 9 patches has a Reviewed-by or Acked-by.
| Patch | Stephen Warren |
|---|---|
| Series | T-b |
| 2/9 | |
| 2/9 | |
| 2/9 | |
| 2/9 | |
| 2/9 | |
| 2/9 | |
| 2/9 | |
| 4/9 | |
| 4/9 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [U-Boot] [PATCH 0/9] arm64: Unify MMU code
Quoted 22 lines · Alexander Graf
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.
Quoted 7 lines
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.
The series,
I tested p2371-2180 (Jetson TX1) ARMv8 development board, including PCIe-based RTL8169 Ethernet, which makes use of the APIs to allocate/convert memory as/to uncached.