From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Mon, 21 Mar 2016 20:42:23 +0100 Subject: [U-Boot] [PATCH] arm64: Keep macro PGTABLE_SIZE for non-full-va map In-Reply-To: References: <1458586790-20847-1-git-send-email-york.sun@nxp.com> <2BBCF2B2-1EC6-47B4-9696-D19643C3CE41@suse.de> Message-ID: <56F04E9F.3040502@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >> >>> On 03/21/2016 12:12 PM, Alexander Graf wrote: >>>> >>>> On Mar 21, 2016, at 7:59 PM, York Sun 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 >>>>> CC: Alexander Graf >>>>> CC: Alison Wang >>>>> CC: Prabhakar Kushwaha >>>>> --- >>>>> 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