Best embedded PPC eval board for Linux

Best embedded PPC eval board for Linux

[Tom Shaver]

We are looking to go to an embedded Linux/PowerPC solution to replace our
existing IBM PPC403 design running IBM's OS Open. Are there any eval boards
out there now with corresponding Linux kernels, ready to boot out of the
box? We are looking to do as little kernel hacking as possible. Our only
requirement is an Ethernet interface, preferably 100Mbit. Nothing "fancy"
like PCI, USB, etc.

Tom Shaver
Electrical Engineer
Planning Systems Inc.


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

Re: Best embedded PPC eval board for Linux

[Jo-Ellen F. Mathews]

Tom,

If you're looking for a quick, out of the box solution, I highly recommend
Embedded Planet's new 'Linux Planet' product as a starting point for your
search.  This development kit is made up of Embedded Planet's RPX Lite
board (MPC823) as well as a default kernel ready to run on this board,
kernel sources, package sources, a minimal root filesystem for the board,
and development tools for building applications.  Of course, once you've
built a kernel and applications to suit your requirements, you can
purchase just the boards in any desired quantities from Embedded Planet.
http://www.embeddedplanet.com

Jo-Ellen
---------------------------------------------------------
Jo-Ellen F. Mathews

AbsoluteValue Software     Web:    http://www.absoval.com
P.O. Box 941149            e-mail: joellen@absoval.com
Maitland, FL 32794-1149    Phone:  407.644.8582
USA                        Fax:    407.539.1294

On Fri, 17 Mar 2000, Tom Shaver wrote:

>
> We are looking to go to an embedded Linux/PowerPC solution to replace our
> existing IBM PPC403 design running IBM's OS Open. Are there any eval boards
> out there now with corresponding Linux kernels, ready to boot out of the
> box? We are looking to do as little kernel hacking as possible. Our only
> requirement is an Ethernet interface, preferably 100Mbit. Nothing "fancy"
> like PCI, USB, etc.
>
> Tom Shaver
> Electrical Engineer
> Planning Systems Inc.
>
>
>


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

Re: What is the catch with IDMA on MPC860?

[Geir Frode Raanes]

On Fri, 17 Mar 2000, Richard Hendricks wrote:

>
>
> Geir Frode Raanes wrote:
> >
> > Revision C or later of the '860 will even perform
> > a single-address _burst_ transfer on IDMA channel 1.
> > This I would love to do from our in-house designed
> > frame grabber to main memory. Then I could avoid
> > disabling all interrupts while bursting. Meaning
> > I could still catch run-away situations on a
> > time-out basis. Today things simply lock up...

> The biggest complaint I hear is the performance stinks.
> Which it does, since it is really a software based DMA
> algorithm running on the CPM.

Possibely. But where does the manual say that the
performance stinks? It should be documented somewhere.

> I *think* you mean Single-buffer burst flyby mode.

That is correct. I just quoted the subtitle of figure 20-15.
But the chapter is named Single-buffer burst flyby mode.
The following figure numbers are collected from the current
version of the MPC860UM user manual in PDF form @ motorola.

Figure 14-5:  Single-Beat Cycle Basic Timing Zero Wait States
              Two clock cycles per bus cycle.

Figure 14-12: Burst-Read Cycle with Zero Wait state.
              Five clock cycles per four words burst cycle.

Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
              /TA alternating resulting in one waitstate per
              word and thus nine clock cycles per four words
              burst cycle.

Figure 14-14: Burst-Read Cycle with Wait States between Beats.
              Would have been identical to figure 20-15
              with identical /TA pattern.


Now, the question is - what controls the /TA line?
Will I get full speed if actively driving the /TA line low for
the duration of the IDMA1 burst cycle? Or for that matter in the
Single-address/Single-cycle Fly-by transfer of figure 20-10?
The subtitles states that /TA is externally generated. What then
stops me from running the IDMA bus cycle with normal PIO mode
timing as per figure 14-5?


Figure 20-10: /SDACK timing diagram
              Single-Address Peripheral write
              __EXTERNALLY GENERATED /TA__


--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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

Re: What is the catch with IDMA on MPC860?

[Alan Mimms]

