This document describes how to install the Channelization API software package on Solaris Sparc and Intel Platforms and Linux Intel x86 Platforms. Other operating systems and host platforms are not currently supported.

The software package includes device drivers, API, and support and diagnostic programs for Communication Automation Corporation's (CAC) DPL3, LightParser, LightParser2 and LightParser2e boards. The software source code supports all three types of boards. However, the driver, API and programs are configured and compiled to support a single board type (except for LightParser2 and LightParser2e, which are both supported by the same device driver and software build). It is possible to configure separate instances of the software to support both board types on the same system. However, at this time the libraries for more than one board type cannot be linked in to the same application.

The sotware (device drivers, API and programs) supports Solaris 8 through Solaris 9 on Intel/AMD (x86) and up through Solaris 10 on Sparc platforms. Linux kernels 2.4 and 2.6 are supported on Intel x86. Linux on Intel ia64 platforms (e.g. SGI Altix) is supported to a limited extent for DPL3 boards. LightParser and LightParser2/2e boards are not currently compatible with the Altix system architecture.

An installation tool from the GNU Project (www.gnu.org) is used to configure the software for a particular target environment.

Specific, step-by-step instructions are provided below in the following sections:

1. Install the Board or Boards
2. Download and Extract the Software Distribution
3. Configure the Software
     3a. Choose the Installation Directory
     3b. Choose the Build Directory
     3c. Configuration Options
     3d. Notes on 64-bit Compatibility
4. Compile and Install the Software
5. Compile and Install the Device Driver
     5a. Solaris Device Driver
     5b. Linux Device Driver
     5c. Cross-Building the Device Driver
6. Update FPGA Configurations
7. Initializing Boards
8. On-Line API Reference

 

1. Install the Board or Boards

The software installation instructions that follow assume that you have already installed the boards in your computer. The software may be installed prior to installing the hardware but warning or error messages will be issued during the device driver installation.

Install your board(s) in appropriate PCI slots of your computer. The system will identify the boards based on which slots they located in. If you installing more than one board, the board found closest to the CPU will be recognized as instance 0 and the others will be numbered in order. The ordering may vary depending on PCI bus slot ordering.

Device entries for the boards are located in the /dev directory once the device driver is installed. The entries are named for the board types and instances. Device entries for DPL3 boards are named "dpl0", "dpl1", etc. Device entries for LightParser boards are named "dplp0", "dplp1", etc. Device entries for LightParser2 and LightParser2e boards are named "dplt0", "dplt1", etc.

Solaris systems save the device information for each board when the device driver is installed and when new boards are added to the system. The boards will retain their designations based on the slot they are in. If a board is moved to a new slot it will be given a new designation. For example, if a DPL3 board originally installed in slot1 and named "dpl0" is moved to the adjacent slot, its new designation will be "dpl1". The system will still have a record for a "dpl0" even though the device is no longer installed. It is recommended that the boards not be relocated after the initial installation to avoid confusion.

On Linux systems the boards will always be designated in the order they are found by the system, with the first found being named "dpl0" or "dplp0".

2. Download (if necessary) and Extract the Software Distribution

The software distributions for Solaris and Linux are available for downloading from the CAC Software Site or on CDROM.

If you are downloading the software package from our WEB site, you will be downloading a tar-format archive compressed using the GNU gzip program. The file name of the package is in the form: chanapi-version.tar.gz where version denotes the version number of the software release (e.g. chanapi-1.2.3.tar.gz).

An additional archive provides an on-line reference manual for the API in HTML format. This archive is named chanapi-ref-version.tar.gz. See below for details on how to unpack and use the documentation.

The program to uncompress the archives, gunzip, is included with distributions of Linux and recent versions of Solaris. It is available for older Solaris versions from several software sites including Sunfreeware.com.

To unpack the downloaded version of the software distribution, create a local directory and place the archive file there. Then run the gunzip and tar programs as shown:

    # mkdir /usr/cac
    # cd /usr/cac
    # (download the software distribution to here)
    # gunzip -c chanapi-version.tar.gz | tar xvf -

