From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: michael@ellerman.id.au, linuxppc-dev@ozlabs.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
linuxppc64-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: merged asm/cputable.h
Date: Tue, 27 Sep 2005 09:38:43 +1000 [thread overview]
Message-ID: <1127777923.15882.114.camel@gaston> (raw)
In-Reply-To: <65BBD07F-B465-45E0-9422-9015D1FBF93A@freescale.com>
> At the end of the day we should have the same init path for
> everything. We have to deal with the fact that some processors are
> not going to have "real mode" to run in. Anything Book-E 32 or 64-
> bit is going to fall into this case.
I know, and real mode isn't necessarily useable on others, my point was,
there is this "pre-mmu-init" phase when we run into a kind of reduced
mmu environment but no need to use RELOC's or -mrelocatable. That is:
- on ppc64, real mode
- on CONFIG_6xx, memory mapped by BATs over first 16M or so
- on others, typically, bolted TLB entries during early asm
This "pre-init" phase has common characteristics, that is
- we can run code without reloc's as explained above
- we can't access much memory above kernel text/data. on ppc64, it
ranges from all memory (lucky) to the limit of the RMO on lpar which
tend to get smaller. In fact, pSeries might even lose real mode sooner
or later and get into a similar "bolted initial mapping" case.
This is when early_setup() is run on ppc64. This is when machine_init()
and MMU_init() are called on ppc32. Those do fundamentally the same
thing. Some pre-init, typically based on device-tree bits & pieces, and
choosing the "right" ppc_md. They could be merged to look like the ppc64
version. The main issue is that ppc32 does a bit too much there (like
finish_device_tree which should be done later like ppc64). There is bits
& pieces there that should be moved around a bit, including in platform
code (ppc_md.probe() should replace {pmac,chrp,...}_init() for example).
Ben.
prev parent reply other threads:[~2005-09-26 23:38 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
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 [this message]
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=1127777923.15882.114.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=kumar.gala@freescale.com \
--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).