Regarding the "where does the manual say that the performance stinks"
comment: even though people like Richard are VERY forthcoming with
"issues" with chips (THANKS Richard), I doubt a company like MOT will
EVER admit in a manual or other official document they built something
that stinks even a little bit.  See the MPC801 for an example of this
where virtually EVERYTHING about the chip stinks (including the crappy
inaccurate manual) and nothing is ever said in written form to that
effect.  (For those unused to my cynical style, I love MOT and my
company has even made a bunch of money selling devices built on the
MPC801.  But they are NOT perfect - as I'm sure Richard and numerous
will attest - and they will rarely admit it in writing.)

a

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/17/00, 9:02:22 AM, "Geir Frode Raanes" <geirfrs@invalid.ed.ntnu.no>
wrote regarding Re: What is the catch with IDMA on MPC860?:


> On Fri, 17 Mar 2000, Richard Hendricks wrote:

> >
> >
> > Geir Frode Raanes wrote:
> > >
> > > Revision C or later of the '860 will even perform
> > > a single-address _burst_ transfer on IDMA channel 1.
> > > This I would love to do from our in-house designed
> > > frame grabber to main memory. Then I could avoid
> > > disabling all interrupts while bursting. Meaning
> > > I could still catch run-away situations on a
> > > time-out basis. Today things simply lock up...

> > The biggest complaint I hear is the performance stinks.
> > Which it does, since it is really a software based DMA
> > algorithm running on the CPM.

> Possibely. But where does the manual say that the
> performance stinks? It should be documented somewhere.

> > I *think* you mean Single-buffer burst flyby mode.

> That is correct. I just quoted the subtitle of figure 20-15.
> But the chapter is named Single-buffer burst flyby mode.
> The following figure numbers are collected from the current
> version of the MPC860UM user manual in PDF form @ motorola.

> Figure 14-5:  Single-Beat Cycle Basic Timing Zero Wait States
>               Two clock cycles per bus cycle.

> Figure 14-12: Burst-Read Cycle with Zero Wait state.
>               Five clock cycles per four words burst cycle.

> Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
>               /TA alternating resulting in one waitstate per
>               word and thus nine clock cycles per four words
>               burst cycle.

> Figure 14-14: Burst-Read Cycle with Wait States between Beats.
>               Would have been identical to figure 20-15
>               with identical /TA pattern.


> Now, the question is - what controls the /TA line?
> Will I get full speed if actively driving the /TA line low for
> the duration of the IDMA1 burst cycle? Or for that matter in the
> Single-address/Single-cycle Fly-by transfer of figure 20-10?
> The subtitles states that /TA is externally generated. What then
> stops me from running the IDMA bus cycle with normal PIO mode
> timing as per figure 14-5?


> Figure 20-10: /SDACK timing diagram
>               Single-Address Peripheral write
>               __EXTERNALLY GENERATED /TA__


> --
>   ******************************************************
>   Never ever underestimate the power of human stupidity.
>   -Robert Anson Heinlein

>               GeirFRS@invalid.and.so.forth
>   ******************************************************


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

Re: What is the catch with IDMA on MPC860?

[Dan Malek]

Alan Mimms wrote:
>
> Regarding the "where does the manual say that the performance stinks"

That's an irrelevant question, as no one literally said "the performance
stinks", and no one should.

If you take a look at the timing diagrams and the CPM performance
worksheets, you will find the IDMA is not terribly efficient.  This
is a system design choice.  You can move data significantly faster
using PPC core programmed I/O operations.  The other system design
considerations surround the use of the CPM.  If you choose to use
the IDMA, it affects other CPM operations.

The IDMA could very well statisfy a particular system design.  If
the feature wasn't there, people would be complaining for that
reason.

The 860 is a killer communication processor.  When you start using
some of these other features, it significantly impacts this capability.
In the case if IDMA, control signals used for some communication
capabilities are lost, and you have to choose configuration options
that further erode the communication processing performance.  Just
be aware of this.


	-- Dan

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

Re: What is the catch with IDMA on MPC860?

[Richard Hendricks]

Ah, but there's an assumption you're making Dan, and that's the IDMA
was added for the 860.  It was really added for camera customers using
the MPC821/MPC823.  That's why single buffer burst flyby was added,
and that's why it supports interlacing.  In the MPC823 manual, we even
describe how to setup IDMA to interface to a CCD camera with multiple
fields.

