On 02/23/2016 06:17 AM, Simon Glass wrote:
Hi Alex,
On 21 February 2016 at 18:57, Alexander Graf <[email protected]> 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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
