Dma Error Vxworks
how to migrate your module libraries and programs from the vxWorks operating system to the Linux operating system. We will assume that the use of the Intel-Based VME controller will be for taking data with CODA, or parallel with CODA. Contents 1 Basic differences with respect to VME access 1.1 Access to VME address spaces 1.1.1 Example: Acquiring Virtual Memory address of a VME module 1.2 Routine changes 1.3 Little-endian vs Big-endian 1.3.1 Example: Reading and Writing with "correct" byte swapping 2 DMA (Block Transfers) 2.1 Performing the transfer 2.2 Do something with the vmeOUT queue 2.3 Queue cleanup 2.4 Different types of VME DMA 3 Library/Application Modifications 3.1 Header Files 4 Changes to Makefile 5 Running the CODA Linux ROC 5.1 Example: Linux ROC execution Basic differences with respect to VME access Access to VME address spaces In vxWorks, the VME windows (the map between various VME address spaces and PCI space) is created at boot. In Linux, this is done at program execution with the routine: int vmeOpenDefaultWindows(); This routine does the following Opens the device file to the VME kernel driver /dev/vme_ctl Opens default VME windows to PCI space. Maps those PCI space windows to Virtual Memory (available to current process) Maps VME bridge registers to Virtual Memory Creates a Shared Mutex for locking access to the VME Bus (if not already created). Because virtual memory is allocated, the programs must make a call to int vmeCloseDefaultWindows(); to release this memory before it exits. The VME windows to PCI space will always remain open after the first call to vmeOpenDefaultWindows(). What will change, is the map of this PCI memory to Virtual Memory for each executed process. Example: Acquiring Virtual Memory address of a VME module After vmeOpenDefaultWindows() has been successfully called, one can gain access to a VME module's registers with int vmeBusToLocalAdrs(int vmeAdrsSpace, char *vmeBusAdrs, char **pLocalAdrs); I have a VME TIR device that responds to A16 (Address Modifier = 0x29) at VME address 0x0ed0. To get its Virtual Memory address: unsigned int vmeAdr = 0x0ed0;
unsigned int lAdr;
int stat; stat = vmeBusToLocalAdrs(0x29,(char *)vmeAddr,(char **)&lAdr); if (stat != 0) {
printf("tirInit: ERROR: Error in vmeBusToLocalAdrs res=%d \n",stat);
}
else
{
printf("TIR VME (USER) address = 0x%.8x (0x%.8x)\n",vmeAdr,lAdr);
} Here... USER address refers to the Virtual Memory address of the TIR that is available to the User Process. This is very similar to what is done to get a local address from the VME address, in vxWorks. Routine changes
- disable the specified cache cacheLock() - lock all or part of a specified cache cacheUnlock() - unlock all or part of a specified cache cacheFlush() - flush all or some of a specified cache cacheInvalidate() - invalidate all or some of a specified cache cacheClear() - clear all or some entries from a cache cachePipeFlush() - flush processor write buffers to memory cacheTextUpdate() - synchronize the instruction and data caches cacheDmaMalloc() - allocate a cache-safe buffer for DMA devices and drivers cacheDmaFree() - free the buffer acquired with cacheDmaMalloc() cacheDrvFlush() - flush the data https://coda.jlab.org/drupal/content/vxworks-linux-howto cache for drivers cacheDrvInvalidate() - invalidate data cache for drivers cacheDrvVirtToPhys() - translate a virtual address for drivers cacheDrvPhysToVirt() - translate a physical address for drivers DESCRIPTION This library provides architecture-independent routines for managing the instruction and data caches. Architecture-dependent routines are documented in the architecture-specific libraries. The cache library is initialized by cacheLibInit() in usrInit(). The cacheLibInit() routine typically calls an http://www.vxdev.com/docs/vx55man/vxworks/ref/cacheLib.html architecture-specific initialization routine in one of the architecture-specific libraries. The initialization routine places the cache in a known and quiescent state, ready for use, but not yet enabled. Cache devices are enabled and disabled by calls to cacheEnable() and cacheDisable(), respectively. The structure CACHE_LIB in cacheLib.h provides a function pointer that allows for the installation of different cache implementations in an architecture-independent manner. If the processor family allows more than one cache implementation, the board support package (BSP) must select the appropriate cache library using the function pointer sysCacheLibInit. The cacheLibInit() routine calls the initialization function attached to sysCacheLibInit to perform the actual CACHE_LIB function pointer initialization (see cacheLib.h). Note that sysCacheLibInit must be initialized when declared; it need not exist for architectures with a single cache design. Systems without caches have all NULL pointers in the CACHE_LIB structure. For systems with bus snooping, NULLifying the flush and invalidate function pointers in sysHwInit() improves overall system and driver performance. Function pointers also provide a way to supplement the cache library or attach user-defined cache functions for managing secondary cache systems. Parameters specified by cacheLibInit() are us
2009 2008 2007 2006 2005 2004 2003 2002 2001 2000 1999 1998 1997 1996 1995 1994 Core-talk Mailman Search 2016 QTi-talk Mailman Search 2016 http://www.aps.anl.gov/epics/tech-talk/2012/msg00207.php Hw-talk Mailman Search 2016 Bugs Documents Links Licensing Format page for printing SearchTech-talk 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 Index 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 dma error 2015 2016 <== Date ==> <== Thread ==> Subject: RE: errors in vxWorks-6.9/target/h(eader) files when building base 3.14.12.1 From: Mark Rivers