Anyways, IDMA performance is horse that has been beaten enough here
in Motorola.  The hardware DMA controller in the original 360 took
too much space, and so using the CPM to do IDMA was born.  For most
situations, it is a perfect compromise.

Actually, I was remiss in my earlier statement.  The biggest complaint
about IDMA is that you can't use it with Ethernet.  On the latest
version of the MPC823 this is fixed.  The problem comes about because
the CAM capability of the Ethernet can't be turned off.  CAM was removed
from the feature list of the MPC823, but wasn't removed from the die
itself until Rev. A (I think).  It caused us many a headaches as
we couldn't understand why a collegue's audio codec using
DMA would always go haywire whenever he received an Ethernet packet.

Dan Malek wrote:
>
> Alan Mimms wrote:
> >
> > Regarding the "where does the manual say that the performance stinks"
>
> That's an irrelevant question, as no one literally said "the performance
> stinks", and no one should.
>
> If you take a look at the timing diagrams and the CPM performance
> worksheets, you will find the IDMA is not terribly efficient.  This
> is a system design choice.  You can move data significantly faster
> using PPC core programmed I/O operations.  The other system design
> considerations surround the use of the CPM.  If you choose to use
> the IDMA, it affects other CPM operations.
>
> The IDMA could very well statisfy a particular system design.  If
> the feature wasn't there, people would be complaining for that
> reason.
>
> The 860 is a killer communication processor.  When you start using
> some of these other features, it significantly impacts this capability.
> In the case if IDMA, control signals used for some communication
> capabilities are lost, and you have to choose configuration options
> that further erode the communication processing performance.  Just
> be aware of this.
>
>         -- Dan

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

Re: What is the catch with IDMA on MPC860?

[Dan Malek]

Richard Hendricks wrote:
>
> Ah, but there's an assumption you're making Dan, and that's the IDMA
> was added for the 860.

Geeze, I guess my couple of years of technical writing classes were
a waste of time.  Where did it appear I was making an assumption?

I said:

	1.  The 860 is a killer communication processor
	2.  The IDMA is a feature that requires system design trade offs
	3.  If IDMA wasn't present, people would likely request it


> ....  It was really added for camera customers using
> the MPC821/MPC823.

OK, but we weren't talking about 821 or 823.  There is a wide range of
features available in the 8xx family, and unfortunately you can't
get everything all of the time.  The IDMA on the 860 falls into
this category.

My original response long ago was to ensure people consider the system
design, and I attempted to include some supporting detail.  This has
been turned into "performance sucks" and "Dan is making assumptions."
Neither is true.


	-- Dan

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

Re: What is the catch with IDMA on MPC860?

[Richard Hendricks]

Alan Mimms wrote:
>
> Regarding the "where does the manual say that the performance stinks"
> comment: even though people like Richard are VERY forthcoming with
> "issues" with chips (THANKS Richard), I doubt a company like MOT will
> EVER admit in a manual or other official document they built something
> that stinks even a little bit.  See the MPC801 for an example of this
> where virtually EVERYTHING about the chip stinks (including the crappy
> inaccurate manual) and nothing is ever said in written form to that
> effect.  (For those unused to my cynical style, I love MOT and my
> company has even made a bunch of money selling devices built on the
> MPC801.  But they are NOT perfect - as I'm sure Richard and numerous
> will attest - and they will rarely admit it in writing.)

I think this issue is covered quite well in the boilerplate at the
beginning of the MPC823 manual.

"Motorola makes no warranty, representation or guarantee regarding
the suitability of its products for any particular purpose..."

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

Re: What is the catch with IDMA on MPC860?

[Alan Mimms]

So THAT's why these big companies never tell us when they find their
junk sucks.  They have it in the fine print at the front of every manual!

a

