January 23, 1998
Overview
Versions 3.1.0 and 3.1.1 of the VME6U6 / VME9U12 host software includes the following changes:
Solaris Device Driver Modifications
Minor modifications were made to the Solaris version of the VME6U6/VME9U12 device driver for compiling under Solaris 2.6. The changes involved using Solaris version dependent macros defining the functions and data type declarations for probing the boards when the driver and devices are loaded during system boot up.
Currently, at the time of this writing, the VME6U6/VME9U12 software and drivers have been tested under Solaris 2.6 only on Force CPU-5V and CPU-8VT Sparc boards, with Force Computer's VME device driver version 2.2.1.
New ioctl requests provide the physical VME addresses for the board or resource. DSP_VMEBRDADDR returns the VME base address for the VME6U6 or VME9U12 board on which the open resource resides and DSP_VMERESADDR returns the VME base address for the open resource, itself. For example:
unsigned int resource_addr, board_addr;
DSP_CHIP *dsp1, *dsp2;
/*
* Determine addresses for dsp0a:
*
* Note that both addresses will be the same since the
* address space for DSPA on any board starts at the
* board's base address.
*/
dsp1 = dspopen ("dsp0a") ;
(void) ioctl (dsp1->fd, DSP_VMEBRDADDR, &board_addr) ;
(void) ioctl (dsp1->fd, DSP_VMERESADDR, &resource_addr) ;
/*
* Determine addresses for dsp0b:
*
* In this case, the value or resource_addr will be
* 0x2000 greater than the value of board_addr.
*/
dsp2 = dspopen ("dsp0b") ;
(void) ioctl (dsp2->fd, DSP_VMEBRDADDR, &board_addr) ;
(void) ioctl (dsp2->fd, DSP_VMERESADDR, &resource_addr) ;
Note: Under Solaris 2.4 and previous versions of Solaris,
the VME6U6/VME9U12 library includes implementations of
the usleep and ualarm functions which were not
included in the C library.
Under Solaris 2.5 and higher, these routines are not included
in the library.
Therefore, binaries of the VME6U6/VME9U12 library compiled under
Solaris 2.5 or higher cannot be copied and used on earlier versions of Solaris.
SunOS Device Driver Modifications
Note: when using the single major device option, the maximum number of boards that can be configured in the system is 14. This is due to the number of minor devices required by the device driver and the SunOS limit of 256 minor devices per major device.
Configuring to device driver and system with or without the single major device option is described below.
dspdrv_options.h
/* * Define DSP_SINGLE_MAJOR to install using a single * major number for all the DSP VME6U6/VME9U12 boards. * #define DSP_SINGLE_MAJOR */To enable the single major device option, move the macro definition to be outside the comment:
/* * Define DSP_SINGLE_MAJOR to install using a single * major number for all the DSP VME6U6/VME9U12 boards. * */ #define DSP_SINGLE_MAJOR
/usr/kvm/sys/sun/conf.c
The file, $CAC/dsp/dspsundev/example.conf.c, includes example entries for the VME6U6/VME9U12 device driver with and without the single major device option.
Note that when DSP_SINGLE_MAJOR is enabled only one entry in the cdevsw table is used for all VME6U6/VME9U12 boards. When DSP_SINGLE_MAJOR not enabled, there must be an entry in cdevsw for each board and you must take note of their indexes in the table.
/usr/kvm/sys/arch/conf/kernel-name
The file, $CAC/dsp/dspsundev/example.config_file, includes example entries for VME6U6/VME9U12 boards with and without the single major device option.
Note that when DSP_SINGLE_MAJOR is not enabled each entry includes the flag keyword with the board's major device number as the flag value.
makedspdev
When using the single major device option, run the makedspdev program telling it how many boards are in the system and the major device number for all the boards. In the following example there are 3 VME6U6 or VME9U12 boards and their major device number (from the index of the driver's entry points in cdevsw) is 110.
makedspdev 3 110
When not using the single major device option, makedspdev must be run for each board in the system, telling it the primary device name (dsp0, dsp1, etc.) and its major device number. In the following example there are 3 VME6U6 or VME9U12 boards and their major device numbers (from their indices of the driver's entry points in cdevsw) are 110, 111, 112.
makedspdev dsp0 110
makedspdev dsp1 111
makedspdev dsp2 112
In all cases makedspdev will ask you to confirm the actions.
This pathname may still be overridden by adding the full pathname of the dspinit program and its command line arguments to the exec line in $CAC/dsp/dspdgdev/dsprc.sh, prior to installation, or in /usr/sbin/init.d/rc.cacdsp, after the installation has been done.
VME6U6 requirements for this capability are:
Current host system requirements:
Support for this capability will eventually be provided for processor boards. Please note that because the access to the DMA controller is hardware and operating system dependent, binary files compiled on one system type may not be copied to a system of another type.
Data transfers are performed on arrays of 32-bit words. The array should be allocated aligned on a page boundary (4096). The actual required alignment may vary on different host systems but a value of 4096 should be safe for any system. Memory can be allocated on a specific alignment using the memalign. system function. For example:
u_long *data = (u_long *) memalign(4096, num_bytes) ;
The transfers are done by accessing a special address range within the VME6U6's VME address space and by enabling a special transfer mode on the VME6U6. This initialization is performed by the fdsp_hostdma_setup function, described below. The VME6U6 hardware can handle individual transfers of up to 8K words (32,768 bytes), within its special VME address range. The library functions break up larger arrays into blocks of 8,192 words passing each block to the CPU's DMA controller.
Performing host-driven DMA transfers is done using the following functions in the VME6U6 Software Support Library.
int
fdsp_hostdma_setup (dmainfo, dsp)
void
fdsp_hostdma_release(dmainfo, dsp)
struct dsp_hostdma_info *dmainfo
DSP_CHIP *dsp - pointer to open DSP resource
The fdsp_hostdma_setup function must be called prior to calling
the host-dma transfer functions.
Following a successful setup, the transfer functions may be called
any number of times.
fdsp_hostdma_setup intializes information in the dsp_hostdma_info structure pointed to by dmainfo. A pointer to this same structure is then passed to the other hostdma functions that are to use the same DSP resource.
fdsp_hostdma_setup returns 1 when successful. It returns 0 if an error is detected. Errno is set to ENODEV if the host system does not support host-driven DMA.
Note: the initialization stored in the dsp_hostdma_info structure by fdsp_hostdma_setup are only valid for the DSP resource and board referenced by the dsp argument. An application may declare multiple dsp_hostdma_info structures to store information for different VME6U6 boards. However, each VME6U6 board may only have one DSP resrouce set up for host dma at a time.
The fdsp_hostdma_release function disables the host dma transfer mode and erases the information stored in the dmainfo structure. It is necessary to call fdsp_hostdma_release function before making additional calls to fdsp_hostdma_setup to perform DMA transfers with another DSP resource on the same VME6U6 board.
fdsp_dl_hostdma and fdsp_up_hostdma are the functions that perform the data transfers.
int
fdsp_dl_hostdma (dmainfo, dsp, dspadr, nwords, buf)
int
fdsp_up_hostdma (dmainfo, dsp, dspadr, nwords, buf)
struct dsp_hostdma_info *dmainfo
DSP_CHIP *dsp - pointer to open DSP resource
u_long dspadr - DSP memory address
u_long nwords - number of 32-bit words to transfer
u_long *buf - pointer to data buffer on the host
(page aligned)
The fdsp_dl_hostdma function transfers nwords (32-bit words)
of data from the array buf on the host
to the memory starting at dspadr on the VME6U6 board.
The fdsp_up_hostdma function transfers nwords (32-bit words)
of data from the memory starting at dspadr on the VME6U6 board
to the array, buf on the host.
The dsp_hostdma_info structure passed must have been previously initialized with fdsp_hostdma_setup for the same DSP resource.
Both functions return 1 for a successful transfer.
If an error is detected or if fdsp_hostdma_setup was not
called or failed, they return 0.
Ioctl Request to Determine Device Driver Version
The version number is returned as an integer whos value is 100 times the value of the major version plus the value of the minor version. For example, if the device driver version is 2.12 then the DSP_DRVRVERSION ioctl returns a value of 212.
The dsptest program supports the DSP_DRVRVERSION ioctl using the command:
dsp0a> ioctl 88
Below is an example of how to use the ioctl request in an application.
int version;
DSP_CHIP *dsp;
dsp = dspopen ("dsp0a") ;
version = 0; /* initialize version */
(void) ioctl (dsp->fd, DSP_DRVRVERSION, &version) ;
if (version == 0)
/* ioctl failed, the driver is an older than the
* first version that supports DSP_DRVRVERSION
*/
printf ("Device driver is old version\n");
else
printf ("Device driver version is %d.%d\n",
version / 100, version % 100) ;
Note that if the ioctl call fails,
because the installed driver does not include the DSP_DRVRVERSION request,
the initialized value of version is untouched.
C12API Software Interface for C12 Mezzanine
The C12API consists of a library of C functions for the host application to call, a DSP32C program buffering data between host and codecs, and a host program (run as a child process) handling DSP data transfers. The C12API uses one DSP on the baseboard and TDM BUS A to transfer serial data between the DSP and the codecs on the C12 mezzanine.
Detailed documentation is available in the updated C12 Mezzanine User Manual, c12mezz.doc.
Diagnostic Program Modifications
piomemdma