Re: [PATCH 1/2] powerpc: enable the relocatable support for the fsl booke 32bit kernel

[Scott Wood <scottwood@freescale.com>]

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 =20
> align to
> > >256M before mapping the PAGE_OFFSET for a relocatable kernel, we =20
> also
> > >change the init tlb map to 256M size.
> >
> > Why 256M?
>=20
> 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.
>=20
> Yes. But since RELOCATABLE is a superset of DYNAMIC_MEMSTART, we can =20
> always
> use RELOCATABLE instead of DYNAMIC_MEMSTART for fsl booke board in =20
> any cases.

The extra flexibility of RELOCATABLE may help some use cases, but you'd =20
still require the entire 256M naturally aligned region containing the =20
kernel to be present and owned by this instance of Linux.

> So DYNAMIC_MEMSTART will seem not so useful after we enable this =20
> feature.

Then why doesn't this patch remove it?

> >  And
> > what about boards with less than 256 MiB of RAM?
>=20
> 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 =20
is executable and/or not guarded, or you could get speculative accesses =20
to who-knows-what.  Even if RAM is present there but owned by some =20
other entity, you could be creating illegal aliases if that other =20
entity mapped it cache-inhibited or similar.

-Scott=