EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Dev lib off-board register access
From: Dirk Zimoch <[email protected]>
To: "Rees, NP \(Nick\)" <[email protected]>
Cc: [email protected]
Date: Thu, 13 Jul 2006 15:34:33 +0200
Hi Nick,

at least on MV2300 and MV5100, caching is disabled for VME access anyway. You should only need to care about cache if using DMA.

Flushing the processor and bus pipelines is something different as far as I understand the problem. Calling cacheFlush probably just gives the system some time process the write and calling printf instead might have the same effect. The BSP (see sysLib.c and sysALib.s) often uses the assembler instructions eieio and sync after register access.

Maybe using the BSP functions sysOutByte() and friends is the only correct way to access external registers? But I don't know if those functions are implemented on all board architectures or what they are called on other operating systems.

Unfortunately I am not familiar enough with the PPC architecture to know what eieio and sync really do and what instructions to use on other processors.

Dirk

Rees, NP (Nick) wrote:
This is really a follow-up to the 2002 thread on PowerPC caching:

http://www.aps.anl.gov/epics/tech-talk/2002/msg00417.php

At Diamond we use the mvme5500. It seems that every vxWorks driver we
have will fall over at some point unless we are careful with memory
caching. Very few EPICS drivers do this properly. However, on the
mvme5500 if we precede every read with a cacheInvalidate and follow
every write routine with a cacheFlush we don't seem to have any
problems.

We have rapidly come to the conclusion that we need to have a set of
routines in devLib to handle register accesses. The two models we am
aware of is the Linux memory barrier routines, and vxWorks cacheLib
routines. I don't know about RTEMS or Windows. The Linux routines are
simpler than the vxWorks ones, but if we adopted that model we could
only implement it in vxWorks with asm directives since the Linux calls
are incompatible with cacheLib.

At the same time I suggest we should handle big/little endian issues as
well as caching. The routines of course know whether the processor CPU
is big or little endian, but they need to be told about the endian-ness
of the card they are reading or writing to.

So I suggest, as a minimum:

devGetBigEndianRegisters( volatile void * from, void * to, size_t nobj,
size_t size );
devSetBigEndianRegisters( void * from, volatile void * to, size_t nobj,
size_t size );

devGetLittleEndianRegisters( volatile void * from, void * to, size_t
nobj, size_t size );
devSetLittleEndianRegisters( void * from, volatile void * to, size_t
nobj, size_t size );

The get routines would call cacheInvalidate on vxWorks or rmb on Linux
and then read the data as nobj chunks of the given size. They would
byteswap if necessary.

The set routines would byteswap, write and then call cacheFlush on
vxWorks or wmb on Linux. If the cacheLib routines don't appear to work
on vxWorks for a particular architecture, then a read of the last data
element written might be added for that architecture (as outlined in the
above thread).

What do people think? Is this the right interface or are there other
suggestions?

I am prepared to do this for Linux and VxWorks, but I don't have access
to the other architectures. Would others be willing to take this up?

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713


-- Dr. Dirk Zimoch Swiss Light Source Paul Scherrer Institut Computing and Controls phone +41 56 310 5182 fax +41 56 310 4413

Replies:
RE: Dev lib off-board register access Rees, NP (Nick)
Re: Dev lib off-board register access Eric Bjorklund
References:
Dev lib off-board register access Rees, NP (Nick)

Navigate by Date:
Prev: Dev lib off-board register access Rees, NP (Nick)
Next: RE: Dev lib off-board register access Rees, NP (Nick)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Dev lib off-board register access Rees, NP (Nick)
Next: RE: Dev lib off-board register access Rees, NP (Nick)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·