On Thu, Jun 27, 2013 at 08:52:20PM -0500, Scott Wood wrote: > On 06/27/2013 08:36:37 PM, Kevin Hao wrote: > >On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote: > >> On 06/26/2013 09:00:33 PM, Kevin Hao wrote: > >> >This is based on the codes in the head_44x.S. Since we always > >align to > >> >256M before mapping the PAGE_OFFSET for a relocatable kernel, > >we also > >> >change the init tlb map to 256M size. > >> > >> Why 256M? > > > >For two reasons: > > 1. This is the size which both e500v1 and e500v2 support. > > 2. Since we always use the PAGE_OFFSET as 0xc0000000, the 256M is > > max alignment value we can use for this virtual address. > > 0xc0000000 is 1G-aligned, so I don't see why 256M is the maximum > (after verifying that enough memory is present with the right > alignment, of course). The TLB1 savings would probably not be > enough to justify figuring that out, though.
Sorry, I didn't make myself clear. Yes, the 0xc0000000 is 1G-aligned. For a 32bit kernel we only have a 1G memory region for the kernel space, but we can't use all of it for direct map. So we always set the __max_low_memory to 0x30000000. And for e500 core, it doesn't support 512M page size. So the 256M is the max page size we can use for a 32bit kernel. And since we always cover the boot code in the first tlb entry, we then use the 256M as the alignment value for the relocatable kernel. Thanks, Kevin > > -Scott
pgp_AAVAj6WfT.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
