Organisation of 4xx initialization code

Organisation of 4xx initialization code

[David Gibson]

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?

--
David Gibson			| For every complex problem there is a
david@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/

Re: Organisation of 4xx initialization code

[Matt Porter]

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.).

Seems like that would be an improvement for people doing custom
405 ports and ease maintenance of existing ports (especially
the #ifdef creep).

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: Organisation of 4xx initialization code

[Tom Rini]

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:

But 95% of the current 4xx platform_init is generic.  With the exception
of the redwood kbd init stuff, which right now we could probably move
into the redwood board_init (providing redwood_irkb_init sets things to
NULL which the previous bits set).

> 	- It would be easier to support wierd and wacky boards which
> have non-standard address setups.

Can you be more specific?

> 	- Some ugly #ifdefs in ppc4xx_setup.c could be done away with.

All of the ones around externs can go regardless.

> 	- 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.

Keep in mind <asm/ibm4xx.h> has the same exact thing.  As does
<asm/mpc8xx.h>.  There's lots of wierd header dependancies, and it's not
fixable in 2.4 anyhow.  kbuild-2.5 doesn't have this issue, and this
isn't even much of a problem anyhow.

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

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

Re: Organisation of 4xx initialization code

[Tom Rini]

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.

Having said that, there is room for imporvement, but I think it's more
along the lines of moving more things into board_init which can override
the default structs if needed.

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

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

Re: Organisation of 4xx initialization code

[Mark Pilon]

I've had to face this, taking the existing walnut/405GP work and migrating
it to a custom controller + 405PM.

some issues:
- mem mapped and DCRs have moved around, been added or taken away when
  going from the 405gp to pm.

- functional differneces exist between the parts as well: one example
  being the GP has 5 ethernet interrupts mapped into the UIC, while
  the PM they're all rolled into 1 int.

- there may be silicon errata which affect one processor which have
  been worked out of another.

- and the cards are different as well ...

for ease of replicating this port when the next kernel comes along,
I came down on the side of really isolating everything I'm adding:
1bm405pm.h instead of ibm405gp.h,
my own board and architecture setup funcs in their own module ...
my own head_ppc405pm.S ....

I've also taken a copy of ppc405_enet.c and modified it for the
new interrupt structure.

this may not be a wise approach, but it saves me ifdeffing many
files to smithereens.  Most of the ifdefs are to makefiles so
that different objects for my card and the 405pm are called for,
rather than walnut and 405GP.  Ay any rate, it'll make my port
easier and I can rethink this when I've got a more stable O/S
release to work on.

my 0.0002: an approach which isolates chip-specific funcs in a
chip-specific module, same for board-specific.  this adds maintenance
as the flavors for a given processor grow.  maybe there's a more clever
way to do this w/o globbing up a few files w/ many ifdefs.

Mark


> 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.).
>
> Seems like that would be an improvement for people doing custom
> 405 ports and ease maintenance of existing ports (especially
> the #ifdef creep).

--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

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

Re: Organisation of 4xx initialization code

[Matt Porter]

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

Leave the 440 out of this, it should never pollute the classic PPC
tree if it's done correctly.

> 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.

405GP specifically is similar to an 8240 in that the "system
controller" is fixed.  That is, there is a known PPC core,
memory controller, PCI bridge, and a set of peripherals.
8240 ports are using the "7xx/74xx" approach because it fits
well.  You could make the same argument that all gt64260+7xxx
ports belong in one file rather than a board specific file
that calls to a common set of library initialization routines.

> Having said that, there is room for imporvement, but I think it's more
> along the lines of moving more things into board_init which can override
> the default structs if needed.

Because it has a PCI bridge on it (which can be very flexibly
mapped, like it's CPC700 cousin) there is going to be a wide
variation in the systems it's placed in.  I can already see
that from the custom designs known internally as well as the
COTs boards that include cPCI and ATX systems.  Interestingly,
this is the same wide variation of system designs that 8240's
find themselves in.

If it was an 8xx-style SoC that didn't have a built-in standard
bus (meaning PCI(X), RapidIO, etc) I'd be thinking differently.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: Organisation of 4xx initialization code

[Dan Malek]

David Gibson wrote:


> Thoughts?

For some reason, the 4xx "structure" wasn't started correctly and
has taken a weird path.  I've discussed this with a few folks that
have asked about it.  Unfortunately, I've been working on a variety
of 4xx boards just to get them to work and haven't been able to
spend time sorting this out.

I don't have a response to your specific question, but in general
we have messed up the 4xx processor/board configuration.  This starts
all of the way from the include files and I'm sure exists in other
source files.  The problem I have with 4xx is we conceptually start with a
processor type, and then try to determine what board we have.  If you
use the 8xx as a model, it is done the other way around.  You first
start with some architecture common things, then do the board, then
let the board determine further unique processor or I/O configuration
details.  Other platforms seem to do something similar.

We need to start right at the top.  The ibm4xx.h file should include
the properly configured board description file, then that file should
include the proper processor type.  The kernel initialization should
do the same.

Specific to your question, I guess you are proposing to have a bunch
of platform_init functions, one for each board, then have them call generic
4xx functions if necessary.  Makes sense.

Who is going to restructure this and when is it going to be done :-)?
I have a big mess of STB and other 4xx stuff to check in, and it
doesn't fit anywhere right now (but is closer to the current model).

Thanks.


	-- Dan


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

Re: Organisation of 4xx initialization code

[Tom Rini]

On Fri, Nov 16, 2001 at 09:42:10AM -0700, Matt Porter wrote:
> 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:
> > >
> > > 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
>
> Leave the 440 out of this, it should never pollute the classic PPC
> tree if it's done correctly.
>
> > 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.
>
> 405GP specifically is similar to an 8240 in that the "system
> controller" is fixed.  That is, there is a known PPC core,
> memory controller, PCI bridge, and a set of peripherals.
> 8240 ports are using the "7xx/74xx" approach because it fits
> well.

That and all of the 8240 'boards' are 7xx/74xx boards which can take a
processor 'card' of some sort, yes?

Not getting too off course, but what's the difference in 8240 vs 8245
(not much, yes?) vs 8260 (different I/O, yes?).

> You could make the same argument that all gt64260+7xxx
> ports belong in one file rather than a board specific file
> that calls to a common set of library initialization routines.

Well depending on how different the boards are, perhaps.

I think right now, 4xx is done in a different way intentionally.  The
7xx/74xx design does indeed work, but for every off-by-one board you end
up either doing an #ifdef or a new set of files, for small changes.  The
current 4xx design seems to be the other way around.  There's common
ground, with hooks for board-specific stuff.  This could probably use
more cleanup & slight changes, but I don't think it's time to scrap the
idea.

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

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

Re: Organisation of 4xx initialization code

[Armin Kuster]

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?
>
> --
> David Gibson                    | For every complex problem there is a
> david@gibson.dropbear.id.au     | solution which is simple, neat and
>                                 | wrong.  -- H.L. Mencken
> http://www.ozlabs.org/people/dgibson
>

David,

I actual did the work a week ago and it became quite evident it was
pointless to restructure to that extent at this time (Dan & Tom both
laughed at me as well).  We should address this when those weird & wacky
boards come along IMHO.

-- armin

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

Re: Organisation of 4xx initialization code

[Tom Rini]

On Fri, Nov 16, 2001 at 09:07:05AM -0700, Mark Pilon wrote:
>

> some issues:
> - mem mapped and DCRs have moved around, been added or taken away when
>   going from the 405gp to pm.
>
> - functional differneces exist between the parts as well: one example
>   being the GP has 5 ethernet interrupts mapped into the UIC, while
>   the PM they're all rolled into 1 int.
>
> - there may be silicon errata which affect one processor which have
>   been worked out of another.
>
> - and the cards are different as well ...
>
> for ease of replicating this port when the next kernel comes along,
> I came down on the side of really isolating everything I'm adding:
> 1bm405pm.h instead of ibm405gp.h,

That's exactly how it should go too.  And did you add in a CONFIG_405PM?
405GP things _should_ be CONFIG_405GP'ed.  If not please post a patch
for them.

> my own board and architecture setup funcs in their own module ...
> my own head_ppc405pm.S ....

Were these actually needed?

> my 0.0002: an approach which isolates chip-specific funcs in a
> chip-specific module, same for board-specific.  this adds maintenance
> as the flavors for a given processor grow.  maybe there's a more clever
> way to do this w/o globbing up a few files w/ many ifdefs.

Which is sort-of where things are going, but haven't yet.  The sooner
you post your port the sooner I can think about things too and see what
needs to be seperated out more.

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

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

Re: Organisation of 4xx initialization code

[Dan Malek]

I'm not arguing for/against anything here, just providing some information.

Tom Rini wrote:


> That and all of the 8240 'boards' are 7xx/74xx boards which can take a
> processor 'card' of some sort, yes?


The 8240/45 60x/7xx/74xx are basically similar, as they are standard
PowerPC processor cores with standard PCI bridges.  The 7540 and later
could throw a big curve if someone decided to use the 36-bit addressing
and we wanted to implement a software TLB manager instead of HPTE.

> Not getting too off course, but what's the difference in 8240 vs 8245
> (not much, yes?) vs 8260 (different I/O, yes?).

The 8260/55 and 8xx are very different because they can be very functional
without a PCI bridge or standard peripherals.  Adding a standard PCI
bridge signficantly confuses and complicates the software configuration.
Their flexibility is very challenging to support and configure in the
software.  In some cases, the Linux software has driven hardware designs
so people can utilize existing software, but for maximum performance and
special applications you can get quite creative with the hardware design
and have to nearly write the kernel support for these processors from
scratch.  The 8xx and 8260/55 are the true embedded processors with a
powerful (in the case of 8260 :-) core and lots of highly optimized
peripherals surrounding them in a single package.  You aren't ever going
to guess right at what may be useful to someone tomorrow :-).

