public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Jon Loeliger <jdl@freescale•com>
Cc: linuxppc64-dev@ozlabs•org,
	"linuxppc-embedded@ozlabs•org" <linuxppc-embedded@ozlabs•org>
Subject: Re: Discuss: Adding OF Flat Dev Tree to ppc32
Date: Thu, 16 Jun 2005 07:52:53 +1000	[thread overview]
Message-ID: <1118872373.5986.242.camel@gaston> (raw)
In-Reply-To: <1118862046.25372.49.camel@cashmere.sps.mot.com>

On Wed, 2005-06-15 at 14:00 -0500, Jon Loeliger wrote:
> On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:
> 
> > It's basically used to extract some infos directly from the flattened
> > tree in order to construct the LMB list (list of memory blocks,
> > equivalent of ppc32's mem_pieces), 
> 
> 
> OK.  So the unflattenting process requires a small amount
> of memory allocation which is currently implemented using
> the lmb mechanism in PPC64 land.

Not only the unflattening process. The full MMU initialisation (ability
to map things etc...) needs mem_pieces too. The ppc32 kernel runs with a
very limited memory setup until that happens.

> As you indicate, there is also the mem_pieces implementation
> over in ppc32 land.  I think it is currently only used by
> arch/ppc/platforms/pmac_setup.c.

mem_pieces is used in several places in the early mmu setup too
in arch/ppc/mm/*

> In porting this code over to PPC32 land, there are roughly
> three choices:
> 
>    1) Copy the LMB implementation from ppc64 over to PPC32 land,

No, we can stick to mem_pieces

>    2) Change the unflattening code in PPC32 to use mem_pieces,
>       or rewrite it to allow a configurable choice between
>       LMB and mem_pieces,

mem_pieces is fine

>    3) Make up something new, yet very similar to LMB and
>       mem_pieces.
> 
> Does anyone have suggestions or advice on route 1) or 2)?
> Anyone?  Kumar?  Ben?  Bueller?

The main issues is not really there. The problem is that we will have to
scan the flattened tree at boot in order to setup the MMU and that will
have to be done with a very limited access to memory, possibly only the
low 32Mb of RAM for example (though we may manage something better
running in real mode with some CPUs).

That means maybe imposing some restrictions on where the flattened
device-tree block can be when passed to the kernel (unless we can run
that C code in real mode) and other niceties that will have to be dealt
per CPU family.

Ben.

  reply	other threads:[~2005-06-15 21:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-01  8:26 Booting the linux-ppc64 kernel & flattened device tree v0.4 Benjamin Herrenschmidt
2005-06-01  8:28 ` Benjamin Herrenschmidt
2005-06-03  7:18   ` Benjamin Herrenschmidt
2005-06-03 17:19     ` Discuss: Adding OF Flat Dev Tree to ppc32 Jon Loeliger
2005-06-08  3:06       ` Benjamin Herrenschmidt
2005-06-15 19:00         ` Jon Loeliger
2005-06-15 21:52           ` Benjamin Herrenschmidt [this message]
2005-06-21 23:41         ` Tom Rini
2005-06-01 16:58 ` Booting the linux-ppc64 kernel & flattened device tree v0.4 Jon Loeliger
2005-06-01 21:56   ` Benjamin Herrenschmidt
2005-06-01 19:54 ` Jon Loeliger
2005-06-01 21:58   ` Benjamin Herrenschmidt
2005-06-02  7:09 ` David Gibson
2005-06-03  8:19   ` David Gibson

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=1118872373.5986.242.camel@gaston \
    --to=benh@kernel$(echo .)crashing.org \
    --cc=jdl@freescale$(echo .)com \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    --cc=linuxppc64-dev@ozlabs$(echo .)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