All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Cordahi <christopher.cordahi@gmail.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Kumar Gala <galak@freescale.com>,
	linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
Date: Wed, 19 Oct 2005 20:29:45 -0400	[thread overview]
Message-ID: <a1a7967e0510191729x520b2aeak@mail.gmail.com> (raw)
In-Reply-To: <4c41159c3c06e288e5d69469f1e3ce7b@embeddededge.com>

On 18/10/05, Dan Malek <dan@embeddededge.com> wrote:
>
> On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:
>
> > For 8xx, I was wondering if the PARTNUM field of the IMMR
> > (section 10.4.1 of MPC860UM.pdf) does have meaningful
> > information which could be used to identify the CPU.
>
> It has meaningful information, but not the way you want
> to use it :-)  The PARTNUM/MASKNUM is only useful
> once you know the type of processor (like 823, 850, 885, etc)
> The PARTNUM is only useful within the "family."  For
> example, the 860 and 880 are two different families, and
> will contain the similar PARTNUM values through their life.
> I believe it's tied to the fabrication process.

I don't understand in what way Marcelo wants to use it, but
from my understanding and a quick look of the Freescale product
summary pages it's the opposite of what you're indicating.
I believe the PARTNUM identifies the family not the part.
You can't tell an 885 from an 870 (IMMR contains 0x09xx).
Similarly you can't tell an 860EN from an 860T (IMMR
contains 0x00xx or 0x05xx).
But you can tell an 860 from an 880 which are in different
families.  Note that it's not always obvious which parts
are in the same family.

> You may as well stop looking for an easy (or possibly
> any) way to differentiate these parts in software, but
> due to they way they are fabricated, I don't think that's
> ever going to happen. :-)
Also just because a feature isn't supposed to be present
doesn't mean it's not.
We bought 860EN (4 SCCs) parts but Motorola accidentily
shipped us 860DE (2 SCCs) parts.  We installed, tested and
shipped a few of these parts using all 4 SCCs without
problem.  It wasn't until another unrelated problem occurred
that we noticed that we had used a tray of the wrong part.

Chris

  reply	other threads:[~2005-10-20  0:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11 13:54 [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx Vitaly Bordug
2005-10-18 14:24 ` Marcelo Tosatti
2005-10-18 19:46   ` Dan Malek
2005-10-20  0:29     ` Christopher Cordahi [this message]
2005-10-20  4:15       ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2005-10-19 17:03 Vitaly Bordug
2005-10-19 17:20 ` Jiri Slaby
2005-10-19 17:58   ` Vitaly Bordug

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=a1a7967e0510191729x520b2aeak@mail.gmail.com \
    --to=christopher.cordahi@gmail.com \
    --cc=dan@embeddededge.com \
    --cc=galak@freescale.com \
    --cc=linuxppc-embedded@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.