> 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.

It seems we should call some early architecture generic init functions (if
necessary), then platform init, then more general architecture functions
if necessary.

> ....  This could probably use
> more cleanup & slight changes, but I don't think it's time to scrap the
> idea.

We don't have any cohesive idea.  The 8xx and 8260 are clearly different
because a "board" is really a collection of their embedded peripherals.
The 6xx/7xx/74xx is at the other end with very dynamic configurations
based upon PCI peripherals.  The 4xx is unfortunately stuck in the middle
and each side wants it their way :-).

I guess when the dust settles I'll just merge changes again :-).

Thanks.


	-- Dan


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

Re: 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@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/

Re: Organisation of 4xx initialization code

[David Gibson]

On Fri, Nov 16, 2001 at 07:59:17AM -0700, Tom Rini 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:
>
> But 95% of the current 4xx platform_init is generic.  With the exception
> of the redwood kbd init stuff, which right now we could probably move
> into the redwood board_init (providing redwood_irkb_init sets things to
> NULL which the previous bits set).

And the common stuff can still be shared - it's just that the board
code, which clearly knows more about the configuration than the 4xx
generic stuff, chooses what order to do things in.

> > 	- 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.
>
> Keep in mind <asm/ibm4xx.h> has the same exact thing.  As does
> <asm/mpc8xx.h>.  There's lots of wierd header dependancies, and it's not
> fixable in 2.4 anyhow.  kbuild-2.5 doesn't have this issue, and this
> isn't even much of a problem anyhow.

Um, no, this has nothing to do with the build system.  Board specific
header files, which contain largely information which is irrelevant to
everything except the board and 4xx setup code is being indirectly
included in parts of the generic kernel.  That creates a dependency
regardless of the build system.

--
David Gibson			| For every complex problem there is a
david@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/

Re: Organisation of 4xx initialization code

[David Gibson]

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.

> 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.

--
David Gibson			| For every complex problem there is a
david@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/

Re: Organisation of 4xx initialization code

[David Gibson]

On Fri, Nov 16, 2001 at 11:46:12AM -0500, Dan Malek wrote:
> David Gibson wrote:
>
>
> >Thoughts?
>
> For some reason, the 4xx "structure" wasn't started correctly and
> has taken a weird path.  I've discussed this with a few folks that
> have asked about it.  Unfortunately, I've been working on a variety
> of 4xx boards just to get them to work and haven't been able to
> spend time sorting this out.
>
> I don't have a response to your specific question, but in general
> we have messed up the 4xx processor/board configuration.  This starts
> all of the way from the include files and I'm sure exists in other
> source files.  The problem I have with 4xx is we conceptually start with a
> processor type, and then try to determine what board we have.  If you
> use the 8xx as a model, it is done the other way around.  You first
> start with some architecture common things, then do the board, then
> let the board determine further unique processor or I/O configuration
> details.  Other platforms seem to do something similar.
>
> We need to start right at the top.  The ibm4xx.h file should include
> the properly configured board description file, then that file should
> include the proper processor type.  The kernel initialization should
> do the same.
>
> Specific to your question, I guess you are proposing to have a bunch
> of platform_init functions, one for each board, then have them call generic
> 4xx functions if necessary.  Makes sense.
>
> Who is going to restructure this and when is it going to be done :-)?
> I have a big mess of STB and other 4xx stuff to check in, and it
> doesn't fit anywhere right now (but is closer to the current model).

