linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] powerpc: merged asm/cputable.h
Date: Tue, 27 Sep 2005 08:45:54 +1000	[thread overview]
Message-ID: <1127774755.15882.104.camel@gaston> (raw)
In-Reply-To: <200509261157.37514.michael@ellerman.id.au>

On Mon, 2005-09-26 at 11:57 +1000, Michael Ellerman wrote:

> Here's a version of my patch updated to apply on top of the merge tree.
> It'll be a lot cleaner when ppc32 has a single cur_cpu_spec, as we'll
> be able to remove a lot of the #ifdefs.

There is a small issue here: You turn identify_cpu into C code. However,
on ppc32, this is called with the kernel not yet relocated (before
prom_init even !). Same with the feature fixup. On ppc32, in order to
run C code that early, it needs to be in -mrelocatable bits of code
(like prom_init) or use RELOC macros (ugh !).

This puts some light on the fact that we do things quite differently
here between ppc32 and ppc64. On ppc64, the call to identify CPU is done
after kernel is relocated (after prom_init), and before early_setup,
though the call to fixup the feature sections is done later, after the
initial parsing of the flat device-tree, where we can "adjust" some
features based on firmware properties.

We might want to sync a bit what ppc32 and ppc64 do here, however, that
will/would require some changes in the way we manipulate some MMU bits.

On ppc32, we first create a temporary initial mapping, using BATs on
6xx, using other mecanisms on other CPUs, that covers kernel text & data
(not much more). This could be "equivalent" of the ppc64 bit that runs
in real mode. (Though we have to be careful there if we do something
like unpacking the device-tree, that has to be done -after- final
translation is turned on with full access to the linear mapping).

Also, the ppc64 bits calls indentify_cpu from asm on the primary CPU at
least. I don't think that is strictly necessary, at least not any more.
It could be done instead at the beginning of early_setup.

Ben.

  reply	other threads:[~2005-09-26 22:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-23 19:08 [PATCH] powerpc: merged asm/cputable.h Kumar Gala
2005-09-24  0:04 ` Paul Mackerras
2005-09-24  0:48   ` Stephen Rothwell
2005-09-24 15:35     ` Kumar Gala
2005-09-26  1:57       ` Michael Ellerman
2005-09-26 22:45         ` Benjamin Herrenschmidt [this message]
2005-09-26 23:05           ` Michael Ellerman
2005-09-26 23:31             ` Benjamin Herrenschmidt
2005-09-26 23:22           ` Kumar Gala
2005-09-26 23:38             ` Benjamin Herrenschmidt

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=1127774755.15882.104.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=sfr@canb.auug.org.au \
    /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).