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...? > > 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. That seems OK. Perhaps a table in board-specific code and a way to add new entries on top. Bear in mind that this happens before relocation but quite late in the pre-reloc init sequence. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
