The device driver and API have been tested with Red Hat Linux 7.2 and 7.3 with Kernel versions 2.4.7-10, 2.4.9-31 and 2.4.18-3. See the Readme file in the linuxdev directory of the software distribution for more information.

Section 13 of the "DPT4 Hardware Reference Manual" is updated to describe the procedure for re-loading the flash memory of an unconfigured board.

• Burst accesses crossing SDRAM row boundaries on DM5420 modules.
• Timeouts too short for read accesses from smPCI modules.
• Host PCI controllers combining separate IO operations into burst accesses to non-burstable regions.
• Attempts to access uninitialized boards.

The first two problems are solved by changes in API library functions that are involved in those IO operations.

The third problem is solved by having the device driver perform the actual IO operations to DPT board registers and having the device driver break up write accesses by performing read operations after critical write operations. Having these operations performed in the device driver also provides a mechanism to avoid IO operations being combined from separate processes and threads. Functions in the API library that require register access are modified to perform those operations using calls to the device driver level.

Some problems encountered are often due to DPT boards not being initialized prior to use. This problem is solved by the library functions used to open DPT devices checking a new register bit indicating that the board has been initialized. The register bit is set by the dpinit program. If a device is opened prior to initialization the call to the open function will fail. A special flag to the open function, PCI_OPEN_IGNORE_INIT_FLAG is provided so that programs that require accessing uninitialized DPT boards can still open the devices.

The API library and device drivers are also modified to have the device drivers cache data read from and written to the EEPROM on the DPT board. Operations requiring EEPROM access take advantage of the cached values instead of having to actually access the EEPROM every time.

Prior to version 1.3.0, the DPT's embedded code that performs the channelization operations was actually included with the MIPS loader code. Starting with version 1.3.0, the embedded application is separated from the loader code. The loader code may now be used to boot user applications loaded into SDRAM or flash memory.

Information on how to build and use MIPS applications will be provided in a forthcoming DPT application note.

The cold reset option (-c) is removed from the dpinit and dprun programs because it is no longer supported by the current FPGA configurations.

The dptp12config program is fixed to handle situations where the host checks JTAG status before the FPGA has had time to set its "data valid" flag.

A new diagnostic program, dpmemtest, provides a tool to test all of the memory on a DPT4 board. This includes the global SDRAM on the baseboard, TDM map memory and memory on smPCI modules. However, the current version does not support testing DSP internal memory on smPCI modules.

The dppws program is no longer included in the distribution. This was a program used for some early hardware development.

To eliminate this problem, the software distribution no longer contains files named "Makefile.am" and the newly created "Makefile" files are not dependent on them.

The only exception is for the readline library distributed along with the DPT software. This is a separately maintained, open-source software library and is distributed without modification.

Important Note:

The new MIPS loader code uses a RamBoot flag setting in the flash memory to determine if it should run a program stored in Flash or SDRAM memory. The default channelization application is stored in Flash memory and will not be executed if the RamBoot flag is enabled. Typical symptoms involve errors from the dpchantest diagnostic and other applications that use channelization.

Most DPT boards do not have RamBoot enable by default. To determine if your DPT board is configured with RamBoot enabled run the program shown below (replace "dpt0" with the proper device name for your board):

    dpserial -s dpt0

The last line of the display shows the various options settings. If this line includes the phrase No RamBoot the board is configured to properly run the channelization application from flash. However, if the options line says RamBoot then you need to run the following programs to configure the board and execute the MIPS channelization code:

    dpserial -r0 dpt0
    dprun dpt0

There is no need to reboot or power-cycle the board for this change to take effect.

In addition to the MIPS loader change, some minor bugs in the channelization application were fixed.

• Added initialization flag bit in CR48.6 cleared on power-up or PCI Reset.
• Cronus reset logic is fixed to meet signal timing requirements Cold Reset is no longer under software control. It is only asserted at power-up or PCI Reset.
• The read timeout retry code is changed to 0xe7e7e7e7. This pattern is less likely than the previous pattern to appear in actual data and is also endian-independent.
• Fixed a bug that caused timed-out reads from TDM RAM to put the retry pattern on only one byte lane.

Important Note:

This note pertains to customers continuing to use previous versions of the DPT software (prior to 1.3.0) and who receive new boards that must be flashed back to the older versions of the FPGA configurations and embedded code:

Due to the new retry timeout code used in the host interface FPGA, older versions of the dpflashup are likely to encounter an error when attempting to run on boards that are configured with version 1.3.0 or higher of the host FPGA configuration. The error can leave the DPT board(s) inoperable.

In order to successfully revert new DPT boards to the older FPGA configurations the dptp12config program must be run before dpflashup. Run dptp12config as follows:

    dptp12config -f dpe1h8.bit dpt0

Repeat this program for all the boards that need to be re-flashed. Once this step is performed it is safe to run the dpflashup program normally.

In case the dpflashup program has already been attempted and has reported an error or otherwise failed to complete successfully, you may still recover by running the dptp12config program as long as the board has not been power-cycled and the system has not been rebooted.