linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mark Pilon <mpilon@midrivers.com>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Organisation of 4xx initialization code
Date: Fri, 16 Nov 2001 09:07:05 -0700	[thread overview]
Message-ID: <3BF539A9.BA3ED260@midrivers.com> (raw)
In-Reply-To: 20011116045737.A24130@cx258813-a.chnd1.az.home.com


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/

  parent reply	other threads:[~2001-11-16 16:07 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 [this message]
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
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=3BF539A9.BA3ED260@midrivers.com \
    --to=mpilon@midrivers.com \
    --cc=linuxppc-embedded@lists.linuxppc.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).