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

[Simon Glass]

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...?

>
> 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