Organisation of 4xx initialization code

[Tom Rini]

On Sat, Nov 17, 2001 at 11:43:30AM +1100, David Gibson wrote:
> On Fri, Nov 16, 2001 at 06:24:13PM -0500, Dan Malek wrote:
> > >I think right now, 4xx is done in a different way intentionally.
> >
> > I'm not so sure :-).  I think it started off badly, is getting better,
> > and from these discussions we have clearly learned how to better
> > structure the software.  From the variety of 4xx projects I have worked
> > on, I'm still making the kinds of changes to better utilize and structure
> > existing software.  I feel like I'm doing the same thing I did years ago
> > with the 8xx, only back then no one cared what I was doing (because it
> > was some embedded stuff that didn't seem to interest anyone :-).
> >
> > >..... There's common
> > >ground, with hooks for board-specific stuff.
> >
> > I could argue the 7xx stuff is this way as well.  Every board should
> > probably
> > have a platform_init() that calls the processor architecture unique
> > functions.
> > I am a little confused that there doesn't seem to be as many platform_init()
> > calls as there are boards we support (just 'grep for it' in the kernel
> > directory).  So, there is probably work to do for all boards we support.
>
> That's exactly my point:  platform_init() for *all* 4xx boards is in
> ppc4xx_setup.c, which then calls a board_init() function which comes
> from the particular board.

Right.  And for all of the 7xx boards it's in platforms/board.c.

> > It seems we should call some early architecture generic init functions (if
> > necessary), then platform init, then more general architecture functions
> > if necessary.
>
> No need - the board's platform_init() can call the processor general
> functions if necessary.

But why not do this once instead of many times?  Right now, each of the
405GP 'board' file would look awful similar.  I think what Dan said
before is we need to break things up into logical and somewhat
independant units.  I think we can make ppc4xx_setup.c::platform_init
smart enough so that it works by calling out to the specific parts it
needs to.  The 'correct' order for things, which we're getting closer to
but aren't yet is 4xx-always stuff, which isn't much and could be less.
Then board bits, and then core bits.  But the thing is in general terms
a 405GP 'board' will always have certain things.  A STB03xxx will have
certain things.  So why not have common names for the processor-specific
stuff we want and then call it?  Eg on 405GP we get ppc_405gp.c and
4xx_do_foo is the 405GP version.  Or if we're 403GCX it's that version,
and so on.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/