On Fri, 17 Mar 2000, Richard Hendricks wrote:
> Alan Mimms wrote:
> >
> > Regarding the "where does the manual say that the performance stinks"
> > comment: even though people like Richard are VERY forthcoming with
> > "issues" with chips (THANKS Richard), I doubt a company like MOT will
> > EVER admit in a manual or other official document they built something
> > that stinks even a little bit.  See the MPC801 for an example of this
> > where virtually EVERYTHING about the chip stinks (including the crappy
> > inaccurate manual) and nothing is ever said in written form to that
> > effect.  (For those unused to my cynical style, I love MOT and my
> > company has even made a bunch of money selling devices built on the
> > MPC801.  But they are NOT perfect - as I'm sure Richard and numerous
> > will attest - and they will rarely admit it in writing.)
>
> I think this issue is covered quite well in the boilerplate at the
> beginning of the MPC823 manual.
>
> "Motorola makes no warranty, representation or guarantee regarding
> the suitability of its products for any particular purpose..."
>
--
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/

Re: What is the catch with IDMA on MPC860?

[Richard Hendricks]

Geir Frode Raanes wrote:
>
> On Fri, 17 Mar 2000, Richard Hendricks wrote:
>
> >
> >
> > Geir Frode Raanes wrote:
> > >
> > > Revision C or later of the '860 will even perform
> > > a single-address _burst_ transfer on IDMA channel 1.
> > > This I would love to do from our in-house designed
> > > frame grabber to main memory. Then I could avoid
> > > disabling all interrupts while bursting. Meaning
> > > I could still catch run-away situations on a
> > > time-out basis. Today things simply lock up...
>
> > The biggest complaint I hear is the performance stinks.
> > Which it does, since it is really a software based DMA
> > algorithm running on the CPM.
>
> Possibely. But where does the manual say that the
> performance stinks? It should be documented somewhere.

Of course!  It's documented in the Serial Communications
Performance chapter.  Something like 3-4 pages at the very
end.  At 25 MHz (the values scale linearly with frequency,
more or less), and with no other loading on the CPM,
Memory to Memory burst IDMA transactions top out at 10.4 MB/sec,
or, at a more reasonable speed like 66 MHz, 27.45 MB/sec.

YMMV, btw. :)

> > I *think* you mean Single-buffer burst flyby mode.
>
> That is correct. I just quoted the subtitle of figure 20-15.
> But the chapter is named Single-buffer burst flyby mode.
> The following figure numbers are collected from the current
> version of the MPC860UM user manual in PDF form @ motorola.
>
> Figure 14-5:  Single-Beat Cycle Basic Timing Zero Wait States
>               Two clock cycles per bus cycle.
>
> Figure 14-12: Burst-Read Cycle with Zero Wait state.
>               Five clock cycles per four words burst cycle.
>
> Figure 20-15: Single Buffer/Address IDMA1 Burst Timing.
>               /TA alternating resulting in one waitstate per
>               word and thus nine clock cycles per four words
>               burst cycle.
>
> Figure 14-14: Burst-Read Cycle with Wait States between Beats.
>               Would have been identical to figure 20-15
>               with identical /TA pattern.
>
> Now, the question is - what controls the /TA line?

Er, you're doing DMA to/from a memory.  The timing of that
memory controls /TA.  If you're using your DRAM with one
of the UPMs, and you're targeting that DRAM with IDMA, it
uses the UPM to control the DRAM. (For a flyby-mode transaction).

> Will I get full speed if actively driving the /TA line low for
> the duration of the IDMA1 burst cycle? Or for that matter in the
> Single-address/Single-cycle Fly-by transfer of figure 20-10?
> The subtitles states that /TA is externally generated. What then
> stops me from running the IDMA bus cycle with normal PIO mode
> timing as per figure 14-5?

You're limited to however fast you can interface to the
memory.  If your peripheral needs extra cycles inserted in,
it could use UPWAITx to do so.

> Figure 20-10: /SDACK timing diagram
>               Single-Address Peripheral write
>               __EXTERNALLY GENERATED /TA__
>
> --
>   ******************************************************
>   Never ever underestimate the power of human stupidity.
>   -Robert Anson Heinlein
>
>                 GeirFRS@invalid.and.so.forth
>   ******************************************************
>

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

Re: What is the catch with IDMA on MPC860?

[Geir Frode Raanes]

On Fri, 17 Mar 2000, Richard Hendricks wrote:

