OSI and Architecture Independent Device Driver Jim Chen HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source

The problem Things in common The solution Exceptions and caveats Conclusions HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source Contents

Since introducing of asyn, EPICS device support actually becomes device driver Asyn takes over the interfaces with records – the device support layer Asyn standardize the interfaces to generic data type Device driver only focuses on hardware access and controls HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source EPICS Device Support to “Device Driver” ---- Much easier!

VxWorks What’s the Problem HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source RTEMS LinuxWindows FreeBSD DarwinSolaris …… The operating systems: The architectures: VME ATCA/uTCA PCI/PCIe/cPCI/PXI C ConCon o D Standalone via TCP/IP Cubie board Raspberry PI EtherCat BUS cPCI IOC9010 PCIe6335 uTCA7003 VME8004 FPGA IOC8800 The processors (with different BSP or device driver): PPC (MVMExxxx) Intel (Concurrent/Tews/Acromag) PMC ARM……

For a single ADC for example HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source C ConCon o D uTCAVMEcPCI … Standalone IOC9010 IOC8800 Linux PPCIntel … ConcurrentKontron … EurotechAdvantech … PC104 Raspberry PI /Cubie Board The BSP or processor device driver could be totally different Some have kernel-user space like Linux, Windows. Some just have one space – VxWorks, RTEMS VME architecture has AM code plus addr/data bit and even CR/CSR etc whereas PCI doesn’t

VxWorks Multiply by Different OS HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source RTEMS LinuxWindows FreeBSD DarwinSolaris …… PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel PPCIntel How about DAC, Scaler, Digital, SIO, Step motor, Timing modules, frame grabber….. (An exaggerated figure)

Hold on – we’ve got OSI model HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source OSI model – Operating System Independent. It takes over the operating dependant calls (interrupt, mutex, event, message queue, signals, thread, math etc etc) Yet down to the device driver level, we still face architecture differences and processor specific BSP/kernel driver differences

Things in Common HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source Register access For all I/O moduels such as ADC, DAC, Scaler, Digital, SIO, Step motor, Timing modules, frame grabber etc devices…. Most processors use PCI/PCIe to bridge the other side, implemented by Universe II/Tsi148/Plx chips Memory access Interrupt management DMA or BLT or MBLT

The (my) solution – ipac + arch specific HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source BSP or kernel device driver mmap/sysBustoLocal connectInterrupt/waitInterrupt dmaInit/dmaRequest Utilise Andrew Johnson’s ipac module + arch specific interface to BSP/kernel device driver What ipac provides: Generic base addresses mapping ipmBaseAddr Generic interrupt management ipmIrqCmd ipmIntConnect This applies to both carrier card case and normal modules as well (see examples) The only thing ipac doesn’t have is DMA support at the moment Standard ipac/asyn interfaces Arch specific Interface EPICS device driver BSP/kernel driver

Example 1 -- Carrier Card + IP HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source C ConCon o D VME 8004 PCIe 6335 uTCA 7002 uTCA 7003 Standalone IOC9010 PC104 IOC8800 Cubie board /Raspberry PI BUS IPs ADC DAC SCALER

Example 1 -- Carrier Card + IP HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source Ipac-2.11 drvHy8002.c drvTip810.c drvXy9660.c …… Linux VME Intel Concurrent VxWorks/RTEMS RTEMS VME PPC EPICS Device Driver cct Kernel Driver + API Intel PCI/PCIe Linux PCI/PCIe Intel drvHyRTEMSCarrier.c drvHy8002Concurrent.c drvHyLinuxCarrier.c devLib devLib2 Hytec Kernel Driver + API Device

Example 2 – Micro Research Timing Module HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source VME cPCI PMC PXI cRIO …… They have the nearly identical (at least to now) register/memory configuration They have similar interrupt scheme MRF provides a generic API function set for Linux, based on memory pointer! With the arch specific interface module in place, we can use this generic API for all

Example 2 – Micro Research Timing Module HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source Ipac-2.11 Linux VME Intel EPICS Device Driver Kernel Driver + API Linux cPCI Intel drvMrfcPCIcct.c VxWorks/RTEMS drvMrfVMEPPC.c VME PPC drvMrfVMEcct.c …… Kernel Driver + API With CR/CSR support devLib Device

Exceptions and Caveats HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source mmap – not all OS support Byte swap – endian problem. Not all processor boards support it. Then need be32_to_cpu etc. Serial port, Ethernet. This needs device driver. Can be done by this model. Standalone unit, like Raspberry PI/Cubieboard IOC8800, the interface cound be SPI or just I/O operations. We might be able to utilise the macro: be32_to_cpu – developing.. DMA support – no common support in EPICS by far. Maybe a generic dmaInit, dmaRequest in ipac plus drvXXX.c?

Conclusion HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source EPICS Device driver to hardware has common operations such as register, memory access, interrupt management and DMA operations The ipac module happens to provide these services in standard interfaces. We can utilise ipac plus OS/Arch specific module to mezzanine the OS/ARCH specific which hides the complex operations. And it gives a common EPICS device driver for I/O peripherals – easy to maintain. Discussion Is this the right place? A DMA interface? --- leave these to the core developers

Thank You! HYTEC ELECTRONICS LIMITED Spring 2013 – Diamond Light Source