On 02/23/2016 09:42 PM, Simon Glass wrote:
Hi Stephen,
On 23 February 2016 at 13:33, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 02/23/2016 01:00 PM, Simon Glass wrote:
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.
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).
Didn't this get discussed to death in the Linux mailing list with the
result that platform data was abolished in favour of device tree? From
my perspective:
I was not aware that decisions within the Linux kernel applied to U-Boot
unilaterally. If that is true, there are many other decisions that
should be carried over but aren't.
- the relevant configuration is mostly in one place
- we can share it with Linux
In some cases that is true. However, I find it extremely unlikely that
the Linux kernel is going to be modified to parse its MMU configuration
from DT, especially as Linux doesn't use the same VA layout that U-Boot
does currently.
If your argument holds water for this specific case, then the DT binding
for MMU configuration needs to be proposed and reviewed on the DT
mailing list.
- it is easier to maintain a few text files than dispersed platform data
- it permits easy run-time configuration, avoiding the need for
multiple builds for trivial differences
- it converts to platform data fairly easily at run-time, so most of
the code can still deal with that
- it is easy to have base SoC data that is expanded/overridden by board data
- the configuration can be listed and queried easily, by U-Boot at
run-time, or by build systems
- device tree is a well-understood format with robust tools
I suspect others have done a much more thoughtful and persuasive analysis.
If you want to pick up on these points I suggest starting a new thread!
To the other points, I largely disagree with them. All of the points can
be easily argued against, but since I've done so repeatedly in detail in
the past I won't bother repeating myself yet again, except simply to
mention this fact.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
