Organisation of 4xx initialization code

[David Gibson]

On Fri, Nov 16, 2001 at 08:51:21AM -0700, Tom Rini wrote:
>
> On Fri, Nov 16, 2001 at 04:57:38AM -0700, Matt Porter wrote:
> >
> > On Fri, Nov 16, 2001 at 04:46:26PM +1100, David Gibson wrote:
> > >
> > > At the moment the initialization for each of the 4xx boards goes
> > > through the platform_init() in arch/ppc/kernel/ppc4xx_setup.c, which
> > > in turns calls a board_init() function for the specific board.
> > >
> > > It seems to me that it would make more sense to put platform_init() in
> > > the board specific files, and these functions could then call back,
> > > where appropriate, to generic 4xx setup functions.  This would mean:
> > > 	- It would be easier to support wierd and wacky boards which
> > > have non-standard address setups.
> > > 	- Some ugly #ifdefs in ppc4xx_setup.c could be done away with.
> > > 	- We should be able to remove some inconvenient header
> > > dependencies - at present lots of things are recompiled when board
> > > local defines are changed because walnut.h/ep405.h/etc are included
> > > indirectly in serial.h and some other unexpected places.
> > >
> > > Thoughts?
> >
> > I've been wondering why it's architected that way as well.  It
> > seems you are looking for it to follow the model of the well
> > abstracted 7xx/74xx ports.  Examples are the ones that rely on
> > mpc10x_common and pplus_common as libraries of common initialization
> > code (MEN F1, PCore, MCPN765, MVME5100, etc.).
>
> But that's just it.  Someone else should probably speak up on this, but
> in the 403/405/stb0{3,4}xxx, and possibly 440 when it exists there are
> some things which always exist, depending on processor.  Each 750 board
> for example can really have almost anything attached to it.  But for a
> 405GP, there are known things and some variable things.  I _think_ 4xx
> boards vary more like the 8xx ones do, than 750 does.

Yes, but how the current code tends to make assumptions about how the
onboard devices have been configured by the firmware, and that does
vary from board to board.

Furthermore, it's quite likely IBM will re-use some of the 4xx onboard
peripherals on new 4xx (or even non-4xx) chips, where they could well
be differently organised.  If the board specific code handles the
top-level initialization it will be easier to reuse the code for these
devices.

--
David Gibson			| For every complex problem there is a
david at gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

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