Hi Stephen, On 23 February 2016 at 10:40, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 02/23/2016 10:30 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 23 February 2016 at 10:21, Stephen Warren <swar...@wwwdotorg.org> >> wrote: >>> >>> On 02/23/2016 06:17 AM, 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. >>> >>> >>> >>>>> 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. >> >> >> Because...? > > > There is literally zero benefit from putting the exact same content into DT, > and hence having to run significantly more code to parse DT and get back > exactly the same hard-coded table.
We do this so that board-specific variations can be described in one place. In the board-specific case, there are benefits. > > DT is not a goal in-and-of-itself. In some cases there are benefits to > placing configuration data outside a binary, and in those cases DT is an > acceptable mechanism to do that. However, any benefit from doing so derives > from arguments for separating the data out of the code, not because "use DT" > is itself a benefit. That's fine as far as it goes. The config file is not an acceptable means of providing per-board or per-arch configuration. If it is arch-specific and/or SoC-specific, but NOT board-specific then we can have it in a C table in a source file (not the config header) that is built into the binary. If it is board-specific, it must use the device tree. What category are we talking about here? Unfortunately it's not entirely clear from the patches and I lack the knowledge/background to figure it out. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
