On Wed, 15 Dec 1999, Richard Hendricks wrote:

Dan Malek wrote:

quoted

Alan Mimms wrote:

quoted

Can you elaborate on the CPU flavors that do and don't work?  I just bought a
pair of RPXCLLF boards from Embedded Planet which have XPC860TZP50B3 on them.

Those are fine, except I am going to add the Rev. B.3 silicon
errata patches into the kernel (again).  I discovered the EP
design has finally encroached upon some of the errata due to
voltage/timing specs.

If they boot Linux/PPC, they will run fine.  If they don't, it
is likely this software workaround.

Just use them.  If you have trouble, let me know.

Alan,
  The B3 revision of the 860/821 had/has some problems related to 
the data caches getting corrupted when certain registers were accessed.
It's discussed in our errata document on our (MPC821) webpage.

The MPC860 was rev'd to C to fix this, the MPC821 wasn't.  There's
a long and sordid story about it I won't bore anyone here with.

quoted

quoted

What is the issue with the "optimized" cache hardware?

Nothing for Linux.

quoted

.....  Is it possible that they have gone to a newer more superscalar
implementation of the 8xx core with the 8xxP parts that does more out of order
operations?

Nope, just a bigger cache.  Some of the bits in the cache
registers now have meaning where they didn't before.

Also, in one of the registers the bits are flipped around.  This
was because the tags got smaller, and so a few bits somewhere ended
up getting swapped around.  Don't ask me why, and I'll tell you no lies.

:)
 

quoted

quoted

...  Or did simply doubling the cache size break something that had
been lurking around waiting to bite us?  Do you know what is wrong?

Relax :-).  If there was trouble, I would be one of the first to
know and I would be working to correct it.

The only possible problem I could see is if you had a routine that
flushed the caches manually.  Of course, if you did, you probably
needed to be slapped anyways.

Richard, how DO you flush the cache if you need to do so without doing it
"manually"?  Say I have a boot ROM that loads code into RAM and wants to flush
the cache afterwards so the D cache is coherent wrt the I cache.  I need to
flush all of the dirty D cache lines out.  Is there some other usage of
"manually" that I am missing?  Of course, I ALWAYS loop over the entire area
I am flushing using a DCBF/ICBI for each addressable cache line boundary (16
bytes for MPC8xx processors).

quoted

quoted

Dan, can you tell us if the DMA operations on the 8xx processors are cache
coherent?

Yes, I can tell you, and no they are not.

Dan's correct, they are not.  The caches sit between the CPU
(really the MMUs) and the bus.  The DMA controller is part of the
CPM, which also sits on the bus.  The 8xx family doesn't support
any kind of snooping for those type of accesses.  You can either mark
the locations you need to DMA non-cacheable (if you plan on writing to
the memory), or as write-through (if you plan on reading from them).
Just basic good system design.

Actually and arguably, "good system design" says precisely the opposite.  If
you're building up, say, network protocol packets to be DMAed out through a FEC
you want to be able to touch the area of the packet buffer repeatedly without
having to do a memory cycle for each "touch".  Cacheable packet buffers are the
only way to get this performance enhancing behavior.  The added benefit that
you get burst accesses to RAM comes with caches ON as well.  Write-thru won't
get you either of these benefits, if I understand what "write thru" means for
MPC8xx, since it will always start a memory write cycle after each access. 
There will be no attempt to aggregate the accesses to adjacent bytes, shorts or
longs into cache line bursts out to RAM unless the cache is in full copy back
mode.  You get this performance at the cost of having to "manually" (there's
that word again!) flush the cache for the area of the bufferr before starting
the DMA.  For receive operations, you can simply invalidate (rather than
flush - cheaper) the cache for the range but only if the buffer is guaranteed to
span the entire cache line aligned region.

quoted

quoted

..... so I have erred on the conservative side and in my drivers
have done cache flushing operations before/after each DMA as appropriate for
DMA direction.

What kind of drivers are you using?  The only thing likely to
perform DMA on the 8xx is the CPM.  There are already CPM functions
for managing this stuff, which is a combination of uncached
memory and cache management.  Try to use something that already
exists, or at least use it as a model for something special
you are doing.

Being conservative never hurt anyone...Unless it seriously hurts your
performance, I wouldn't worry to heavily about it.  BTW, you shouldn't
be caching the internal memory map, including DPRAM, and memory
areas the CPM writes to.

That much was clear.  My IMMR and DPRAM areas are non-cacheable.
 

quoted

quoted

....  MOT sent us 40 chips of which 4 or 5 were rev A.

Cool.  Make key chains out of them.  Seriously, depending upon
what you are trying to accomplish, the Rev. A parts should work
fine.  It may take a few software patches, but they will work.

Really?  Wow.  Rev. A's.  Maybe you *should* make keychains out
of them.  I can't remember which fixes went in between A and B3,
but you should be able to find them on the website in the various
errata.

Note that these were rev A MPC850s not MPC860s.  Are these two chip families
basically the same except for marketing and perhaps a process revision, or am
I smoking something?

There were/are tons and tons of I2C errata.  Most related to > multi-master
mode.  Another long and sordid story, no doubt.
 

quoted

quoted

wait for the boards to which rev A 850s had been nailed to be reworked (several
days' turnaround) to get working boards so I can bring them up and give them to
the other software folks.

There are advantages to working with people with Motorola connections.

quoted

It also appears that there are a lot of errata associated with the MPC850 rev
A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.

Every revision is better, but Rev. B still has some things to work
around.

Really?  Hopefully nothing I need to worry about.  Figuring out the
G14 errata for the MPC823 was a life-unaffirming experience.

quoted

        -- Dan

BTW, Brendan, I work in Motorola supporting the MPC821/MPC823, 
and I tend to lurk on this mailing list as well as comp.sys.powerpc.tech

BTW, Richard, you may be a very very useful resource for those of us paving new
ground on these parts.  Can I be so bold as to hit you with the occasional deep
technical question?  I promise it won't be often...  Really.

Thanks for the info.

 -- 
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/