PCI caching question related to mvme5500
strauman at slac.stanford.edu
Tue Nov 1 19:50:25 UTC 2005
Peter Dufault wrote:
> I'm merging the local changes I have in mvme5500 into cvs and then I'll
> submit them via the bug reporting mechanism. While doing this I want
> to do things more properly. This has to do with accessing a PCI card's
> memory through a cached region.
> To get decent throughput on the PCI data acquisition card (Acromag
> PMC341) I had to read it through a cached address. To do this I used a
> BAT register to create a second mapping onto the PCI bus that was
> cached. I did this by adding a fixed PCI1_MEM_CACHED address to
> libbsp/powerpc/mvme5500/include/bsp.h, setting up a BAT register, and
> accessing it through that.
> Much later when porting to vxWorks and again having it slow I realized
> that the board does not properly say that its memory is pre- fetchable.
> After poking around I figured out how to hook it up to vxWorks as if it
> had said it was cached.
> So, two questions:
> 1. If the board properly said it was pre-fetchable would RTEMS have
> accessed a different mapping so things would have worked through a
> cached mapping?
No. Currently, PCI memory space is mapped through a BAT as
cache-inhibited/guarded. Supporting pre-fetchable memory on
PCI devices would require
a) setting up a second mapping marked as cacheable (BAT or
b) reconfiguring all cacheable devices to use addresses
mapped by a)
c) resolving coherency issues [probably the hardest]
Regarding b), note that it is potentially dangerous to
simply map the same physical address range twice, i.e.,
both, caching-inhibited and caching-allowed.
> If so I'll change it to do that. If not, on to
> question 2.
> 2. Is there a better way that my PCI1_MEM_CACHED hack that won't take
> too much time to implement? I don't have the time to do much but I can
> at least put comments in the code around any hacks I have to leave in.
More information about the users