Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Thu, 8 Dec 2022 13:32:42 -0800

On 12/8/22 08:00, Perez Juarez, Emilio (DLSLtd,RAL,LSCI) wrote:

Hi Michael and thanks for the information,

I had a quick look at your support module, and it seems generally useful, is there a reason why devlib2 is not part of EPICS base?

There is a long standing preference not to including specific
HW drivers in the epics-base repository which precedes my
involvement by many years.  (and which I mostly agree with*)

So the real question for me is why devLib (the original) is still
part of Base?

In truth I don't have a good answer other than our policy of
avoiding breaking API changes when at all possible.  The code
in Base works as well as it ever has.  Removing it in favor of
the devlib2 module seems likely to break some downstream code
without a significant benefit.  (reduced confusion?)

* I do think some of the soft support modules like autosave and
  caputlog should be part of Base.  But this is a different
  discussion.

Kind Regards,
Emilio
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*From:* Michael Davidsaver <mdavidsaver at gmail.com>
*Sent:* 06 December 2022 19:28
*To:* Perez Juarez, Emilio (DLSLtd,RAL,LSCI) <emilio.perez-juarez at diamond.ac.uk>; Wang, Lin <wanglin at ihep.ac.cn>
*Cc:* tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
*Subject:* Re: A simple EPICS driver example for PCI devices using asynPortDriver on Linux
On 12/4/22 02:39, Perez Juarez, Emilio (DLSLtd, RAL, LSCI) via Tech-talk wrote:

Hi Lin Wang and thanks for sharing,

I have some comments/questions:

   * Is there a reason why you prefer to use ioctl for register access instead of mmap and letting userspace access directly?
   * I know security is usually not a priority, but I've noticed you don't check/validate the register offset passed in the ioctl syscall, which means it could give access to other resources (memory or I/O)
   * You might want to provide a fallback path when the target system doesn't have your kernel module installed, in which case, you can get register access by mmap'ing /sys/bus/pci/devices/<X>/resource<Y>, where <X> is the domain:bus:devices.function of your  device and <Y> is the BAR number you want to access
   * I noticed you dereference a volatile pointer to access the registers, in kernel space I'd recommend using the functions ioread<X> or iowrite<X> instead, where <X> is the access size (8, 16 or 32). This will make code more portable.

Sorry, I didn't notice this thread sooner.

My devlib2 support module does just what is described, and is portable
across Linux, RTEMS, and vxWorks.

https://epics.sourceforge.net/devlib2/ <https://epics.sourceforge.net/devlib2/>

https://github.com/epics-modules/devlib2 <https://github.com/epics-modules/devlib2>

This includes device support for simple register operations.

https://epics.sourceforge.net/devlib2/exploreapp.html <https://epics.sourceforge.net/devlib2/exploreapp.html>

No DMA support, but there is limited support for interrupts if a
device supports the standard INTx Disable bit in the PCI_CONFIG
register (not to be assumed).

https://epics.sourceforge.net/devlib2/exploreapp.html#exploreirq <https://epics.sourceforge.net/devlib2/exploreapp.html#exploreirq>

I hope any of that was useful,

Kind Regards,
Emilio

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*From:* Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wang, Lin via Tech-talk <tech-talk at aps.anl.gov>
*Sent:* 02 December 2022 10:15
*To:* tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
*Subject:* A simple EPICS driver example for PCI devices using asynPortDriver on Linux

Dear all,

A simple EPICS driver example for PCI devices using asynPortDriver on Linux is shared in the following GitHub link in case somebody might be interested,

https://github.com/wanglin86769/cpciEpicsApp <https://github.com/wanglin86769/cpciEpicsApp>

This is an EPICS IOC developed for the LLRF system of a small-scale accelerator facility at CSNS campus. The LLRF board is a customized cPCI FPGA board with PCI 9056 bridge, the control interface is merely register access plus waveform read with 1 second  update period, no interrupt or DMA is needed.

The Linux driver part is implemented as kernel module rather than UIO (Userspace I/O). This example is only useful for simple customized PCI devices that does not need interrupt and DMA, and only one MMIO (Memory mapped I/O) BAR is used to access the FPGA  registers.

This is my first assignment to control PCI under Linux rather than vxWorks, any suggestion is appreciated.

Regards,

Lin Wang

Staff Engineer

Controls Group, Accelerator System Division, CSNS (China Spallation Neutron Source)

IHEP (Institute of High Energy Physics), Chinese Academy of Science

--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt  by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System