linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Kevin Hao <haokexin@gmail.com>
Cc: linuxppc <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2 3/8] powerpc: enable the relocatable support for the fsl booke 32bit kernel
Date: Fri, 26 Jul 2013 18:28:46 -0500	[thread overview]
Message-ID: <1374881326.30721.37@snotra> (raw)
In-Reply-To: <1372942454-25191-4-git-send-email-haokexin@gmail.com> (from haokexin@gmail.com on Thu Jul  4 07:54:09 2013)

On 07/04/2013 07:54:09 AM, 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.
>=20
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> v2: Move the code to set kernstart_addr and virt_phys_offset to a c =20
> function.
>     So we can expand it easily later.
>=20
> Hi Scott,
>=20
> I still use the 256M align for the init tlb as in v1 for the =20
> following reasons:
>   * This should be the most possible case in reality.

There is no "most possible case".  It's either possible (and supported) =20
or not.  And having less than 256M is definitely possible.  The 8540 =20
reference board has 64M.

AMP scenarios that start on a 64M-aligned but not 256M-aligned address =20
are also something I've done.

>   * This is just for very early booting code and should not be a big =20
> issue
>     if the first tlb entry shrink to a less size later.

"We can probably get away with it most of the time" is not a very good =20
justification.  What's wrong with the suggestion I made last time, of =20
basing the size on the alignment of the address?

> +	/*
> +	 * We have the runtime (virutal) address of our base.
> +	 * We calculate our shift of offset from a 256M page.
> +	 * We could map the 256M page we belong to at PAGE_OFFSET and
> +	 * get going from there.
> +	 */
> +	lis	r4,KERNELBASE@h
> +	ori	r4,r4,KERNELBASE@l
> +	rlwinm	r6,r25,0,0xfffffff		/* r6 =3D PHYS_START % =20
> 256M */
> +	rlwinm	r5,r4,0,0xfffffff		/* r5 =3D KERNELBASE % =20
> 256M */
> +	subf	r3,r5,r6			/* r3 =3D r6 - r5 */
> +	add	r3,r4,r3			/* Required Virutal =20
> Address */

s/Virutal/Virtual/

-Scott=

  reply	other threads:[~2013-07-26 23:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 12:54 [PATCH v2 0/8] powerpc: enable the relocatable support for fsl booke 32bit kernel Kevin Hao
2013-07-04 12:54 ` [PATCH v2 1/8] powerpc/fsl_booke: protect the access to MAS7 with MMU_FTR_BIG_PHYS Kevin Hao
2013-07-26 23:14   ` Scott Wood
2013-08-04  0:30     ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 2/8] powerpc/fsl_booke: introduce get_phys_addr function Kevin Hao
2013-07-04 12:54 ` [PATCH v2 3/8] powerpc: enable the relocatable support for the fsl booke 32bit kernel Kevin Hao
2013-07-26 23:28   ` Scott Wood [this message]
2013-08-04  0:38     ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 4/8] powerpc/fsl_booke: set the tlb entry for the kernel address in AS1 Kevin Hao
2013-07-26 23:37   ` Scott Wood
2013-08-04  0:42     ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 5/8] memblock: introduce the memblock_reinit function Kevin Hao
2013-07-04 12:54 ` [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info Kevin Hao
2013-07-27  0:18   ` Scott Wood
2013-08-04  0:45     ` Kevin Hao
2013-08-05 23:59       ` Scott Wood
2013-08-06  1:21         ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel Kevin Hao
2013-07-27  0:17   ` Scott Wood
2013-08-04  0:50     ` Kevin Hao
2013-08-06  0:10       ` Scott Wood
2013-08-06  1:23         ` Kevin Hao
2013-08-06  0:14   ` Scott Wood
2013-08-06  1:45     ` Kevin Hao
2013-07-04 12:54 ` [PATCH v2 8/8] powerpc/fsl_booke: enable the relocatable for the kdump kernel 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=1374881326.30721.37@snotra \
    --to=scottwood@freescale.com \
    --cc=haokexin@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).