> Geir Frode Raanes wrote:
> >
> > Possibely. But where does the manual say that the
> > performance stinks? It should be documented somewhere.
>
> Of course!  It's documented in the Serial Communications
> Performance chapter.  Something like 3-4 pages at the very
> end.  At 25 MHz (the values scale linearly with frequency,
> more or less), and with no other loading on the CPM,
> Memory to Memory burst IDMA transactions top out at 10.4 MB/sec,
> or, at a more reasonable speed like 66 MHz, 27.45 MB/sec.


Ah. RTFM. The paper version - Appendix B - that is.
Can still not find it in the PDF version. Funny.
Thank you anyway. Those where the timing diagrams I
were looking for. I am just moving up from the world
of microcontrollers and FPGA to microprocessors.
Can't say I am all that thrilled about IF-THEN-ELSE
soft timing datasheets. But I'll manage.

And 27.45 MBytes per sec gives me a reasonable headroom
from the 20 MBytes per second requirement of the grabber,
and still allow me to leave interrupts enabeled.
And yes, it is in fact a CCD camera grabber without
much local buffering.


What I was really asking was what the "inefficient"
label on IDMA was all about. More specifically, if that
meant that IDMA wasted bus clock cycles - i.e. hogging
the bus while setting up the transfer or requiring
wait states irrespectible of the source/target speed.
Considering the timing diagrams in Appendix B and given
the Motorola "will then perform a fast back-to-back
transfer" statement this does not seem to be the case.

I can live with the fact that IDMA can not utilize the
bus 100% of the time as long as it __relinquish the bus__
at all times it does not perform __full speed__ data
movements. Actually I prefer it does just that.

The other use of these IDMA channels is for soft
PCI interface. There is specified a limit of 8 PCI
clocks on target latency. That rules out any interrupt
based interface handling. But IDMA to configuration
space and memory space respectively in combination
with an interrupt migth do the trick.

> > Now, the question is - what controls the /TA line?
>
> Er, you're doing DMA to/from a memory.  The timing of that
> memory controls /TA.  If you're using your DRAM with one
> of the UPMs, and you're targeting that DRAM with IDMA, it
> uses the UPM to control the DRAM. (For a flyby-mode transaction).

I am aware of that. What I was really asking was what is the
upper boundary on the timing. Like for instance the timing
of the TMP68303 microcontroller from Toshiba wich stated that
the _slower_ of the internally generated /DTACK and externally
applied is used for DMA transfers.

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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

Re: What is the catch with IDMA on MPC860?

[Richard Hendricks]

Geir Frode Raanes wrote:
>
> On Fri, 17 Mar 2000, Richard Hendricks wrote:
>
> > Geir Frode Raanes wrote:
> > >
> > > Possibely. But where does the manual say that the
> > > performance stinks? It should be documented somewhere.
> >
> > Of course!  It's documented in the Serial Communications
> > Performance chapter.  Something like 3-4 pages at the very
> > end.  At 25 MHz (the values scale linearly with frequency,
> > more or less), and with no other loading on the CPM,
> > Memory to Memory burst IDMA transactions top out at 10.4 MB/sec,
> > or, at a more reasonable speed like 66 MHz, 27.45 MB/sec.
>
> Ah. RTFM. The paper version - Appendix B - that is.
> Can still not find it in the PDF version. Funny.
> Thank you anyway. Those where the timing diagrams I
> were looking for.

Ah, I am support for the MPC823/MPC823, so everything is
tinged with MPC82x colored glasses.  I don't happen to have
an MPC860 manual handy anymore.

> I am just moving up from the world
> of microcontrollers and FPGA to microprocessors.
> Can't say I am all that thrilled about IF-THEN-ELSE
> soft timing datasheets. But I'll manage.

Such is life in the high end world ;)

> And 27.45 MBytes per sec gives me a reasonable headroom
> from the 20 MBytes per second requirement of the grabber,
> and still allow me to leave interrupts enabeled.
> And yes, it is in fact a CCD camera grabber without
> much local buffering.

Just be sure you don't overtax your CPM.  20/27.45 = 73%,
but if you start adding in UARTs, etc, you might be getting
close to the edge.

> What I was really asking was what the "inefficient"
> label on IDMA was all about. More specifically, if that
> meant that IDMA wasted bus clock cycles - i.e. hogging
> the bus while setting up the transfer or requiring
> wait states irrespectible of the source/target speed.
> Considering the timing diagrams in Appendix B and given
> the Motorola "will then perform a fast back-to-back
> transfer" statement this does not seem to be the case.

