On 02/23/2016 01:00 PM, Simon Glass wrote:
Hi Stephen,
On 23 February 2016 at 10:40, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/23/2016 10:30 AM, Simon Glass wrote:
Hi Stephen,
On 23 February 2016 at 10:21, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/23/2016 06:17 AM, Simon Glass wrote:
Hi Alex,
On 21 February 2016 at 18:57, Alexander Graf agraf@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.
I'd like to see an explicit enumeration of the benefits; I'm not aware of any (either benefits, or such an enumeration). Board-specific data can just as easily (actually, more easily due to lack of need for parsing code) be stored in C data structures vs. stored in DT.
Or put another way, the simple fact that some data is board-specific does not in-and-of-itself mean there's a benefit to putting it into DT. To move something into DT, we should be able to enumerate some other benefit, such as: - Speeds up boot time. - Allows code to be simpler. - Simplifies editing the data.
(Note that I don't believe any of those example potential benefits are actually true, but in fact are the opposite of the truth).
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.
I expect this data is SoC-specific. At least for Tegra in the codebase, that's certainly true. I believe it's true for other SoCs in the current codebase too. I don't expect this to change going forward, at the very least for Tegra.