From: Dan Malek <dan@embeddededge.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-embedded@lists.linuxppc.org, Paul Mackerras <paulus@samba.org>
Subject: Re: Organisation of 4xx initialization code
Date: Fri, 16 Nov 2001 11:46:12 -0500 [thread overview]
Message-ID: <3BF542D4.10706@embeddededge.com> (raw)
In-Reply-To: 20011116164625.K673@zax
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/
next prev parent reply other threads:[~2001-11-16 16:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 5:46 Organisation of 4xx initialization code David Gibson
2001-11-16 11:57 ` Matt Porter
2001-11-16 15:51 ` Tom Rini
2001-11-16 16:42 ` Matt Porter
2001-11-16 17:13 ` Tom Rini
2001-11-16 23:24 ` Dan Malek
2001-11-17 0:43 ` David Gibson
2001-11-17 1:01 ` Dan Malek
2001-11-17 2:18 ` Tom Rini
2001-11-17 11:16 ` Paul Mackerras
2001-11-17 12:43 ` Ralph Blach
2001-11-17 14:46 ` Mark Pilon
2001-11-17 0:50 ` David Gibson
2001-11-17 2:16 ` Tom Rini
2001-11-17 0:35 ` David Gibson
2001-11-17 2:18 ` Tom Rini
2001-11-16 16:07 ` Mark Pilon
2001-11-16 17:29 ` Tom Rini
2001-11-16 14:59 ` Tom Rini
2001-11-17 0:40 ` David Gibson
2001-11-17 2:15 ` Tom Rini
2001-11-16 16:46 ` Dan Malek [this message]
2001-11-17 0:47 ` David Gibson
2001-11-17 1:11 ` Dan Malek
2001-11-16 17:15 ` Armin Kuster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BF542D4.10706@embeddededge.com \
--to=dan@embeddededge.com \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).