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....@nxp.com> wrote: >> >>> On 03/21/2016 12:12 PM, Alexander Graf wrote: >>>> >>>> On Mar 21, 2016, at 7:59 PM, York Sun <york....@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....@nxp.com> >>>>> CC: Alexander Graf <ag...@suse.de> >>>>> CC: Alison Wang <alison.w...@nxp.com> >>>>> CC: Prabhakar Kushwaha <prabhakar.kushw...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
