From: Scott Wood <scottwood@freescale•com>
To: Kevin Hao <haokexin@gmail•com>
Cc: linuxppc <linuxppc-dev@lists•ozlabs.org>
Subject: Re: [PATCH 1/2] powerpc: enable the relocatable support for the fsl booke 32bit kernel
Date: Mon, 1 Jul 2013 19:30:45 -0500 [thread overview]
Message-ID: <1372725045.8183.102@snotra> (raw)
In-Reply-To: <20130630073310.GA32268@pek-khao-d1.corp.ad.wrs.com> (from haokexin@gmail.com on Sun Jun 30 02:33:10 2013)
On 06/30/2013 02:33:10 AM, Kevin Hao wrote:
> On Thu, Jun 27, 2013 at 08:47:27PM -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.
> >
> > Is there any reason why 64M won't continue to work here?
>=20
> Yes. In general we would map the 0 ~ 256M memory region in the first
> tlb1 entry. If we align to 64M, the relocatable kernel would not work
> if loaded above 64M memory. For example, if we load a relocatable =20
> kernel
> at 64M memory, we will relocate it as:
> __pa(PAGE_OFFSET) =3D 0x4000000
>=20
> But in map_mem_in_cams function, it will create a memory map as:
> __pa(PAGE_OFFSET) =3D 0x0
>=20
> The kernel will definitely not work in this case.
That's a problem with map_mem_in_cams(), as discussed in the thread on =20
other patch. Perhaps fully solving those problems is not worthwhile at =20
this time, but we should at least be able to determine the TLB size =20
automatically based on the alignment of the address you're trying to =20
map. 64M would be used unless (address & (256M - 1)) >=3D 64M. I hope =20
we can continue to assume the kernel won't cross a 64M boundary.
> > >> 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?
>=20
> According to the Kconfig it is still used by 44x.
RELOCATABLE appears to be supported on 44x, and is what CRASH_DUMP uses =20
on 44x.
> And maybe someone still want to use this relocation method.
Then you don't get to dismiss claims that you're changing =20
DYNAMIC_MEMSTART alignment requirements by saying that RELOCATABLE is a =20
strict superset. :-) Given the requirement that the kernel be in the =20
first TLB entry, though, using RELOCATABLE rather than DYNAMIC_MEMSTART =20
doesn't fix the alignment problem.
I don't think it makes sense to keep both mechanisms around unless =20
there's some obvious reason to prefer DYNAMIC_MEMSTART.
> > >> 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 =20
> 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.
>=20
> Yes, there may be speculative access in this case.
>=20
> > 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.
>=20
> Fair enough. So it seems error prone if we map this 256M memory region
> blindly. But if we don't do this, it seems that we have to do twice =20
> relocation.
> The first time we just align to a predefined value (64M for example), =20
> and
> then parse the device tree and get the real memstart_addr. After that =20
> we
> should relocate the kernel to the real start address. It seems a =20
> little
> complicated. Do you have any better ideas?
This seems like the proper way to address it, assuming we're unwilling =20
to map the kernel image somewhere other than the normal lowmem mapping =20
(and I think we're unwilling, given how tight the address space is on =20
32-bit, and the intrusiveness of the change). The dynamic =20
determination of 64M versus 256M could be an acceptable alternative =20
though, if we're OK with not supporting arbitrary relocatable =20
scenarios, but just those that are either needed by kdump, or supported =20
by current kernels (with DYNAMIC_MEMSTART, or just starting at zero =20
with less than 256M of RAM). If we go that route, the limitations =20
should be documented.
-Scott=
next prev parent reply other threads:[~2013-07-02 0:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 2:00 [PATCH 0/2] powerpc: enable the relocatable support for fsl booke 32bit kernel Kevin Hao
2013-06-27 2:00 ` [PATCH 1/2] powerpc: enable the relocatable support for the " Kevin Hao
2013-06-27 19:58 ` Scott Wood
2013-06-28 1:36 ` Kevin Hao
2013-06-28 1:47 ` Scott Wood
2013-06-30 7:33 ` Kevin Hao
2013-07-02 0:30 ` Scott Wood [this message]
2013-07-02 3:24 ` Kevin Hao
2013-07-02 22:39 ` Scott Wood
2013-07-03 3:00 ` Kevin Hao
2013-07-03 20:38 ` Scott Wood
2013-07-04 1:08 ` Kevin Hao
2013-07-08 16:48 ` Scott Wood
2013-07-09 1:26 ` Kevin Hao
2013-06-28 1:52 ` Scott Wood
2013-06-30 7:34 ` Kevin Hao
2013-06-27 2:00 ` [PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel Kevin Hao
2013-06-28 2:19 ` Scott Wood
2013-06-30 7:35 ` Kevin Hao
2013-07-02 1:00 ` Scott Wood
2013-07-02 3:45 ` Kevin Hao
2013-07-02 22:41 ` Scott Wood
2013-07-03 3:29 ` Kevin Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1372725045.8183.102@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=haokexin@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox