From: David Gibson <hidden> Date: 2001-11-16 05:46:26
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/
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/
From: Dan Malek <hidden> Date: 2001-11-16 16:46:12
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/
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/
From: David Gibson <hidden> Date: 2001-11-17 00:40:52
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:
quoted
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.
quoted
- 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/
From: David Gibson <hidden> Date: 2001-11-17 00:47:24
On Fri, Nov 16, 2001 at 11:46:12AM -0500, Dan Malek wrote:
David Gibson wrote:
quoted
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/
From: Dan Malek <hidden> Date: 2001-11-17 01:11:40
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/
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:
quoted
On Fri, Nov 16, 2001 at 04:46:26PM +1100, David Gibson wrote:
quoted
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.
quoted
quoted
- 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/