Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: Dev lib off-board register access
From: Eric Bjorklund <bjorklund@lanl.gov>
To: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 14 Jul 2006 09:49:38 -0600
Hi Kate,

On Jul 14, 2006, at 7:45 AM, Kate Feng wrote:

Eric Bjorklund wrote:

.

In my experience I have usually been able to always get non-DMA drivers to work by always declaring the register pointer as "volatile" (which is more to defeat compiler optimization and not really a caching issue) and following the last write with a dummy read to the same register (to flush the pipeline).

Do you mean the dummy read following the last write is needed for
only vxWorks-mvme5500 ? Or is it needed for almost all the powrPC
boards using VxWorks ? Does it apply to all the VME boards ?


This is pretty much the case for any PPC using the Universe or Tempe VME bridge. But my statement wasn't quite complete. As Andrew pointed out, write posting ("pipeline") is mostly a problem with ISR's issuing a write to clear the IRQ line and the write not actually happening until after the ISR returns (as Andrew also pointed out, the dummy read does not really have to be to the same register). So if your VME board doesn't interrupt, you probably don't need to worry about it.

At NSLS, we use RTEMS-MVME5500 BSP that I developed, which
enables the hardware cache snoop on CPU local memory for all the
DMA applications so that the sofware caching is not needed yet.
However, the VME space is marked as Non-Cacheable and
Guarded in the BSP.


I believe it is hardware caching that we've been talking about. The "software" part refers to system routines in vxWorks (and probably in RTEMS too) that talk to the MMU to either invalid or flush the hardware cache (depending on whether your DMA is reading or writing). These routines are, of necessity, system-dependent, and it would be nice to have devLib implementations so that DMA device drivers could be more portable.

-Eric Bj.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Eric Björklund
Los Alamos Neutron Science Center (LANSCE)

phone: 505-667-6031 email: bjo@lanl.gov
<><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Correspondence


Replies:
Re: Dev lib off-board register access Jukka Pietarinen
Re: Dev lib off-board register access Andrew Johnson
References:
Dev lib off-board register access Rees, NP (Nick)
Re: Dev lib off-board register access Dirk Zimoch
Re: Dev lib off-board register access Eric Bjorklund
Re: Dev lib off-board register access Kate Feng

Navigate by Date:
Prev: Re: Dev lib off-board register access Andrew Johnson
Next: Re: Dev lib off-board register access Jukka Pietarinen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: Dev lib off-board register access Kate Feng
Next: Re: Dev lib off-board register access Jukka Pietarinen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·