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? Alex > not problem to use it for the final MMU tables. We are exploring initializing > DDR before U-Boot, but we are not anywhere close yet. > > York > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
