Discuss: Adding OF Flat Dev Tree to ppc32
Benjamin Herrenschmidt
benh at kernel.crashing.org
Thu Jun 16 07:52:53 EST 2005
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.
More information about the Linuxppc64-dev
mailing list