[U-Boot] [PATCH] arm64: Keep macro PGTABLE_SIZE for non-full-va map

[Alexander Graf]

On 21.03.16 20:39, york sun wrote:
> On 03/21/2016 12:29 PM, Alexander Graf wrote:
>>
>> On Mar 21, 2016, at 8:23 PM, york sun <york.sun at nxp.com> wrote:
>>
>>> On 03/21/2016 12:12 PM, Alexander Graf wrote:
>>>>
>>>> On Mar 21, 2016, at 7:59 PM, York Sun <york.sun at nxp.com> wrote:
>>>>
>>>>> Commit 7985cdf removed non-full-va map code, replaced PGTABLE_SIZE
>>>>> with get_page_table_size() function for all. It is incorrect for
>>>>> platforms with non-full-va mapping, at this moment Layerscape SoCs.
>>>>>
>>>>> Signed-off-by: York Sun <york.sun at nxp.com>
>>>>> CC: Alexander Graf <agraf at suse.de>
>>>>> CC: Alison Wang <alison.wang at nxp.com>
>>>>> CC: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>
>>>>> ---
>>>>> arch/arm/include/asm/system.h |    4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
>>>>> index ac1173d..fab6f0c 100644
>>>>> --- a/arch/arm/include/asm/system.h
>>>>> +++ b/arch/arm/include/asm/system.h
>>>>> @@ -20,7 +20,11 @@
>>>>> #ifndef __ASSEMBLY__
>>>>>
>>>>> u64 get_page_table_size(void);
>>>>> +#ifdef CONFIG_SYS_FULL_VA
>>>>
>>>> This macro doesn't exist anymore. We need to do something different. Let me cook up a patch.
>>>>
>>>
>>> Thanks.
>>>
>>> After this, I want to discuss the possibility to use the new infrastructure for
>>> our SoCs. The key is we have limited on-chip RAM before DDR is initialized. We
>>> cannot use full va mapping for this reason for early MMU tables. We should have
>>
>> I'm not sure I understand this part. How is full va different from your current approach? The only really major difference is that you can do non-1:1 maps.
>>
>> If all maps are aligned, you shouldn't waste too much memory compared to your current approach, no?
>>
> The new full va map doesn't map all space, only the selected mapping in the
> table, correct? If yes, we should be able to fix the tables in the on-chip RAM.

Yes, it maps as much as it needs to fit your largest page in that you
describe in the table.

> I think my case is different because I use two tables. The final table is
> equivalent to those everyone else is using. The early table is different with
> non 1:1 mapping. This feature shouldn't be too hard to add.

I think it would be trivial to add. Just call the existing functions
with an explicit table passed as parameter instead of the implicit
global variable :).

> Now it comes the third part. The early table is so early, we don't have gd setup
> yet, or printf. We need to change the table handling to accept an argument,
> instead of using gd for table pointer.

Yes, exactly. That's much cleaner anyway, so I'd welcome that change.


Alex