On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote: > Today, the only way to load kernels whose size is greater than 8Mbytes is to > activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is > limited to 8Mbytes. This patch adds the capability to select the size of > initial > memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB > is active or not. It allows to load "big" kernels (for instance when > activating > CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB. > > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> > > diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -980,6 +980,29 @@ > config PIN_TLB > bool "Pinned Kernel TLBs (860 ONLY)" > depends on ADVANCED_OPTIONS && 8xx > + > +choice > + prompt "Initial Data Memory Mapped on 8xx" > + default 8xx_MAP_8M > + depends on ADVANCED_OPTIONS && 8xx > + > +config 8xx_INIT_MAP_8M > + bool "8 Mbytes" > + > +config 8xx_INIT_MAP_16M > + bool "16 Mbytes" > + > +config 8xx_INIT_MAP_24M > + bool "24 Mbytes"
Are you working with a loader that passes initial-mapped-area size in r7 as per ePAPR? If so, we could rely on that at runtime. If you're using a non-ancient U-Boot, it should qualify here even if it's not fully ePAPR compliant (it passes the value of the bootm_mapsize variable in r7). > -#ifdef CONFIG_PIN_TLB > +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M) > /* Map two more 8M kernel data pages. > */ > +#ifdef CONFIG_PIN_TLB > addi r10, r10, 0x0100 > mtspr SPRN_MD_CTR, r10 > +#endif > > lis r8, KERNELBASE@h /* Create vaddr for TLB */ > addis r8, r8, 0x0080 /* Add 8M */ > @@ -858,15 +860,19 @@ > addis r11, r11, 0x0080 /* Add 8M */ > mtspr SPRN_MD_RPN, r11 > > +#ifdef CONFIG_8xx_INIT_MAP_24M > +#ifdef CONFIG_PIN_TLB > addi r10, r10, 0x0100 > mtspr SPRN_MD_CTR, r10 > +#endif Are these ifdefs for CONFIG_PIN_TLB really needed? It shouldn't harm anything to use those entries even if they're not being pinned. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