Oh yes, you're right.  The CPM does all the staging internally,
and it doesn't need to "hold" the bus for the cycles while
it is packing/unpacking data.  It only takes the bus
when it is actively transferring data.

> I can live with the fact that IDMA can not utilize the
> bus 100% of the time as long as it __relinquish the bus__
> at all times it does not perform __full speed__ data
> movements. Actually I prefer it does just that.

And that's just what it does.  Sorry about the misunderstanding.

> The other use of these IDMA channels is for soft
> PCI interface. There is specified a limit of 8 PCI
> clocks on target latency. That rules out any interrupt
> based interface handling. But IDMA to configuration
> space and memory space respectively in combination
> with an interrupt migth do the trick.
>
> > > Now, the question is - what controls the /TA line?
> >
> > Er, you're doing DMA to/from a memory.  The timing of that
> > memory controls /TA.  If you're using your DRAM with one
> > of the UPMs, and you're targeting that DRAM with IDMA, it
> > uses the UPM to control the DRAM. (For a flyby-mode transaction).
>
> I am aware of that. What I was really asking was what is the
> upper boundary on the timing. Like for instance the timing
> of the TMP68303 microcontroller from Toshiba wich stated that
> the _slower_ of the internally generated /DTACK and externally
> applied is used for DMA transfers.

The timing is controlled by either the UPM or GPCM currently in
control of the transaction.  If you want finer scale timings,
then you can check out the timing spreadsheets (for the MPC821/MPC823
anyways).

> --
>   ******************************************************
>   Never ever underestimate the power of human stupidity.
>   -Robert Anson Heinlein
>
>                 GeirFRS@invalid.and.so.forth
>   ******************************************************

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

Re: What is the catch with IDMA on MPC860?

[Noah Misch]

Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
are, or pointing me to a document that explains them?  I see these terms
used a lot, but I don't know what they stand for and have only a general
idea of what they are.  I apologize for wasting your time with a worthless
question.

<snip>

>Just be sure you don't overtax your CPM.  20/27.45 = 73%,
>but if you start adding in UARTs, etc, you might be getting
>close to the edge.

<snip>

>> I can live with the fact that IDMA can not utilize the
>> bus 100% of the time as long as it __relinquish the bus__
>> at all times it does not perform __full speed__ data
>> movements. Actually I prefer it does just that.

<snip

>> > Er, you're doing DMA to/from a memory.  The timing of that
>> > memory controls /TA.  If you're using your DRAM with one
>> > of the UPMs, and you're targeting that DRAM with IDMA, it
>> > uses the UPM to control the DRAM. (For a flyby-mode transaction).

<snip>
Noah Misch
nmisch@erols.com

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

Re: What is the catch with IDMA on MPC860?

[Graham Stoney]

Hi Noad,

Noah Misch writes:
> Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
> are, or pointing me to a document that explains them?  I see these terms
> used a lot, but I don't know what they stand for and have only a general
> idea of what they are.  I apologize for wasting your time with a worthless
> question.

Have a look at the Glossary in the HOWTO, at:
    http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO-19.html

As always, I'd be very interested in any feedback and pointers to more
authoratative references.

Regards,
Graham

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

Re: What is the catch with IDMA on MPC860?

[Claude Robitaille]

The most authoritative reference for thoses terms is the PowerQUICC
(MPC8xx) user's manual. You can find it on the Motorola web site at:
http://www.mot.com/netcomm


Claude

On Thu, 23 Mar 2000, Graham Stoney wrote:

>
> Hi Noad,
>
> Noah Misch writes:
> > Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
> > are, or pointing me to a document that explains them?  I see these terms
> > used a lot, but I don't know what they stand for and have only a general
> > idea of what they are.  I apologize for wasting your time with a worthless
> > question.
>
> Have a look at the Glossary in the HOWTO, at:
>     http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO-19.html
>
> As always, I'd be very interested in any feedback and pointers to more
> authoratative references.
>
> Regards,
> Graham
>
>
>


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

Re: What is the catch with IDMA on MPC860?

[Richard Hendricks]

Noah,
  Everyone else pointed you to documents, but I'll give you a
