Has anyone made the 8240 do burst reads from PCI memory?

Has anyone made the 8240 do burst reads from PCI memory?

[Callebaut Benoit]

I Ron

>So I was just wondering if anyone has actually gotten an 8240 to access PCI
>memory with multiple beat, memory read cmds.?

The response is yes, We do PCI memory burst write but we had to implements DMA
transfer on the PPC to do this. At low level, this implementation is very
easy, you must just enable the PCI bus snooping bit to avoid "strange" memory
content problem due to the cache.

Per default the PPC will try to send a full DWORD (CBEN[0..3] = 0X0) with one
PCI clock by DWORD.
Such a transfer is 5 time faster than without burst.

Note that you must use physical addresses with the DMA controller. This mean
that you must do the reverse than do ioremap to retreive it. And beware with
virt_to_phys or phys_to_bus, I am not sure that it work with PCI addresses.
I wrote this code, so if you want it, please ask.

Good Luck,
Benoit Callebaut

------------------------------------------------------------------------------
----
Benoit Callebaut
Software Development Engineer
Barco | Control Rooms
Noordlaan 5, 8520 Kuurne, Belgium

Tel 	+32(0)56 36 84 28
Fax 	+32(0)56 36 86 05

mailto:benoit.callebaut@barco.com
http://www.barcocontrolrooms.com


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

Has anyone made the 8240 do burst reads from PCI memory?

[Ron Bianco]

Hello,

We have a custom 8240 board running a linux 2.2.x kernel variant with some dual
port SRAM mapped into PCI memory space using a custom CPLD.  We use a modified
version of the sandpoint setup in the ppc linux kernel initialization code.

In the ISR of a custom device driver we read and write to the PCI mem
successfully.

FYI, although not a PCI expert, I'm trying to determine if we need to upgrade
our CPLD code in order to successfully support memory read cycles with more than
one data phase.

Even with sequential reads in groups of 8 words, ( or writes for that matter )
we are unable to get the 8240 to do other than single (beat) word read PCI
cycles.  One 'strange' thing in particular is that the 8240 as PCI initiator is
keeping !FRAME asserted only very briefly.
It also de-asserts !IRDY very soon after the first data phase completes.  It may
be that the 8240 is just indicating a wait and we need to handle that better.

Anyway, according to the 8240 user's manual it supports burst ordering of the
linear incrementing type for memory accesses when the 2 low order bits of the
address are 0, as we are doing.

So I was just wondering if anyone has actually gotten an 8240 to access PCI
memory with multiple beat, memory read cmds.?

regards, Ron


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

Re: Has anyone made the 8240 do burst reads from PCI memory?

[Jochen Roth]

At 12:50 PM 6/6/03 -0700, Ron Bianco wrote:
>FYI, although not a PCI expert, I'm trying to determine if we need to upgrade
>our CPLD code in order to successfully support memory read cycles with
>more than
>one data phase.

It's been a while that I worked on this, but here are some things I remember:

You implemented the PCI Read Line/Multiple commands in the CPLD, I assume.
Check
the PCI spec for details on the protocol.

You then will have to set up things like the PCI command used by the 8240 and
the PCI latency register.

Check the DBAT settings used for accessing your CPLD memory space. If you
use the
generic MMIO mapping provided in the kernel, then caching is disabled for those
accesses. If I remember correctly, the 603 core will not burst in that case.

>Even with sequential reads in groups of 8 words, ( or writes for that matter )
>we are unable to get the 8240 to do other than single (beat) word read PCI
>cycles.  One 'strange' thing in particular is that the 8240 as PCI
>initiator is
>keeping !FRAME asserted only very briefly.
>It also de-asserts !IRDY very soon after the first data phase
>completes.  It may
>be that the 8240 is just indicating a wait and we need to handle that better.

Did you check the CBE lines for the PCI command issued by the 8240? If it was a
generic single word read, then what you describe would be normal, I think.

Regards,

Jochen Roth
ZNYX Networks


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

RE: Has anyone made the 8240 do burst reads from PCI memory?

[Ron Bianco]

> -----Original Message-----
> From: Jochen Roth [mailto:jochen@znyx.com]
>
> At 12:50 PM 6/6/03 -0700, Ron Bianco wrote:
> >FYI, although not a PCI expert, I'm trying to determine if we need to upgrade
> >our CPLD code in order to successfully support memory read cycles with
> >more than
> >one data phase.
>
> It's been a while that I worked on this, but here are some things I remember:
>
> You implemented the PCI Read Line/Multiple commands in the CPLD, I assume.
> Check
> the PCI spec for details on the protocol.

Thanks for the reply.  Yes, it will respond to all 3 types.

> You then will have to set up things like the PCI command used by the 8240 and
> the PCI latency register.

Yup, checked.

> Check the DBAT settings used for accessing your CPLD memory space. If you
> use the
> generic MMIO mapping provided in the kernel, then caching is disabled
> for those
> accesses. If I remember correctly, the 603 core will not burst in that case.

Yeah, a couple years ago when I did the linux port, I was sure I had used an
unused DBAT to make sure no address translation would be done for the PCI mem
address range, but now I only see the default setup for the DBATs in 'our' code
base.
So I don't yet have a real explanation as to why the PCI mem space we're using
is marked cache inhibited, but it must be somewhere.  Prelim. examination of
DBAT registers with the BDI2000 doesn't seem to confirm it...sigh.   Another
confusing thing.

But anyway, in the 8240 chip errata #14, I see that prior to chip rev 1.2 , the
8240 corrupts inbound data/inst. when bursting into cache from PCI space and the
work around is to mark the PCI space as cache inhibited, which results in single
beat only PCI reads being initiated, and use DMA into main mem. if multi beat
reads are desired.   So the solution to the problem in our driver when needing
to read relatively lots of data and due to 'slow' single beat PCI read accesses,
for our existing customers ( using older chips ), will have to be usage of DMA
in our driver.

> Did you check the CBE lines for the PCI command issued by the 8240?
> If it was a
> generic single word read, then what you describe would be normal, I think.

Yeah, I guess if the 8240 is only driving binary 0110 ( read cmd ) on the CBE
lines during the address/cmd phase then that means only single word cycles are
done.  Mutil beat cycles require one of the other read cmds.  I got temp.
confused by the PCI doc and the fact that the 8240 has 8 words of
processor-to-PCI-read buffers.  So I figured maybe that even if the cache wasn't
involved that a multi-beat read with cmd 0110 might still be possible.

Thanks a lot.
FYI, for other users of the 8240, the errata is now more readily available than
in the past, and is downloadable from this page:

http://search.motorola.com/semiconductors/query.html?qt=MPC8240&Go.x=12&Go.y=9

which is a link I hope will work for anyone.
BTW, it would be great to be able to do a PCB rev and use the 8245 instead.

Cheers, Ron


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