From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 23 Feb 2016 10:21:24 -0700 Subject: [U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic In-Reply-To: References: <1456106232-233210-1-git-send-email-agraf@suse.de> <1456106232-233210-3-git-send-email-agraf@suse.de> Message-ID: <56CC9514.4050404@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/23/2016 06:17 AM, Simon Glass wrote: > Hi Alex, > > On 21 February 2016 at 18:57, Alexander Graf 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. >> 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 would strongly object to making the MMU setup depend on device tree parsing. This is low-level system code that should be handled purely by simple standalone C code. Having some CPU-/SoC-/board-specific code define the table, rather than having it be a #define, seems fine though, if the code in the current patch needs to change.