If you are receiving the software on the CDROM there is no need to download any additional software. Load the CDROM and you can find the software packaged in tar format in the unix directory of the CDROM named: chanapi-version.tar where version denotes the version number of the software release (e.g. chanapi-1.2.3.tar).

You can unpack the software onto your system by creating a local directory, cd'ing into it and running the tar program. For example:

    # mkdir /usr/cac
    # cd /usr/cac
    # tar xvf /cdrom/unix/chanapi-version.tar

The resulting, unpacked software distribution is placed in a directory named chanapi-version where version denotes the version number of the software release. For example:

/usr/cac/chanapi-1.2.3.

An unpacked copy of the distribution is also available on the CDROM in a sub-directory of the unix directory named chanapi-version. This is provided as a backup to view the original distribution files.

Note: The software distribution includes support for both Solaris and Linux in the same package. Device driver code for Solaris and Linux are in separate sub-directories of the unpacked software distribution. The configuration step will configure your package to use the proper device driver directory for the system you run the configuration on.

3. Configure the Software

This step involves setting up the environment and running the configure script that is provided in the top level of the distribution source directory.

3a. Choose the Installation Directory

Before configuring the software you should decide where the software is to be built, installed to, and used from. The installation directory should be a common location accessible by all users who will need to compile applications and run support or diagnostic programs. The default directory is /usr/cac. Once you have chosen this directory you should set your environment to have a variable named CAC and its value should be the name of your installation directory.

Users of the software should also include the directory, $CAC/bin, on their program search path to enable running the programs from any location in the filesystem. This is usually done by appending to the PATH environment variable. You may also want to include one or more of the following directories for diagnostic programs:

$CAC/dpl3/diag to run DPL3 diagnostic programs.
$CAC/dplp/diag to run LightParser diagnostic programs.
$CAC/lp2/diag to run LightParser2/2e diagnostic programs.

If you use the Bourne shell (sh or one like it) use the following commands to set this variable (replace "/usr/cac" with the directory you have chosen):

    # CAC=/usr/cac
    # export CAC
    # PATH=$PATH:$CAC/bin:$CAC/dpl3/diag:$CAC/dplp/diag:$CAC/lp2/diag
    # export PATH

You can add those commands to your .profile file, or whatever file your shell reads startup commands from, so that the CAC variable and PATH will be set automatically the next time you log on.

If you use the C-shell (csh or one like it) use the following command to set this variable (replace "/usr/cac" with the directory you have chosen):

    # setenv CAC /usr/cac
    # setenv PATH ${PATH}:$CAC/bin:$CAC/dpl3/diag:$CAC/dplp/diag:$CAC/lp2/diag

You can add those commands to your .login file so that the CAC variable and PATH will be set automatically the next time you log on.

3b. Choose the Build Directory

The software may be configured and built directly in the source directory. However, it is recommended that a separate build directory be created to configure and build the software. This is especially important if you plan to configure and build software to support both DPL3 and LightParser boards or if the software distribution is unpacked in a location that can be shared from systems with different operating system versions or require different configuration options.

If you choose to build the software in the distribution source directory run:

    # cd /usr/cac/chanapi-version
    # ./configure --enable-board_type --prefix=$CAC

If you choose the build the software in a separate directory the commands are slightly different, specifying the path to the configure program in the source directory. First choose a name for your build directory.

    # mkdir /usr/cac/build_name
    # cd /usr/cac/build_name
    # ../chanapi-version/configure --enable-board_type --prefix=$CAC

You can unpack the software onto your system by creating a local directory, cd'ing into it and running the tar program. For example:

    # mkdir /usr/cac
    # cd /usr/cac
    # tar xvf /cdrom/unix/chanapi-version.tar

The build_name should indicate the board type and platform, especially if you may be building the software under various operating system versions. Example suggestions for build_name; build DPL3 software for Linux Red Hat Enterprise Linux 3 in a directory named "dpl3.rhel3" and build LightParser software for Solaris 9 on Intel x86 in a directory named "dplp.sol9x86" or, for Solaris 10 on Sparc use "dplp_sol10sparc".

