PCI caching question related to mvme5500

Till Straumann 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
      pagetables)
   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.


T.
>  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.
> 
> Peter
> 




More information about the users mailing list