April 23, 2009
Overview
The following changes are introduced in this release:
Notes:
Fix for Power-on Configuration Problem on DPT5 and DPT6 Boards
Background: This problem involves an anomaly in one of the components on DPT5 and DPT6 boards that can interfere with the FPGA configuration process when the board is first powered on. Depending on various factors, the problem may not occur at all, may occur very seldom or may occur very often. It can vary from board to board and from host system to system.
We have strived to weed out problematic boards. However, it is possible that some boards that did not fail in our test systems could exhibit the problem in customer systems.
All new boards being shipped have been modified to fix this problem and are marked with a label showing the revision "0.6" or higher for DPT5 boards and "0.4" or higher for DPT6 boards.
Symptoms: If the host FPGA fails to configure the board will not be seen by host system when it scans for devices during the early stages of the boot process. Therefore, the operating system will not detect any boards. One clue that this has happened is if there are boards plugged into the system and the dpfind does not report any boards or reports fewer than are installed.
However, there are other conditions that could cause the software to not report one or more of the boards. If boards appear to be missing from the list reported by dpfind, try to determine if they failed to configure.
The most direct way to determine if the host FPGA has failed to configure is to view the two LEDs on the top side and top edge of the circuit board (the edge opposite the PCI connector tabs). If the LEDs labeled PLD and FPGA are both RED, the FPGA is not configured. Normally these LEDs should be GREEN, OFF or Blinking GREEN.
It may not be easy to view these LEDs without removing the cover from the computer. You can also try to examine the system's device configuration.
- On Linux systems: In a shell window (e.g. console or X-term) run the command:
/sbin/lspci -n | grep 1231:05e1DPT5 and DPT6 boards should appear in the results as lines that include the value, "1231:05e1".
- On Solaris systems: In a shell window (e.g. console or X-term) run the command:
/usr/sbin/prtconf | grep 1231,4e1DPT5 and DPT6 boards should appear in the results as lines that include the value, "pci1231,4e1". (Note: the "4e1" is not an error.)
- On Windows systems: Open the device manager via Control Panel / System, select the "Hardware" tab and click on the "Device Manager" button.
If the DPT device driver has previously been installed on the system you should see devices named "DPT5/6" in a category named "CACDSP".
If those are not found or if the device driver has not been previously installed, look for "? PCI device" entries under the "? Other devices" category. Double click on each device icon to access its properties and select the "Details" tab. For DPT5 and DPT6 boards, the string in the value field should begin with "PCI\VEN_1231&DEV_05E1".
If you do not see results that account for the DPT5 and DPT6 boards installed in the system, it is likely that the missing boards have failed to configure their host FPGA device.
The fix requires both a physical modification to the board and a new configuration for the CPLD device on the board. This release includes the new CPLD configuration file (dpt5c1-5-4.xsvf). While the new CPLD configuration is not sufficient to solve the problem by itself, it is a required part of the solution and it is important that it be available to avoid an older version being loaded. The new CPLD configuration does not affect boards that do not have or require the physical modification.
CAC will fix any DPT5 or DPT6 board that exhibits, or is suspected of exhibiting, this problem, by applying the physical modification and updating the CPLD configuration. Contact CAC at 1-800-367-6735 or sales@cacdsp.com to request an RMA for this repair.
Update for the DPT5 and DPT6 host FPGA Configuration
In addition, maximum DMA retry count was increased to eliminate
some rare errors caused in older systems when 3 or more boards
are running diagnostics at the same time.
Minor Version Portion of PCB Revision Added to Value Stored in EEROM
The minor revision portion, if provided, is stored in the upper 8 bits
of the EEROM field used to store the board revision.
Note that this will affect the value read from that field as well
as the revision value reported by the pci_get_info function.
If the value of this 16-bit field that exceeds 255, it indicates a minor
version portion is present.
Operations based on this value must mask off the upper 8 bits to
determine the major revision number.
Programs that report the PCB revision will display the minor version
and a value after a decimal point appended to the major revision number,
if the minor version number is non-zero.
Updates to Some Support and Diagnostic Programs
The dpserial program is modified to accept a minor version portion
for the PCB revision code.
For example, the revision may be entered as "0.5" to specify a revision
0 PCB with minor version number 5.
The dpfind and dpinfo programs have a new -i option
to identify each board by blinking its LEDs for about 10 seconds.
The LEDs may be hard to see on boards with LEDs behind and between the
shielded RJ-45 connectors,but should be visible when blinking.
On DPT4 boards, the embedded MIPs processor must be running for
the panel LEDs to blink.
These programs are also modified to display the new minor version portion
of the PCB revision code, if present.
The dpdebug program has new command line arguments and a new
command for special purpose testing.
The -e and -f arguments request opening devices without
EEROM support and/or without restoring settings in PCI configuration space.
The new fixbridge command restores the settings for the bridge
device on DPT5 and DPT6 boards but is only usable on systems for which
the device driver supports this operation (currently only Linux).
Updates to the Linux Device Driver
The allocation of the system device region for DPT boards on systems
running 2.6 kernels is fixed to allow more than 4 boards per system.
Added support for the PCI_FIXBRIDGE ioctl request that is used by the
the new "fixbridge" command in the dpdebug program.
The host FPGA configuration for DPT5 and DPT6 includes an improvement
for handling aborted PCI target transactions.
The problem was discovered during repeated power-cycle tests
and is not a normally expected condition.
The PCB revision value that is stored in the board's EEROM may now include
a minor version value which tracks modifications applied to the board
during or after board assembly.
These modification generally represent wiring or component changes
made after the design and tooling of the circuit board.
The dpflashup program is modified to avoid attempting to re-program
the CPLD device on DPT5 and DPT6 boards with the host FPGA configured
with an incompatible version.
Specifically, versions 1.5.5 and 1.5.6 of the host FPGA have a problem
communicating with the CPLD device that can render the board inoperable
if reprogramming the CPLD is attempted.
This new version of dpflashup will skip the CPLD update if it
sees that one of those version of the host FPGA is loaded.
Once the FPGA version is updated and reconfigured, the program can be run
again to complete the update for the CPLD device.
A bug in the Linux device driver is fixed that could cause the driver
to get into a dead-lock state if an "unexpected" value is read from
from the interrupt status register during the interrupt service procedure.
The situation that could cause this is unusual but could occur in
some special circumstances.