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.
Is there any reason why 64M won't continue to work here?
> This tightens the alignment requirement for dynamic memstart.
Yes. But since RELOCATABLE is a superset of DYNAMIC_MEMSTART, we can
always
use RELOCATABLE instead of DYNAMIC_MEMSTART for fsl booke board in
any cases.
The extra flexibility of RELOCATABLE may help some use cases, but you'd
still require the entire 256M naturally aligned region containing the
kernel to be present and owned by this instance of Linux.
So DYNAMIC_MEMSTART will seem not so useful after we enable this
feature.
Then why doesn't this patch remove it?
> And
> what about boards with less than 256 MiB of RAM?
It should be fine. We just create the map in the tlb. The MM still use
the real size of memory.
No, you must not map anything that is not present with a mapping that
is executable and/or not guarded, or you could get speculative accesses
to who-knows-what. Even if RAM is present there but owned by some
other entity, you could be creating illegal aliases if that other
entity mapped it cache-inhibited or similar.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