3c. Configuration Options

The examples of using the configure program, above, show the use of two options. Some situations may require additional configuration options. The configuration options are specified using parameters added to the command line for the configure program. A complete list of options is available by using the --help parameter:

    # ./configure --help

This will generate a rather long list of options, many of which are part of the standard GNU software system and are irrelevant for the CAC software. The options of interest are:

--enable=BOARD-TYPE

This option is required and specifies the type of board to configure the software for. The choices for BOARD-TYPE are dpl3 for DPL3 boards, dplp for LightParser boards and dplp2 for LightParser2 and LightParser2e boards. For example:

    --enable-dpl3
  or
    --enable-dplp
  or
    --enable-dplp2

Note that only one board type may be specified.

--prefix=PREFIX

This option specifies a location to install the compiled libraries and programs. If you chose an installation directory other that the default of /usr/cac you must use this option to specify the installation directory.

--with-numboards=#

This option is used to specify the number of DPL3 or LightParser boards you expect to install in your system. The value is used to size various array in the API and counters in programs that operate on multiple boards. The value is also used to determine how many device entries to create in the /dev directory for Linux installations.

The default number of boards is 4.

--with-readline=option

Some of the interactive support and diagnostic programs utilize an external library for controlling user input called readline. The package provides some convenient command line editing and recall features. Currently the programs that use readline are dpl_debug, dplp_debug, lp2_debug and lp2_sdhgroom. A version of this library is included with the Channelization software release.

The --with-readline parameter allows the user to specify the following readline options:

cac	Use the readline library provided by CAC. (default)
system	Search for a readline library installed on the system.
disable	Disable the use of any readline library.

Many host systems have a readline or compatible facility already installed. However the use of the readline facility in the CAC programs may be incompatible with newer distributions of the readline library. Therefore, the default readline option is to compile and use the version in the CAC software distribution.

--with-cflags=flags

This option allows you to specify additional flags to the C compiler. It is primarily intended to allow specifying a 32-bit or 64-bit environment for the API library and support programs.

See the "Notes on 64-bit Compatibility" below for details.

This option does not affect compilation of the device driver.

Special options for Solaris device driver configuration are:

--enable-solaris64
--enable-solaris32

Normally the Solaris device driver is configured to be compiled for the type of kernel currently running (32-bit or 64-bit).

These options force the device driver configuration to be compiled for the 32-bit or 64-bit kernel regardless of the currently running system. They may be useful if you need to prepare an installation that can be used with a different kernel.

Special options for Linux device driver configuration are:

--disable-bigphys

For release version 0.6.0 and higher, the default configuration is to use the bigphysarea facility for allocating DMA memory for channel buffers if the bigphysarea.h header file is found in the Linux source directory.

This option disables the use of the bigphysarea facility for testing or in case the bigphysarea facility in not actually enabled in the kernel.

For Linux 2.4 kernels without the bigphysarea facility, the method for allocating DMA memory is limited to about 10 or 12 megabytes which may not be sufficient for some applications. One exception is the 2.4 kernel ported to the SGI Altix system (ProPack 3), which does not suffer from this limitation.

--enable-bigphys

In versions prior to 0.6.0, use of the bigphysarea facility for allocating DMA memory was not configured by default. This option enables the use of the bigphysarea facility if the bigphysarea.h header file is found in the Linux source directory.

--disable-vsyms

This option is used to disable compiling the device driver with version information for kernel symbols. In most cases this should be left enabled. However, under certain circumstances the kernel symbol versions obtained from the installed kernel source may not match those of the running kernel. Symptoms of this situation are unresolved symbol errors when loading or installing the device driver. If you experience these types of errors, try re-configuring and re-building the device driver using this option.

--with-ksrcdir=dirname

This option is used to specify the location of the kernel source or build directory. It is available with release versions 0.7.4 or higher.

By default this directory is determined by the version of the currently running Linux kernel at the time the configure program is run. For Linux 2.4 kernels, it is usually found in /usr/src/linux-version. For Linux 2.6 kernels this directory will be the module build directory which is usually found in /lib/modules/version/build.