nickel explaination.

CPM = Communications processor module.  It's the second CPU on the
MPC8xx family that handles communication (so, say, the PowerPC CPU
doesn't need to worry about handling each byte of an ethernet packet).
It is based off the MPC68360 CPM.  It has been modifed by adding
a MAC unit to do DSP, and changing the hardware DMA to software
(running on the CPM).  Kinda makes the MPC8xx family "dual core", but
that may be strecthing it a bit.  Programming of the CPM is restricted
to Motorola and a few key customers.

UART = Universal Asynchronous Receiver/Transmitter.  A serial port,
where data is transmitted one bit at a time.  Used mostly in PCs as
RS-232.

DMA/IDMA = Direct Memory Access/ Independant DMA.  DMA allows memory
transactions to go on without CPU intervention.  Say you have a digital
camera with a CCD.  You would want the CCD's information constantly
copied to main memory.  With DMA, you can do that without the CPU
having to transfer every byte itself.  IDMA is just how DMA is
implemented in the MPC8xx by the CPM.  Independant means
independant from the serial channels, I guess.  You could also
use DMA, say, to feed an audio chip data when it requests it.

UPM = User Programmable Machine.  A special state machine within
the Memory Controller for handling complex memories like DRAM and
custom user interfaces.  It allows you to control the waveforms of
the various memory signals.  Sorta like a microcode for a memory
controller.

SCC = Serial Communications Controller.  Many serial protocols are
similar enough that a general "serial engine" can handle them.  The SCC
is powerful enough to do everything from RS-232 up to Ethernet.  There's
also a FCC, or Fast CC, and an SMC.  An SMC is a Serial Management
Controller, which is designed for very simple serial protocols. As far
as actual nuts & bolts, the SCC can handle more bandwidth since much
of its functionality is hardware-based, while most of the SMC
functionality is controlled by software.  This is why the SMC
can't handle the same amount of data bandwidth the SCC can.

Noah Misch wrote:
>
> Would you mind telling me briefly what CPM, UART, DMA/IDMA, UPM, and SCC
> are, or pointing me to a document that explains them?  I see these terms
> used a lot, but I don't know what they stand for and have only a general
> idea of what they are.  I apologize for wasting your time with a worthless
> question.
>
> <snip>
>
> >Just be sure you don't overtax your CPM.  20/27.45 = 73%,
> >but if you start adding in UARTs, etc, you might be getting
> >close to the edge.
>
> <snip>
>
> >> I can live with the fact that IDMA can not utilize the
> >> bus 100% of the time as long as it __relinquish the bus__
> >> at all times it does not perform __full speed__ data
> >> movements. Actually I prefer it does just that.
>
> <snip
>
> >> > Er, you're doing DMA to/from a memory.  The timing of that
> >> > memory controls /TA.  If you're using your DRAM with one
> >> > of the UPMs, and you're targeting that DRAM with IDMA, it
> >> > uses the UPM to control the DRAM. (For a flyby-mode transaction).
>
> <snip>
> Noah Misch
> nmisch@erols.com
>

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

What is the catch with IDMA on MPC860?

[Geir Frode Raanes]

I must admit - I love DMA. A DMA a day keeps the
software away. But I repeatedly hear - both inhouse
and on this list that the MPC860 IDMA implementation
leaves somewhat to be wanted. Problem is, I can not
figure out what. MPC860 IDMA looks OK.

According to the documentation, the SDMA/IDMA (DSP-)
controller will perform a normal arbitration on the
internal U-bus and, when granted access, perform a
fast back-to-back transfer. In the IDMA case the
transfer will continue until exhaustion of the
(possibely chained) Buffer Descriptor (list.)
The SDMA will OTOH perform an alternating bus
cycle-steal transfer.

Dual address modes will even interface between
different bus sizes on source and target by grouping
data in the internal buffer memory, thus utilizing
the widest bus width possible on both read and write.


Revision C or later of the '860 will even perform
a single-address _burst_ transfer on IDMA channel 1.
This I would love to do from our in-house designed
frame grabber to main memory. Then I could avoid
disabling all interrupts while bursting. Meaning
I could still catch run-away situations on a
time-out basis. Today things simply lock up...

Sooo, what is really the problem with IDMA?

---

  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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