I'm offering...  As far as I can see the sanest (i.e. least gratuitous
breakage) way to do it is as follows:  create a new ppc4xx.c which
will probably have a lot of code copied out of ppc4xx_setup.c, migrate
one or two boards (probably ep405 and walnut, because I have access)
over to have their own platform_init() calling code in ppc4xx.c.
Gradually move each of the other 4xx machines over to the new scheme
and finally remove ppc4xx_setup.c

--
David Gibson			| For every complex problem there is a
david@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/

Re: Organisation of 4xx initialization code

[David Gibson]

On Fri, Nov 16, 2001 at 09:42:10AM -0700, Matt Porter wrote:
>
> 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
>
> Leave the 440 out of this, it should never pollute the classic PPC
> tree if it's done correctly.

Yes and no.  That's probably true for the processor core, but it's
likely to have onboard peripherals which are the same as or very
similar to older 4xx designs.  It would be nice if we could share the
code for handling these devices.

--
David Gibson			| For every complex problem there is a
david@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/

Re: Organisation of 4xx initialization code

[Dan Malek]

David Gibson wrote:


> 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.

But, you missed my point.  I was implicating all PowerPC boards, not
just 4xx.  Before we jump off and proclaim it is _the_ way to handle
porting of the different boards, we better understand why it isn't
widely done today.  It seems only Matt does it for some of the boards
he has ported.  The platform_init() for _all_ 8xx boards is done
generically in m8xx_setup.c, which works fine for all of them we support
and it wouldn't make sense to have individual files for the dozens of
those that are supported.


	-- Dan

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

Re: Organisation of 4xx initialization code

[Dan Malek]

David Gibson wrote:



> ..........  create a new ppc4xx.c which
> will probably have a lot of code copied out of ppc4xx_setup.c,

Oh great, even more new files names......

> Gradually move each of the other 4xx machines over to the new scheme
> and finally remove ppc4xx_setup.c

How about you just do them all at once so we don't have a mess with
some old and some new methods?  Even if you can't test the changes,
contact someone that can and offer to do the best at changes.  Nothing
is worse than making major changes to only some of the files, leaving
someone else to do the remainder when they are busy trying to accomplish
something else.

Thanks.


	-- Dan


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

Re: Organisation of 4xx initialization code

[Tom Rini]

On Sat, Nov 17, 2001 at 11:40:52AM +1100, David Gibson wrote:
> On Fri, Nov 16, 2001 at 07:59:17AM -0700, Tom Rini 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:
> >
> > But 95% of the current 4xx platform_init is generic.  With the exception
> > of the redwood kbd init stuff, which right now we could probably move
> > into the redwood board_init (providing redwood_irkb_init sets things to
> > NULL which the previous bits set).
>
> And the common stuff can still be shared - it's just that the board
> code, which clearly knows more about the configuration than the 4xx
> generic stuff, chooses what order to do things in.

And provided things are done in the 'right' order to start with, it
should just work.  We deal with having a rather useless firmware on 7xx
by doing things under ppc_md I believe.  So why not here?  Keep in mind
that 'board_init' is calling in platform_setup and can override ppc_md
stuff set in platform_setup.

> > > 	- 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.
> >
> > Keep in mind <asm/ibm4xx.h> has the same exact thing.  As does
> > <asm/mpc8xx.h>.  There's lots of wierd header dependancies, and it's not
> > fixable in 2.4 anyhow.  kbuild-2.5 doesn't have this issue, and this
> > isn't even much of a problem anyhow.
>
> Um, no, this has nothing to do with the build system.  Board specific
> header files, which contain largely information which is irrelevant to
> everything except the board and 4xx setup code is being indirectly
> included in parts of the generic kernel.  That creates a dependency
> regardless of the build system.

So what were you complainging about <asm/serial.h> deps for?  It isn't
excactly nice, but it's not exactly related to this.  And supposedly
kbuild-2.5 is smarter about how it does deps, so unless you're say
CONFIG_SPRUCE, changing <asm/spruce_serial.h> won't effect
<asm/serial.h> on !CONFIG_SPRUCE.  If I understand things right.

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

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

Re: Organisation of 4xx initialization code

[Tom Rini]