The source or build directory may be specified to be that of a different version of the kernel to allow building the device driver to be installed on a system running a different version of the Linux kernel. There are some additional requirements and limits for the ability to cross-build the device driver, described below.

--with-kmoddir=dirname

This option is used to specify where the device driver module is installed. It is available with release versions 0.7.4 or higher.

The module installation location setting affects both where the Makefile installs the module and where the boot script looks for it. By default the directory is determined by the currently running kernel version at installation time and at boot time and is located in /lib/modules/version/misc.

Because the default location is determined at installation or boot time, it is not usually required to specify this option when configuring the device driver to be built for a different kernel version.

--with-rcdir=dirname
--with-initdir=dirname

These options are used to specify the location of the system init-scripts and the symbolic links to them that are used to control how and when the scripts are run. By default the configure script searches for the usually locations: /etc/rc.d/init.d, /etc/init.d and /etc/init.d/rc.d.

If neither of those exist or you need to specify another location, use the --with-rcdir option to name the parent directory where the directories rc2.d, rc3.d, rc5.d, etc. are found. If that directory does not also include the directory named init.d then also use the --with-initdir option to specify the parent directory of the init.d directory.

--with-majordev=#

Normally the Linux device driver allows the Linux kernel to dynamically allocate its major device number. If, for some reason, you want to force the use of a specific major device number, use this option to specify it at configuration time.

Be sure not to specify a number that is not reserved for other devices in the system. Consult the file, devices.txt, in the Documentation directory of the Linux kernel source for a list of devices with reserved major device numbers.

3d. Notes on 64-bit Compatibility

The ChanAPI software API and device driver are 64-bit compatible. Configuring the software to be compiled for 64-bit varies depending on the operating system and platform.

For Linux on Intel x86 and ia64 platforms, the GCC compiler is generally installed with default settings to match the architecture and installation. For example, when the Red Hat 64-bit installation is loaded on a system with x86 EMT-64 processors, it will compile 64-bit code by default.

The device driver must be built to match the data width of the kernel. However, if you wish, you can build the API for 32-bit applications. This can be done by using the following option with the configure script:

      --with-cflags=-m32

For Solaris, the device driver must be compiled as a 64-bit module if the system supports sparc-v9 or amd64 architectures and is running the 64-bit kernel. The configure script handles this by automatically providing the appropriate compiler flags for the device driver. However, by default, the user code (API and support programs) compilation is done for 32-bit code, regardless of the platform and kernel mode. It is not affected by the enable-solaris64 option to the configure script.

To compile the user code for 64-bit applications use one of the following options with the configure script (depending on the compiler and platform).

Compiler	Platform	Configure Option
Gnu GCC	any	--with-cflags=-m64
Sun Studio CC	Sparc (v9)	--with-cflags=-xarch=v9
Sun Studio CC	x86-64 / AMD64	--with-cflags=-xarch=amd64

4. Compile and Install the Software

Once the configure program has been run you may compile the software. To do this, run the following command in the build directory, where you ran configure:

    # make

This will compile the various libraries and programs that comprise the channelization API. Excluded from the default build is the device driver. The device driver is built and installed as a separate operation described below.

Once the API and programs have successfully compiled they can be installed by running the command:

    # make install

This will install the various components and the API and support files into the following directories:

directory	files installed
$CAC/bin	support programs
$CAC/lib	the Channelization API library and other libraries used by the software
$CAC/include	header files required for applications that use the API
$CAC/dpl3/diag $CAC/dplp/diag $CAC/lp2/diag	diagnostic programs (directory name depends on the board type)
$CAC/dpl3/hwdata $CAC/dplp/hwdata $CAC/lp2/hwdata	data files for FPGA and PLL configurations (directory name depends on the board type)

5. Compile and Install the Device Driver

The device driver is installed separately from the libraries and support programs.
This step must be performed with root privileges.

5a. Solaris Device Driver

The Solaris device driver has been tested with Solaris 8 and 9 on Sparc and x86 (IA32) platforms.

