On 02/24/2016 06:01 PM, Stephen Warren wrote:
On 02/24/2016 03:55 AM, Alexander Graf wrote:
On 23.02.16 14:17, Simon Glass wrote:
Hi Alex,
On 21 February 2016 at 18:57, Alexander Graf <ag...@suse.de> wrote:
The idea to generate our pages tables from an array of memory ranges
is very sound. However, instead of hard coding the code to create up
to 2 levels of 64k granule page tables, we really should just create
normal 4k page tables that allow us to set caching attributes on 2M
or 4k level later on.
So this patch moves the full_va mapping code to 4k page size and
makes it fully flexible to dynamically create as many levels as
necessary for a map (including dynamic 1G/2M pages). It also adds
support to dynamically split a large map into smaller ones when
some code wants to set dcache attributes.
With all this in place, there is very little reason to create your
own page tables in board specific files.
Signed-off-by: Alexander Graf <ag...@suse.de>
---
arch/arm/cpu/armv8/cache_v8.c | 346
+++++++++++++++++++++++++++++++------
arch/arm/include/asm/armv8/mmu.h | 68 ++++----
arch/arm/include/asm/global_data.h | 4 +-
arch/arm/include/asm/system.h | 3 +-
include/configs/thunderx_88xx.h | 14 +-
5 files changed, 332 insertions(+), 103 deletions(-)
Should the change to the thunderx file go in a separate patch?
We're changing semantics for some defines from "this define acts in
L1/L2 page table entries" to "this define is for level/block type PTEs".
So it's tied to this patch :).
diff --git a/arch/arm/cpu/armv8/cache_v8.c
b/arch/arm/cpu/armv8/cache_v8.c
index 9229532..4369a83 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -2,6 +2,9 @@
* (C) Copyright 2013
* David Feng <feng...@phytium.com.cn>
*
+ * (C) Copyright 2016
+ * Alexander Graf <ag...@suse.de>
+ *
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -9,35 +12,40 @@
#include <asm/system.h>
#include <asm/armv8/mmu.h>
-DECLARE_GLOBAL_DATA_PTR;
-
-#ifndef CONFIG_SYS_DCACHE_OFF
+/* #define DEBUG_MMU */
-#ifdef CONFIG_SYS_FULL_VA
-static void set_ptl1_entry(u64 index, u64 ptl2_entry)
-{
- u64 *pgd = (u64 *)gd->arch.tlb_addr;
- u64 value;
+#ifdef DEBUG_MMU
+#define DPRINTF(a, ...) printf("%s:%d: " a, __func__, __LINE__,
__VA_ARGS__)
+#else
+#define DPRINTF(a, ...) do { } while(0)
+#endif
Can you use the normal DEBUG and debug()?
Uh, I guess so, yeah.
- value = ptl2_entry | PTL1_TYPE_TABLE;
- pgd[index] = value;
-}
+DECLARE_GLOBAL_DATA_PTR;
-static void set_ptl2_block(u64 ptl1, u64 bfn, u64 address, u64
memory_attrs)
-{
- u64 *pmd = (u64 *)ptl1;
- u64 value;
+#ifndef CONFIG_SYS_DCACHE_OFF
- value = address | PTL2_TYPE_BLOCK | PTL2_BLOCK_AF;
- value |= memory_attrs;
- pmd[bfn] = value;
-}
+/*
+ * With 4k page granule, a virtual address is split into 4 lookup
parts
+ * spanning 9 bits each:
+ *
+ * _______________________________________________
+ * | | | | | | |
+ * | 0 | Lv0 | Lv1 | Lv2 | Lv3 | off |
+ * |_______|_______|_______|_______|_______|_______|
+ * 63-48 47-39 38-30 29-21 20-12 11-00
+ *
+ * mask page size
+ *
+ * Lv0: FF8000000000 --
+ * Lv1: 7FC0000000 1G
+ * Lv2: 3FE00000 2M
+ * Lv3: 1FF000 4K
+ * off: FFF
+ */
+#ifdef CONFIG_SYS_FULL_VA
static struct mm_region mem_map[] = CONFIG_SYS_MEM_MAP;
I am not ken on the idea of using a big #define table on these boards.
Is there not a device-tree binding for this that we can use? It is
just a data table, We are moving to Kconfig and eventually want to
drop the config files.
I'll move this into board files which then can do whatever they like
with it - take if from a #define in a header, populate it dynamically
from device tree, do something halfway in between, whatever fits your
needs best :).
Btw, if you want to use dt for it, you don't need to add any new
bindings at all. Simply take all of your device regs/ranges and memory
ranges and gobble them into the memory map.
That's only true if every single MMIO region that the code accesses is
already represented in DT already, or any DT conversion patches also
add any missing devices. It's quite unlikely that even on heavily
DT-dependant platforms that /all/ in-use MMIO regions are already
represented in DT. Such a conversion would need quite significant
testing.
Well, it's something I'd leave to the SoC / board maintainer really.
With v2 you can now fiddle with the map as much as you like inside your
code. The important bit to me is that we have a standardized path on how
we map the mem_map table into the MMU. I don't care how we fetch the table.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
