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: Sat, 17 Nov 2001 07:46:44 -0700	[thread overview]
Message-ID: <3BF67854.C4D8EA7D@midrivers.com> (raw)
In-Reply-To: 3BF65B8B.EB015B30@intrex.net


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/

  reply	other threads:[~2001-11-17 14: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 [this message]
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
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=3BF67854.C4D8EA7D@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).