To compile and install the Solaris device driver, change your current directory to the soldev sub-directory of your software build directory and run make install-dev. For example:

    # cd /usr/cac/dpl3.sol9sparc/soldev
    # make install-dev

This will compile the driver code and run the system commands to install the driver in your system. The device driver installation process includes installing a system start-up script that will automatically initialize the DPL3 or LightParser boards as part of the system boot-up procedure.

Note: a 64-bit capable compiler is required if you are building the device driver for a 64-bit Solaris kernel. Compatible 64-bit compilers include Sun Workshop or Forte compiler and GCC version 3.2 or higher.

5b. Linux Device Driver

The Linux device driver supports 2.4 and 2.6 kernel versions on Intel x86 (IA32) platforms. Kernel version 2.4 has been tested with Red Hat releases 7.3 through Enterprise Linux Version 3. Kernel version 2.6 has been tested with Red Hat Enterprise Linux versions 4 and 5.

Compiling the Linux device driver for 2.4 version kernels requires the kernel source to be installed. This is normally installed with the kernel-source RPM. Check the installation using the command:

    # rpm -q kernel-source

Compiling the Linux device driver for a 2.6 version kernel requires that the appropriate kernel development package be installed. The appropriate package depends on the type of the kernel you are running and, perhaps somewhat, on which Linux distribution is used.

For Red Hat Enterprise Linux 4, the choices are normally either the kernel-devel or kernel-smp-devel package (for the single processor or SMP variant of the kernel, respectively). Both are usually installed if you select Kernel Development as one of the packages to install. If you are using the hugemem variant of the kernel you should install the kernel-hugemen-devel package.

For Red Hat Enterprise Linux 5, the kernel-devel package is installed by default and will work unless you have installed one of the special kernel variants, such as the PAE enabled kernel. In this case you need to also install the kernel-pae-devel package.

You can usually determine which kernel variant is currently running using the uname -r command. Check the installation using commands appropriate for the kernel variant you are using. For example:

    # rpm -q kernel-devel

    # rpm -q kernel-smp-devel

    or

    # rpm -q kernel-pae-devel

The facility for allocation DMA memory for PCIbus access is limited in the Linux 2.4 kernels to providing about 10 to 12 megabytes. This may be insufficient for some applications, especially those requiring the high bandwidth of data available from a LightParser, LightParser2 or LightParser2e board. For such purposes it is necessary to patch the kernel to include the bigphysarea facility. This widely used patch reserves a specified amount of memory at boot time and makes it available to device drivers through a set of simple kernel functions added to the system. The bigphysarea patch files and installation instructions are available on the CDROM that contains the ChanAPI distribution and from our FTP site at

ftp://ftp.cacdsp.com/pub/misc/bigphys_rh.tar.gz.

This patch is not required for the Linux 2.6 kernel which is able to provide enough DMA memory as long as the system has enough. The bigphysarea patch may be used with the 2.6 kernel if desired.

To compile and install the Linux device driver, change your current directory to the linuxdev sub-directory of your software build directory and run make install-dev. For example:

    # cd /usr/cac/dpl3.rhel3/linuxdev
    # make install-dev

This will compile the driver code to create the loadable kernel module, load the module and create device entries in the /dev directory. It also copies the driver module into the /lib/modules directory of the system for use by the boot-up initialization script (see below).

The device driver will be properly compiled for SMP if the system is running in SMP mode. To build and install the module for both SMP and non-SMP kernel modes, after installing the driver while running in the current kernel mode (SMP or non-SMP), reboot the system in the other kernel mode and run the following commands in the linuxdev build directory:

    # make clean
    # make install-dev

This will force the driver module to be rebuilt and installed for the new kernel mode. Now both versions will be installed in the appropriate modules directories. For example:

    /lib/modules/2.4.18-3smp/misc/dpldrv.o      - the SMP driver
    /lib/modules/2.4.18-3/misc/dpldrv.o         - the non-SMP driver

When installing a new device driver on a system that has the device driver already loaded, the module must be unloaded before the new one can be installed. To do this, run this command prior to the make install-dev command:

    # make unload-drv

