PowerPC Burst PCI access

[Kate Feng]

Peter Dufault wrote:

> On Apr 7, 2005, at 11:23 PM, Feng, Shuchen wrote:
>
> > Hi Peter,
> >
> > The whole 512MB of memory on the mvme5500 is cachable.  The 1GHZ NIC
> > is on the PCI.  It's performance is slightly higher than that of the
> > vxWorks at this point even though I think a patch in the RTEMS might
> > even make it higher. If anyone is interested in the data, I will
> > post it.
> >
> >
> > The mvme5500 has eight DMAs, more than enough.
>
> Are these on the GT64260?  Can you point to an interface to get at them?

There are 33 pages  in the documnet that I think  one should  read
through it,  including each bit defintions, to implement  the DMA.


>
> >
> >
> > I do not think you updated your PCI to the unified PCI yet.
>
> I have not, this weekend I will.
>
> > If so, can you do PCIx_read_config_dword(1,0,10,0, offset, &data)
> > by setting  offset from 0 to 0x40 at an interval of 4 ?
> > For example :
> > PCIx_read_config_dword(1,0,10,0,0, &data)
> > PCIx_read_config_dword(1,0,10,0,4, &data)
> > ...
> > ...
> > PCIx_read_config_dword(1,0,10,0,0x40, &data)
> >
> >
> > What is all the returned value ?
> > Also what does inl(0xc00) and  inl(0xc80)
> > return ?
>
> Do you mean "If so" or "If not"?  I assume you mean "If not", since I
> thought the "PCIx_*" functions were going away.
>

The old version  allows one to use  PCIx_read_config_dwords()
dynamically via cexp.   With the unified PCI (and old one), you can write
test routines or  do as what Till  Straumann wrote :
> cexp> long (*pci_rcw)()
> cexp> pci_rcw = *((long*)&pci_indirect_functions + 1)
> cexp> pci_rcw(8,10,0,0,&device_id)

>
> Anyway, I'll look later today when I'm at my client and email to you
> privately.

One more,  the value of inl(0x1f00), please.
In general, if you need to transfer large number of bytes (e.g.
perhaps > 256 bytes , depending on the system), DMA will help,
the larger the  better.  For  smaller number  of bytes (e.g. <64 bytes,
depending on the system), prefecth  might help.

>
> >
> >
> > To digress a moment, is the code you wrote for
> > PMCspan sharable by the RTEMS community ?
> >
>
> Yes and maybe - in general, the PMCSPAN will work as long as the bus
> counting is OK and the DEC controller is recognized.

The code you wrote for PMCspan should be part of shared code
for some PPC boards (e.g. mvme2307 besides mvme5500).
I might need it pretty soon, such as two weeks ago.


Till Straumann had kindly sent me the driver for his faster
ADCs,  except  we need a faster ADCs at the  xMHZ sampling rate.
The only concern is $$.


> This weekend I'll
> take your new release and if it doesn't work make it work and send the
> changes back to you.  The PMC drivers for the two Acromag boards are
> still being thought over by the client but I think they'll agree to
> release them.  A big warning in advance to anyone hoping to use them: I
> only added exactly what I needed and no more.  For example, you can
> only read either 8 or 16 channels and in order - I didn't add any
> general purpose code.  It is still better than starting from scratch,
> though.
>

Please do'nt worry about sending me codes for the ADCs.


Regards,
Kate