PowerPC Burst PCI access
feng1 at bnl.gov
Fri Apr 8 13:25:31 UTC 2005
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
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,
Please do'nt worry about sending me codes for the ADCs.
More information about the users