If you need to uninstall the device driver completely, run the command:

    # make uninstall-dev

Whenever the device driver is loaded or re-loaded, the initialization program must be run to initialize the boards. (see below).

The device driver module must be re-loaded and the device nodes re-created whenever the system is rebooted. To automate this process you can install an initialization script to be included in the system's boot-up initialization procedure. It is recommended that this be installed after you have verified that the driver loads and operates properly in your system and you can successfully run the initialization program.

To install the initialization script run the command:

    # make install-rc

This will copy the configured script to the system's init.d directory and create links in other RC directories to run the boot-up sequence when the system boots into run-level 3 or 5 and to run the shutdown sequence when the system switches to run level 6 or 0 (reboot or halt).

The initialization script's boot-up sequence loads the device driver module, creates device entries in /dev and runs the initialization program. The the device driver module from the appropriate modules directory for the kernel mode that is running (i.e. SMP or non-SMP).

During system start up, the init-script will be indicated by the message, "Starting cacdpl" for DPL3 boards, "Starting cacdplp" for LightParser boards or "Starting cacdplp2" for LightParser2/2e boards. It may pause for several seconds while initializing the boards, especially if the Expansion FPGA on DPL3 boards or the Virtex FPGA on LightParser, LightParser2 or LightParser2e boards require configuration. Check the system log file (/var/log/messages) for details on the initialization sequence.

The script's shutdown sequence re-initializes the board to disable any on-going channelization and unloads the device driver.

If you need to remove the init-scripts from the system run the command:

    # make uninstall-rc

5c. Cross-Building the Device Driver

The API library and support programs are generally compatible across versions of the operating system, although not all possible combinations have been tested. Note however, that separate builds are always required for Solaris on Sparc platforms, Solaris on x86 platforms and Linux on x86 platforms.

Device drivers are generally much more dependent on the specific version of an operating system. The default configuration and build for the device driver assumes that the device driver is to be installed for the currently running version of the operating system on the current hardware platform.

Cross-compiling the device driver, building it for installation on a different version of the operating system is supported to a limited extent by the configure program. Compiling a device driver for a different hardware platform is not supported.

When cross-compiling the device driver to be installed later for a different version of the kernel, do not use the make install-dev command as show in the previous sections. Instead, run

    # make driver

This will compile the device driver to produce the loadable module without attempting to install it on the current system.

The Solaris device driver has not typically been dependent on the version of the operating system. For example, a device driver built on Solaris 8 can be installed on a system running Solaris 9. The primary dependency for the Solaris device driver is whether or not it is build for a kernel that supports 64-bit addressing. A device driver built for the 32-bit version of the Solaris kernel will not load for the 64-bit version of Solaris, and vice-versa. If it is necessary to build a Solaris device driver for they kernel type (32-bit or 64-bit) that is not the currently running type, one of the configuration options, --enable-solaris64 or --enable-solaris32 may be used.

Linux kernel modules are much more dependent on the kernel version and, in some circumstances, on the version of the compiler used.

The main requirement for compiling the Linux device driver for a different version of the kernel is to have the kernel source for the target version installed. This is most easily accomplished by installed the appropriate RPM package; the kernel-source package for 2.4 kernels, or the kernel-devel and kernel-smp-devel packages for 2.6 kernels. The --with-ksrcdir configuration option may be used to direct the configuration to the kernel source (or build) directory for the desired target kernel version. Note: this option is available in ChanAPI release versions 0.7.4 or higher.

For 2.4 kernels, the kernel source directory must be configured and build up through the step of running make dep in order to have all the required module version information available. If the bigphysarea patch is to be utilized, the kernel source directory must include the patch, as well.

This works on its own for building the Linux device driver for various kernel versions with the same Red Hat Linux release family (i.e. Red Hat 8, Red Hat 9, Enterprise Linux 3 and Enterprise Linux 4). Certain problems arise when attempting to build the device driver for a different Linux distribution. For example, to compile the driver for Red Hat Enterprise Linux 4 (a 2.6 kernel) while running Red Hat Enterprise 3, the version of the GCC compiler from the Red Hat Enterprise Linux 4 distribution must be used, and vice-versa. To specify the compiler, you should specify the full path to the gcc program as the environment variable, CC. For example:

      # setenv CC /usr/local/rhel4gcc/bin/gcc
      # make driver

