[U-Boot] [PATCH 2/9] arm64: Make full va map code more dynamic

[Stephen Warren]

On 02/23/2016 09:42 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 23 February 2016 at 13:33, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 02/23/2016 01:00 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 23 February 2016 at 10:40, Stephen Warren <swarren at 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 at 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 at 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.