On Sat, Nov 17, 2001 at 11:50:44AM +1100, David Gibson wrote:
> On Fri, Nov 16, 2001 at 09:42:10AM -0700, Matt Porter wrote:
> > Leave the 440 out of this, it should never pollute the classic PPC
> > tree if it's done correctly.
>
> Yes and no.  That's probably true for the processor core, but it's
> likely to have onboard peripherals which are the same as or very
> similar to older 4xx designs.  It would be nice if we could share the
> code for handling these devices.

Right.  Which is why we need to seperate out peripherals from core so
that it will just work on any new 4xx processor, provided things didn't
get dramatically changed around.

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

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

Re: Organisation of 4xx initialization code

[Tom Rini]

On Sat, Nov 17, 2001 at 11:35:41AM +1100, David Gibson wrote:
> On Fri, Nov 16, 2001 at 08:51:21AM -0700, Tom Rini wrote:
> > 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.

Yes, and these assumptions are bugs which need fixing.

'Common' stuff needs to be seperated out more from 'core' stuff.  Feel
free to post patches for this stuff.

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

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

Re: 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/

Re: Organisation of 4xx initialization code

[Paul Mackerras]

Tom Rini writes:

> > 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

As a philosophical thing, I think it is better to give control to the
platform-specific code early and let it call back to generic stuff.
This is very much the Linux philosophy - it's basically what Linus did
with the USB code for instance (the old code worked its way down
through several layers to the HCI driver, Linus' new code called
straight into the HCI driver which then called a library of support
routines).

I think that each platform (ep405, walnut, etc.) should have its own
platform_init(), and if all that does is ppc405_init(), that's fine.
The fact that we have board_init() at present suggests that some
platforms will do more than just ppc405_init.  And having a
platform_init() for each platform is consistent with our approach on
other platforms as well.  Then ppc4xx_setup.c becomes a library of
pieces of code that can be called or not as appropriate.

Paul.

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

Re: Organisation of 4xx initialization code

[Ralph Blach]

Just a note that might influence you.  The sprs of each 405 will be the same,
but there is NO gurantee that the DCR, any of them look anything like any
other DCR in any other DCR.

I suggest core, chip, and then platform specfic.

Chip

Paul Mackerras wrote:

> Tom Rini writes:
>
> > > 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
>
> As a philosophical thing, I think it is better to give control to the
> platform-specific code early and let it call back to generic stuff.
> This is very much the Linux philosophy - it's basically what Linus did
> with the USB code for instance (the old code worked its way down
> through several layers to the HCI driver, Linus' new code called
> straight into the HCI driver which then called a library of support
> routines).
>
> I think that each platform (ep405, walnut, etc.) should have its own
> platform_init(), and if all that does is ppc405_init(), that's fine.
> The fact that we have board_init() at present suggests that some
> platforms will do more than just ppc405_init.  And having a
> platform_init() for each platform is consistent with our approach on
> other platforms as well.  Then ppc4xx_setup.c becomes a library of
> pieces of code that can be called or not as appropriate.
>
> Paul.
>

--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


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

Re: Organisation of 4xx initialization code

[Mark Pilon]

Ralph Blach wrote:
>
> Just a note that might influence you.  The sprs of each 405 will be the same,
> but there is NO gurantee that the DCR, any of them look anything like any
> other DCR in any other DCR.
>
> I suggest core, chip, and then platform specfic.
>
> Chip
>

some differences between 405gp and 405pm:
- DCRs and memory mapped peripherals have moved, (m4xx_map_io(): makes
  more sense to map small blocks for each peripheral than one large
  map for 0x80000000 on up),

- the -PM supports floating point (yet more ifdefs for head_4xx.S)
- the ethernet MAL interrupts have been mux'd from 5 to 1 in the UIC
  (and moved too in the UIC -- more ifdefs for drivers/net/ppc4xx_enet.c)

IBM appears to create their processors by combining asic cores, i.e.
one core for the basic 405, one for ethernet, FPU, ... in doing so
they can move things around.  depending upon how many 4xx processors
they create, that's going to make for a lot of ifdefs if we stick to
one set of files.

is there a 'ppc-generic' set of interfaces that all code must conform
to in the kernel? too many layers?

an alternative might be (e.g.) all the ppc4xx ethernet stuff in
one file, but ifdef'd in (large separate) sections w/ common code
calling that which is processor specific.  (as opposed to ifdeffing
each individual func for each case.)

yow.

Mark
--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

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