or

      # CC=/usr/local/rhel4gcc/bin/gcc
      # export CC
      # make driver

Compiling a device driver for Red Hat 8 or Red Hat 9 while running newer Red Hat distributions may not work at all because of various differences in how the kernel is built and installed.

6. Update FPGA Configurations

The DPL3 and LightParser boards include non-volatile memory which stores FPGA configuration information and data. The non-volatile memory may be a combination of flash memory and/or special purpose electrically-rewritable read-only memory. Some LightParser board assemblies may not include the flash memory, requiring the host to configure the Virtex FPGA. However, the configuration version numbers are still stored on the board.

In the case of the LightParser2, the FPGA configuration data and version numbers are stored on a removable Multi-Media Memory Card (MMC). In the case of the LightParser2e, the FPGA configuration data and version numbers are stored on a removable Mananged NAND module (MNAND). The FPGA cannot be configured without the MMC or MNAND installed.

New software releases may include updates for FPGA configuration data. To ensure that the FPGA configurations are up to date, run the "flash" updater program: dpl_flashup for DPL3 boards, dplp_flashup for LightParser boards or lp2_flashup for LightParser2 and LightParser2e boards. For example:

    # dpl_flashup all
  or
    # dplp_flashup all
  or
    # lp2_flashup -A all

The program will compare the configuration versions in the storage medium of each board with the versions in files from the new software release. Any new configuration versions will be loaded onto the boards. The use of the -A option for LightParser2 and LightParser2e is required to update all FPGA types stored in the MMC or MNAND.

To see what the flashup will do before actually committing the changes use the -S (show-only) option. For example:

    # dpl3_flashup -S all
  or
    # dplp_flashup -S all
  or
    # lp2_flashup -SA all

7. Initializing Boards

DPL3 and LightParser boards must be initialized before most applications can be run on them. An initialization program, dpl_init for DPL3 boards, dplp_init for LightParser boards or lp2_init for LightParser2 and LightParser2e boards, is provided to prepare the boards for application use. This program must be run after the board is first powered on and after updating FPGA configurations. For example, the command

    # dpl_init all
  or
    # dplp_init all
  or
    # lp2_init all

will initialize all of the DPL3, LightParser, LightParser2/2e boards found in the system. It also configures the expansion FPGA on any DPL3 boards that have the expansion FPGA installed, the Virtex FPGA on LightParser boards that do not have flash memory installed to store the Virtex configuration, or reconfigures the FPGA on LightParser2 and LightParser2e boards if it is currently loaded with a boot configuration.

The ChanApi Utility reference manual describes the other options available with the init programs.

As described above, the device driver installation process includes installing a system start-up script that will automatically initialize the boards as part of the system boot-up procedure.

8. On-Line API Reference

A reference manual for the channelization API is available in HTML format. This documentation is created using a software package called doxygen (www.doxygen.org) The on-line reference is provided in a separate archive for download as chanapi-ref-version.tar.gz or on the CDROM as chanapi-ref-version.tar.

To unpack the downloaded version of the reference manual, create a local directory and place the archive file there. Then run the gunzip and tar programs as shown:

    # mkdir /usr/cac
    # cd /usr/cac
    # (download the archive to here)
    # gunzip -c chanapi-ref-version.tar.gz | tar xvf -

To unpack the reference manual from the CDROM, create a local directory, cd into it and run the tar program. For example:

    # mkdir /usr/cac
    # cd /usr/cac
    # tar xvf /cdrom/manuals/chanapi-ref-version.tar

Once unpacked, the manual may be viewed with any WEB browser by opening the file chanapi-ref-version/html/index.html.

The reference manual is also available, already unpacked, on the CDROM in the manuals directory. It can be viewed from there by opening the file /cdrom/manuals/api-ref/html/index.html