Broadcom PCI/PCIe SDK
Release Notes
Version 8.23
November 2020
Important Notes:
1. NDA Required for Full Software Support of PLX PCI Express Switches
2. Distribution of PCI/PCIe SDK Components
3. Shipping a Product with a Broadcom/PLX chip
5. PCI/PCIe Debug Tools Per-chip Support
6. Compatibility with Newer Versions of Microsoft Visual Studio & Managed Code
7. PCI/PCIe Drivers and the 9050 BAR Errata
8. Increase Host CPU Write (“Direct Slave”) Performance to PLX 9000 & 8000 BAR Spaces
9. Working with the Generic Local-to-PCI Interrupt (LINT) or GPIO Interrupts
10. Using the PCI/PCIe API Statically Instead of as a Dynamic Link Library (DLL)
11. PCI/PCIe Digitally Signed Windows Drivers
12. Windows IA64 is not supported
13. Access to PCIe Extended Configuration Space on UEFI Systems via Windows PCI/PCIe Service driver
Changes in SDK Versions:
Beginning with SDK 5.20, an NDA key is required for complete software support of PLX PCI Express Switches (i.e. 8500 & 8600 parts). The NDA key only affects the PLX Device Editor utility (PDE) and will not affect any other portion of the SDK. Without an NDA key, access to PLX switch registers and EEPROM will be disabled in the PDE. Access to PLX chips through the PLXMon & PlxCm utilities does not require an NDA key.
To obtain an NDA key, please contact the sales representative for your region. NDA keys are assigned based on the PLX switches used in the design. You may update your key anytime by re-starting the PLX SDK installation and selecting the “Modify” option. To find your PLX sales representative, please visit http://www.plxtech.com/about/contacts.
PCI/PCIe Software License Agreement
This section is meant for OEM customers who have written applications with Broadcom software and intend to ship it with their product. The PCI/PCIe SDK is provided under a proprietary license. Specific SDK components are provided under dual license: the GNU General Public License (GPL) version 2 and BSD licenses. Only these components are permitted to be distributed.
PCI/PCIe SDK Distribution Restrictions
The following restrictions apply to the distribution of PLX software:
· The complete SDK package may not be distributed
· Applications, utilities, or tools provided by Broadcom, for which Broadcom does not provide source code for, such as PLXMon, GenMon, or the PLX Device Editor (PDE), may not be distributed.
· Tools for which PLX provides source for, such as PlxCm or PlxEep, may be distributed in binary format. If the tools are modified without removing “Broadcom” or ‘PLX’ from the name or any displayed output, such as command-line help, additional text must be added to clearly mention that the tool has been modified by the 3rd party & is not supported by Broadcom/PLX.
· Documentation written by Broadcom to explain software architecture or design or Broadcom reference documentation may not be distributed.
· PCI/PCIe software may only be used in conjunction with designs containing a Broadcom/PLX device.
· Broadcom provides no warranty for distributed PCI/PCIe SDK components and will not support end-users who have received such components from OEM vendors. End users must be made aware that Broadcom is not responsible for support of the OEM product.
PCI/PCIe Components Allowed for Distribution
Broadcom allows distribution of the following components required for OEM software to function properly and utilize the Broadcom/PLX chip through the PCI/PCIe SDK API.
· Any scripts needed to install the software and/or load modules.
· PCI/PCIe SDK driver source code may be distributed.
· PCI/PCIe SDK API library source code may be distributed.
· PCI/PCIe SDK header files may be distributed
Note: The distributable SDK components mentioned above must be distributed independently from all other non-distributable PCI/PCIe SDK components.
Designating a Device ID
If you have created a design with a PLX chip and plan to ship it to end users, it is important that the PCI ID of the device is set correctly. This generally applies to PLX 9000 & 8311 products. The ID is determined by a combination of the PCI Device/Vendor ID (PCI offset 0) and the PCI Subsystem ID (PCI offset 2Ch). It is important to note the following before shipping your product:
· A unique ID is required to properly identify your product, ensure no conflicts with other devices, and ensure the correct software is loaded for your product.
· PLX’s Vendor ID is 10B5h. This ID is reserved for use exclusively by PLX and PLX is responsible for maintaining a list of all devices that use this ID. Any devices set with the PLX vendor ID should not be shipped without express permission from Broadcom.
· The ID is set via an EEPROM that contains values the PLX chip will load upon power up.
· The PCI revision ID may also be used to identify a minor revision of your product. It is recommended, however, to use a new subsystem Device ID to identify a new revision of the product.
The proper procedure for determining the ID for you device is:
1. If your company is a member of the PCI SIG, you should already have a PCI Vendor ID assigned. Your device should be set with this Vendor ID and the Device ID should be maintained within your company. Refer to the PCI-SIG website for additional information (http://www.pcisig.com).
2. If you do not have a Vendor ID, you may contact support for an assigned subsystem Device ID for your product. Additional information will be required about the product and the company and then a subsystem ID assigned for exclusive use for your product. At that point, the Broadcom/PLX chip’s Device/Vendor ID (PCI offset 0) should be set to the default (e.g. 9054_10B5) and the subsystem ID will consist of the newly assigned Device ID along with PLX’s Vendor ID. For example, If PLX assigns 3A49h as the subsystem ID, the complete subsystem ID would be 3A49_10B5.
3. Once the complete ID is determined, it is important to program the EEPROM properly and to modify any software that ships with the device. This ensures that software applications are able to detect and access the device and also so the Operating System loads the correct driver for the product.
Software Modifications
If PCI/PCIe SDK API & drivers are used with the product, it’s important to rename files to avoid conflicts with other vendors shipping products with PCI/PCIe SDK files. The PCI/PCIe SDK API & driver versions must match. In other words, if SDK API v6.50 is used, the driver must also be from v6.50. Before distributing a product, the following steps are recommended:
1. Rename the driver file to a unique name to match your product. PLX driver file names do not change between PLX SDK versions. For example, rename Plx9056.sys to AcmeDecoder9056.sys. Windows uses .SYS extension but the same procedure applies to Linux, which uses .ko for driver extensions.
2. In Windows, modify the INF file to account for the updated driver name. In Linux, modify any scripts used to install the driver.
3.
In Windows, the PLX API DLL is renamed for every SDK version to include
the version number (e.g. PlxApi720.dll). In addition, internally,
the API DLL will only access PLX drivers of the same version. This should
eliminate most conflicts with other vendors. It is still recommended that
you modify the API DLL to a custom name, especially if any modifications are
made to the original file. The name modification must be made in the
Visual Studio project so that any applications linked with the DLL use the new
name.
In Linux, the PLX API is linked statically by default, so there should be no
name conflict unless the API library is modified to load as a shared object.
The PCI/PCIe SDK API supports native access to PLX chips over I2C. At this time, I2C connections are only supported with the TotalPhase Aardvark I2C/SPI USB device (http://www.totalphase.com/products/aardvark_i2cspi). Starting with PLX SDK 6.40, the PLX API takes advantage of the new I2C API function aa_i2c_write_read(), which has shown register read performance improvements up to 33%. This new API call, however, requires TotalPhase driver package v2.02 or higher. Additionally, the 2.02 drivers require the Aardvark device firmware to be v3.50 or higher.
To use I2C with PLX SDK v6.40 or higher, please update your TotalPhase drivers and firmware. The latest files may be obtained from the TotalPhase.com website (http://www.totalphase.com/products/aardvark-i2cspi/). Current released USB driver versions as of Dec 2019 are 2.16 for Win 7/8 and version 3.0 for Win 10.
The PCI/PCIe SDK provides various debug tools,
including PLX Device Editor (PDE) GUI, PlxCm command-line tool, and PLXMon
GUI. Depending upon the chip being used, some features may or may not be
supported in some tools. For legacy devices, including PCI 9000-series,
PCI 6000-series, PCIe 8311, 8111/8112, & 8114, please use either PLXMon GUI
or PlxCm for working with these devices.
The PDE GUI is designed to work only with PLX PCIe switches (PCIe
85xx/86xx/87xx/97xx). PDE used in accordance with legacy devices is not
supported. PLXMon/PlxCm may be used with any PCI/PCIe device, but do not
include some PDE-specific features, such as register-level descriptions from
the datasheet.
The Windows sample applications and API library are built with Microsoft Visual C++ v6.0, Service Pack 6. Microsoft’s newer Visual Studio (e.g. 2005/2008) includes newer versions of Visual C++. The project files shipped with the PLX SDK are completely compatible with newer versions after a simple conversion process. When a project file is opened, Visual Studio will display a warning that the project is from a previous version and will provide an option to update the project file. The conversion only needs to be performed once for each project file. The projects will then be fully compatible with the newer version and should open without a warning message. Starting with PLX SDK v7.0, VS 2005 Solution files are also provided for sample applications.
Note: Visual Studio project files are not backwards compatible with previous versions. A project, which was converted to or created with the Visual Studio 2005, for example, cannot be opened in Visual Studio v6.0.
Although PLX does not support Managed Code, there are techniques available which allow calling of PLX API DLL functions. The two techniques are published by Microsoft. At the time of this writing, this was located under:
http://msdn2.microsoft.com/en-us/library/ms235282
Due to a 9050 chip erratum, if a PC boots and the 9050 PCI BAR 0 is assigned a PCI address in which bit 7 is set, the PLX driver (and PLXMon) will not be able to access the 9050 internal registers or the EEPROM. An example of this is the address 0xffebc080. PlxMon will display all internal registers as FFFF_FFFF.
This erratum does not exist on the 9052.
When the Host CPU performs reads or writes from a PCI BAR space, this is called a “Direct Slave” operation. On most chipsets, the host bridge/Root Complex will not allow any sort of burst/large TLP payload for these operations. As a result, performance has traditionally been relatively poor for these types of transactions. This is not a limitation of the PLX device, but of the chipset and is a known industry standard in PCI and PCI Express.
After some investigation, PLX was able to achieve significant Direct Slave write performance increases, but only in Windows. Burst writes/large TLP payload will only occur in specific situations. First, the CPU must post write data quickly enough to the host bridge so that it can buffer enough to send out in a large chunk. Second, write-combining must be enabled for that specific region.
In SDK versions prior to v5.0, when the PLX Windows driver mapped a PCI BAR to kernel or user space, the mapping was always specified as non-cacheable (MmNonCached). To support CPU to PCI BAR space burst writes, the PLX driver is now able to map the space as Write-combinable (MmWriteCombined), which usually results in a significant increase in write performance. The PLX driver will enable write-combining for a PCI BAR space if the space is configured as pre-fetchable. For PLX devices, this is typically specified in the Space Range register in the EEPROM.
Notes: If write combining is enabled, however, issues could
arise in certain cases. In some instances, multiple writes to the same
location by the CPU may internally be combined into a single write on the
bus. This could result in undesired behavior, for example, if a sequence
of specific write values were intended to trigger a hardware device or were
destined for a FIFO port.
Direct Slave read burst is not achievable by any known methods. Some increase is possible by using x86 assembly code to read to special x86 SSE large registers (64-bit or higher). This is not supported by PLX. If greater performance is needed, a PLX device with a DMA engine is recommended to overcome these limitations.
The notable increase in performance was only noticed in Windows, but not in Linux. Linux does support a similar feature in newer kernels, but the PLX SDK drivers do not yet support this. In Linux, you may manually enable write-combining in MTRRs for a specific region. Refer to the Linux kernel documentation (http://www.mjmwired.net/kernel/Documentation/mtrr.txt). A future version of the PLX SDK may support this feature by either using mtrr_add() or iorema_wc() kernel functions.
The PLX PCI 9000 series chips all contain at least one generic local-to-PCI interrupt, which is related to the LINT# pin. Since this interrupt is generic and is triggered based on the OEM design, the generic PLX SDK drivers do not “know” how to clear the true source of the interrupt. For example, clearing the interrupt source may require a write to a specific local bus address. As a result, the PLX Windows and Linux drivers simply disable/mask the interrupt if it is active. Without this, the interrupt will continue to remain active and the OS will continuously call the PLX driver’s Interrupt Service Routine (ISR), which will hang the system since the ISR pre-empts all other tasks.
With this in mind, there are 2 options when the local-to-PCI interrupt is used:
· By the time the application is notified of the interrupt (i.e. return from PlxPci_NotificationWait), the PLX driver ISR will have already received it and disabled/masked it. After interrupt notification, the application must always re-enable the interrupt, but only after it has cleared the source of the interrupt. Without the re-enable, the interrupt will remain disabled/masked.
· Modify the PLX driver to clear the true source of the interrupt. Typically, this would be done in the DpcForIsr routine in the file PlxSdk\[Windows or Linux]\Driver\Source.9000\PlxChip\<Plx_Chip_Type>\PlxInterrupt.c. If this option were selected, the interrupt source would be cleared, so disabling/masking it will no longer be necessary. Note that this modification will make the PLX driver non-generic since it will contain OEM hardware-dependent code.
In the Windows environment, the PLX SDK API library is designed for use as a DLL (e.g. PlxApi50.dll). If the file PlxApi.c is included statically in a project, rather than calling it as a LIB that loads the API DLL, access violation exceptions could occur. The reason for the access violations is due to the required initialization that must occur before the PLX API is used. When Windows loads a DLL, it automatically calls the function DllMain(). Referring to this function in PlxApi.c will demonstrate the initialization that needs to happen. When PlxApi.c is included statically, the function DllMain does not get called, so the required initialization does not occur, resulting in eventual access violation exceptions.
The solution for this is to either, include the API LIB file (e.g. PlxApi50.lib) and have Windows load the DLL or, the application must explicitly call DllMain or equivalent to force the necessary initialization before the application calls any of the PLX API functions.
[Applies to Windows versions up to Windows 7/Server 2008]. Starting with PLX SDK v6.0, all PLX Windows driver binaries (.SYS files) are digitally signed by PLX. 64-bit versions of Windows will not load a driver unless it is digitally signed. PLX has implemented signing of only the driver binaries to allow customers to easily use PLX drivers with their own products. Windows will still issue a warning message before loading PLX drivers, but the driver will load properly.
[Windows 8/Server 2012 & newer] The introduction of Windows 8/Server 2012 resulted in greater restrictions for driver loading in default configuration. Driver packages must now provide a digitally signed CATalog file or Windows will refuse to load the driver. There are ways to override this setting (eg F8 Menu during boot or driver install options in system global policy), but PLX does not have the authority to modify these on end-user systems.
Starting with PLX SDK v7.0, PLX provides a PLX-digitally signed SDK CATalog file, which allows PLX drivers to load in Windows 8/10. Unfortunately, any modification to the SDK INF file (previously allowed), will invalidate the CATalog digital signature & Windows will no longer load the driver. At this time, customers that need to ship PLX drivers with Windows 8+ support must obtain a Kernel Mode Code Signing certificate for their company & digitally sign custom INF/CAT files.
Even when Windows allows PLX driver loading, Windows will still prompt the user with a warning regarding PLX certificate. This warning is standard for any device package that has not passed through Windows WHQL, in which case Microsoft adds its own digital signature. PLX SDK drivers are not submitted to WHQL because the drivers are generic & not tied to any particular card. To remove all warning messages, a driver package must be submitted for WHQL. Customers are free to create their own digitally signed installation packages for WHQL submission.
NOTE: If a PLX driver is rebuilt, it will no longer contain the digital signature and, therefore, will not load in newer Windows versions. For customers that must modify & rebuild PLX drivers, you must obtain your own digital certificate and sign the custom-built driver. Microsoft on-line documentation explains the procedure for driver signing. This is not supported by PLX but you may refer to the PLX BuildDriver.bat file in the PLX SDK that PLX uses to build & digitally sign drivers.
PLX 64-bit Windows drivers are only tested on standard x86 CPUs that support 64-bit (i.e. Core 2 Duo, Xeon, AMD64, etc). PLX drivers are not tested on Intel Architecture 64 (IA64) platforms and IA64 is, therefore, not supported.
The Windows version of the PCI/PCIe Service driver relies on locating the PCIe Enhanced Configuration Access Mechanism (ECAM) base address in order to access PCIe configuration space offsets 100h+. Since Windows does not easily provide a way for a service-type driver to obtain this information, the service driver manually probes ACPI tables in system ROM to find the address. On UEFI BIOS systems, however, the required tables for ACPI probe are not present, preventing the service driver from accessing PCIe extended registers.
Starting with SDK v8.0, when the service driver is unable to locate the ACPI tables, it will then, if enabled, perform a manual probe of system memory space to locate the ECAM. This presents a risk, however, because on some systems, access of specific regions may result in an exception and halt the system. In SDK 8.10, the algorithm was modified to search in reverse order and also allow the user to control the address range for the driver to search. These are registry options and the Driver Wizard may be used to modify them. These changes minimize the risk of a system crash.
The manual ECAM probe is disabled by default by the SDK installer to avoid potential crashes. On UEFI systems, if a user requires access to PCIe extended registers, the ECAM probe option must be enabled manually. The recommended procedure below should be followed:
· System may crash, so ensure nothing critical is running
· Launch Driver Wizard and disable the PCI Service Driver “Launch driver when Windows start” option
· Enable “Allow manual ECAM probe” option
· For the address ranges, start in the upper area, such as F0000000h -> FC000000h.
· Click “Start Driver”
o If the system crashes, repeat the steps but avoid the previous memory region and click “Start Driver” again
o If the driver loads ok, run PlxCm and select a PCI Express device (port number will be listed) and type ‘pcr 100’ to attempt a read of offset 100h. If a value other than FFFFFFFF is displayed, the driver was able to locate the ECAM and the access worked. If not, try a different address range, Stop/Start the driver, and try the register read again.
· Once the driver and PCIe accesses are working properly, the driver may be enabled to auto-start with Windows. It will refer to the registry for the last set of options to use the next time it loads.
NOTE: The service driver will usually locate the ECAM using the default range without a crash. System crashes typically occur only on a small number of systems. For more details about the service driver behavior and location of the ECAM, refer to the included PCI/PCIe SDK General FAQ document for capturing kernel driver debug output.
· Windows Drivers
· PCI/PCIe Service driver binaries for Windows 10 x64 and later versions is Digitally signed by Microsoft by way of Attestation signing to support Secure boot enabled environments.
· API
· Updated support for Aardvark I2C API v5.40. This is required for newer Aardvark USB drivers (v2.16+ for Win7,8 & v3.0+ for Win10).
· Added SPI flash API calls to read/write/erase flash
· Additional enhancements to Serial Debug Port (SDB) support for PEX 88000 devices. All devices now reported, including internal upstream/downstream, MPT, GEP, etc.
· PlxCm
· Added SPI commands to read/write/erase SPI flash
· Windows Drivers
· PCI/PCIe Service driver supports new registry options to control manual ECAM probe address range to avoid potential system crash. Driver Wizard updated to support the new options. Manual ECAM probe is disabled by default.
· Include a proprietary BrcmSC.exe utility which implements a subset of features of the default System Control (SC.exe) utility provided by Microsoft. Windows PE, however, does not ship with SC.exe, so the provided BrcmSC.exe may be used in its place to install and control the PCIe Service driver.
· PCI/PCIe Service driver now supports a manual probe for PCIe ECAM, which is invoked on UEFI systems so that the driver is able to support access to PCI config registers 100h+
· Linux Drivers
· Updated to support recent kernels (3.x, 4.x, 5.x)
· PCI/PCIe Service driver now ensures all PLX/Broadcom switch ports are in D0 power state. In some cases, newer Linux kernels are putting the ports into low power D3 state which prevents access to downstream device registers, making debug difficult.
· API
· Fixed issue with PlxPci_DeviceFind() not returning devices on bus FFh
· Add Serial Debug Port (SDB) and MDIO access native API support for PEX 88000 devices
· Add native API support for I2C for PEX 88000 devices
· Linux Drivers
· Fixed kernel crash when the API calls PlxPci_IoPortRead, PlxPci_IoPortWrite, PlxPci_PerformanceInitializeProperties, PlxPci_PerformanceGetCounters. This occurred on kernels that support Supervisor Mode Access Prevention (SMAP). PLX drivers, in the mentioned API calls, were directly accessing the passed-in user-mode buffer rather than using kernel copy_to_user()/copy_from_user() calls. SMAP support was added in kernel 3.7 and automatically enabled for hardware that supports it. It can be manually disabled via the kernel parameter nosmap.
· Windows Drivers
· Added detection of Windows 10
· Updated drivers to set additional No-execute flags for calls to ExAllocatePoolXxx() and MmMapMdlXxx() functions. These were newly added starting with Windows 8. The additional flags are only used in the calls if the OS is Win8 or higher to preserve backward compatibility. Refer to NonPagedPoolNx & MdlMappingNoExecute.
· Fixed issue with Power Management during lowering of device power state. The IRP status was being returned as STATUS_PENDING even though no further processing was needed.
· Fixed blue screen issue for legacy 9000 series in Windows 10. Issue occurs on resume from hibernate or when booting normally if Fast Boot Mode is enabled. PLX drivers were calling an OS delay function to allow chips a small amount of time to complete reset & reload EEPROM. The delay function causes an issue on Windows 10, so it was replaced with multiple benign chip register reads to emulate the delay.
· PLX 8000 NT Windows Driver
· Added support for 9700 series Non-Transparent endpoint
· Updated NT LUT add API to support newer LUT index access method Capella-1 & 2 devices
· PLX Service Driver
· Corrected port offset adjustment for switch upstream & downstream ports, which affected the PlxPci_PlxRegsiterRead/Write() API calls.
· PLX 8000 NT Windows Driver
· Fixed driver load crash. In some cases, the driver attempts to access BAR 0 before it was mapped to kernel space.
· Updates to support newer Linux kernels 3.x & 4.x
· Bugs Fixed
·
o [PLX
Windows 8000 NT Driver] Driver crashes system on initial load due to access
violation
The 8000 NT driver, during initialization, probes the device to determine additional
information. This probe involves access of PLX-specific registers within the
BAR0 space. The 8000 NT driver, however, attempted to access registers
before BAR0 is mapped to kernel space, resulting in an access violation error
& crashes the system.
Affected files: PlxSdk\Driver\Source.Plx8000_NT\Driver.c
· PLX API
o Changed ApiXXX return codes to new PLX_STATUS_XXX codes. Refer to PlxSdk/Include/PlxStat.h.
· PEX Device Editor (PDE) GUI
o Added support for 9700 series
o Various bug fixes & enhancements
· GenMon (Performance Monitor & Packet Generator)
o Added support for 9700 series & recent 8700 series not previously supported
o Revised interface to separate device list from packet generator dialog
· PLX Service Driver for Windows
o Added option to disable probe for the size of a non-PLX device’s BAR spaces to avoid issues if device is in-use
· [PEX Device Editor (PDE) GUI] Bug fixes & enhancements:
o Updated Databook register table information for Capella-1 devices – 8796, 8780, 8764, 8750, 8718
o Changed the PDE exe to prompt for admin password if running as an ordinary user.
o Fixed issue with high CPU usage, even when PDE was idle.
o Fixed memory leak, which caused PDE to become sluggish when opening too many screens.
o Fixed problem with time scale in Serdes Eye.
o Fixed issue with Serdes eye not working on stations other than station 0.
o Improved Serdes eye gradient plot.
o Fixed problem with Far end value in TxEq status.
o Added a filter to EEPROM browse dialog to filter entries by device ID.
o Added a checkbox to switch between local host or remote machine in Find Devices screen.
o Added extra space in System Tree View to prevent the tree from getting chopped.
o Fixed problem with Error/Warning dialogs blocking the GUI in some cases.
o Corrected formatting in probe mode output file
o Corrected warning message shown if PDE is not able to open probe mode output file.
· Bugs Fixed
o
[PLX Drivers] 8114 EEPROM Accesses to offsets 256B(100h) & higher
Since the 8114 doesn’t report EEPROM byte addressing in 206[23:22], PLX drivers
were mistakenly defaulting to 1B addressing, which limited accessible
offsets. Default is now 2B, which allows up to 64KB EEPROM access.
Affected files: PlxSdk\Driver\Source.Plx8000_NT\Eep_8000.c
PlxSdk\Driver\Source.PlxSvc\Eep_8000.c
PlxSdk\PlxApi\Eep_8000.c
· Added PLX driver support for Windows 8
· Added PLX driver support for Linux kernel 3.x. Support for kernel 2.4 has been removed from the PLX SDK.
· Support for Capella-1 family of Gen3 PLX devices – 8796, 8780, 8764, 8750, 8718
· [PEX Device Editor (PDE) GUI] Various updates & enhancements:
· The PDE has been rewritten in Java so that the same GUI will work under both Windows & Linux OS
· The PDE will prompt for a license file when it starts the first time after installation. The key is no longer entered during the SDK installation.
· Serdes Eye detection algorithm has been optimized
· Support for multiple Aardvark Controllers and cascaded I2C devices
· EEPROM Editor enhancements –
o Addition of multiple rows at a time
o Row duplication (with right click)
o “Remove All” option
· Option to start/stop the remote server process from the GUI. This will release I2C resources while the GUI is still open and allow other applications to connect to the I2C device (Will be available in Beta Release)
· Option to run GUI remotely on a different system from where the PLX Device is physically located
· [PLX SDK Installer] The PLX SDK installer will now fully install & update any existing PLX drivers dynamically. If a PLX compatible device is installed in the system, the installer will trigger Windows Plug ‘n’ Play system to load/update the driver for the device. During PLX SDK uninstall, the SDK will unload & uninstall existing SDK drivers. Drivers are migrated to the Windows DriverStore for future installation. For additional details, refer to the Microsoft Driver Package Installer (DPInst) documentation, as this is the tool the PLX SDK installer utilizes.
· [PLX SDK Directory Structure] The PLX SDK directory structure has changed slightly. All folders under PlxSdk\Windows & PlxSdk\Linux have been moved up one level. The new directory locations are now PlxSdk\Driver, PlxSdk\PlxApi, PlxSdk\Samples.
·
[PLX SDK Drivers Renamed] To avoid confusion, some PLX drivers
have been renamed for their respective functions. For example, many
customer assumed the “Plx8000” driver was for all PLX switches
when, in fact, it is only for the NT Endpoint in supported switches. The
changed drivers are:
Plx8000 à Plx8000_NT
PlxDma à Plx8000_DMA
Plx6000 à Plx6000_NT
· [PLX 8000 NT Linux Driver] Updated driver to use MSI interrupt instead of INTx if supported.
·
[PlxCm] Added ‘/b’ option to the eep_load
command to bypass data verification during EEPROM loading from a file. This
results in up to 50% performance increase during EEPROM programming, especially
through I2C mode. Note that using this means PlxCm will not perform a
read to verify whether EEPROM data was programmed correctly.
Example: eep_load MyEeprom.bin /b
·
[PlxCm] Added ‘dp’ command to dump PCI registers & ‘dr’
command to dump PLX-specific registers mapped behind BAR 0.
Usage: dp|dr [Start_offset]
<Byte_Count>
Examples: dp 0 40
- Dump standard PCI config registers 0-3Ch
dp 0 1000 - Dump entire PCI config
space of the selected device
dr 3000 1000 - Dump all 4KB of port 3 PLX-specific
registers
dr 2FB0 40 - Dump AER registers of port 2
· [Windows Samples] Added VS 2005 Solution files so the projects can be opened with newer versions of MS Visual Studio.
· [PlxDmaSglNoApi Sample] Updated this sample to support PLX 8000 DMA as well as 9000 DMA. Demonstrates manual SGL DMA setup.
· Add support for all Draco & Mira family of PLX devices.
· Draco – 8749, 8748, 8747, 8733, 8732, 8725, 8724, 8717, 8716, 8713, 8712.
· Mira – 8605, 8603, 3382, 3380 and 2380.
· DMA driver updated to support 8700 DMA.
· GenMon (Performance Monitor & Packet Generator) updated to support 8700
· Serdes Eye feature is supported for Draco family.
· PDE GUI in Linux is also available as a separate installation.
· This release includes minor bug fixes and updated Kernel Driver Code Authentication Certificates.
· Bugs Fixed
o [PDE] EEPROM data corruption when programming EEPROM from a file or saving data to a file. This affected 8508, 8512, 8517, 8518, 8524 & 8532.
o [PDE] Equalization Status screen for Draco series of devices (8712, 8716, 8724, 8732, 8747, 8748) had issues when reading certain lanes under different stations.
o
[PLX Linux Drivers] Updated Dispatch table to use unlocked_ioctl()
instead of ioctl()
In the driver dispatch table registration, the function ioctl()
was officially removed in 2.6.36 and replaced with unlocked_ioctl().
PLX drivers were updated to use the new interface. Older kernel versions
requiring the ioctl() interface are still supported through the use of #ifdef’s.
Refer to http://lwn.net/Articles/119652
for details.
Affected files:
PlxSdk\Linux\Driver\Source.<Driver_Name>\Dispatch.c/h
PlxSdk\Linux\Driver\Source.<Driver_Name>\Driver.c
· This release includes minor bug fixes and updated data book register tables for the PDE.
· Bugs Fixed
· Performance Monitor counters showed spurious counts and messed up the calculations. Added a software workaround to ignore spurious counts.
· Serdes Eye for gen3 devices were not working on lanes that are not in station zero.
· Added support for the PLX Scout and Draco family of Gen3 devices – 8700, 8748, 8747, 8732, 8724, 8716, 8712
· PEX Device Editor GUI supported on Linux (Separate download will be made available in Jan 2011)
· The PlxCm application command-line was updated to support the use of variables and simple arithmetic operations. For example, the command ‘dl v0+200’ is now legal and will read from BAR 0 offset 200h without the user needing to determine the virtual address.
· Performance Monitor updated for PLX PCIe Gen3 devices
· Packet Generator updated for PLX PCIe Gen3 devices
· Following additions to the PEX Device Editor (PDE) GUI application:
· Special GUI support for AHB register access
· Compare register dump text files
· Auto-detection of Requestor ID in the GUI for setting up Non-Transparent Mode
· Serdes Eye feature enhancements for Gen3 like Serdes Height, Gradient Plot, Time estimate etc.
· ”Remove All” option in Eeprom Editor screen.
· Option to Clear All errors in the Global error monitoring screen.
· All 85xx devices can be accessed with a single key.
· Probe Mode can read an output file in offline mode.
· Probe Mode output file names can be customized at the time of saving.
· Special screen to setup Transmit and Receive equalization parameters for Gen3 Serdes.
· Added a new Sample application that demonstrates fast transfer of data across 2 hosts connected over NT using DMA
· The GenMon Performance Monitor now allows manual re-size of the port statistics window
· Updated I2C in the PLX API to utilize the new aa_i2c_write_read() API call for reading a register. This requires the latest Aardvark drivers and firmware. Please refer to “PLX SDK and I2C” for details.
· Bugs Fixed
·
[PLX 8000 NT Windows Driver] Driver fails to distinguish between NT
Virtual and Link side
The PLX 8000 NT driver NT Virtual vs. Link detection algorithm was modified
in the previous SDK release to use a new algorithm for detection. The
algorithm involves PCI configuration reads of 3Ch. In some versions of
Windows, the OS returns an internally stored value for 3Ch instead of actually
performing a PCI configuration read. This resulted in incorrect data
received by the PLX driver.
The fix was to bypass the OS services for the PCI configuration access.
This always results in a PCI configuration read to obtain the correct register
value.
Affected files: PlxSdk\Window\Driver\Source.Plx8000\PlxChipFn.c
·
[PLX Windows Drivers] Possible OS crash during shutdown in a rare scenario
In some cases, Windows is not able to assign resources to the PLX
device. The PLX driver will get called by the OS to load, but no
IRP_MN_START message will get sent to the driver to inform it of device
resources. As a result, the PLX driver will not have mapped resources,
specifically to BAR 0 for register accesses. Device Manager will usually
report a message like “This device cannot find
enough resources that it can use. (Code 12)”. Windows then
prompts the user that the system must be rebooted for changes to take effect.
During a subsequent shutdown or hibernate, Windows sends power down messages to
the PLX driver. Normally, the PLX driver disables interrupts and saves
the device context (i.e. register contents). If the device was not previously
started, registers will not be accessible, but the PLX driver attempted the
access anyway, resulting in a system crash during the shutdown.
The fix was to bypass the PLX-specific device disable procedure if the device
had not yet been started.
Affected files: PlxSdk\Window\Driver\Source.Plx<DriverName>\Power.c
·
[PLX Linux Drivers] PLX drivers corrupt reference count in pci_dev
structure
In SDK 6.30, PLX Linux drivers were updated to use the new pci_get_*
kernel functions instead of the now deprecated pci_find_*
functions. The new functions update a reference count in the pci_dev
structure each time they are called. As a result, the driver is
responsible for decrementing the count with pci_dev_put() when it
no longer needs the pci_dev structure.
When PLX drivers scanned the bus with pci_get_device(), the
driver was also calling pci_dev_put() when it no longer needed pci_dev.
In this special case, however, it turns out pci_get_device() actually
decrements the reference count internally of the dev_from(3rd)
parameter. As a result, the PLX driver unnecessarily decremented the
reference count, eventually resulting in a kernel panic.
The fix involved removing the pci_dev_put() call in the cases
where pci_get_device() is used.
Affected files: PlxSdk\Linux\Driver\Source.PlxSvc\SupptFunc.c
PlxSdk\Linux\Driver\Source.Plx<DriverName>\Driver.c
·
[PLX Linux Drivers] Corrupt memory page reference count on DMA
cleanup during abnormal termination of app
When an application terminates, the PLX driver performs numerous cleanup
operations. If a DMA is in-progress and was started by the terminating
application, the PLX driver aborts the DMA. In cases where an SGL DMA is
pending (PlxPci_TransferUserBuffer() called), additional cleanup
is required to unlock and release buffers pages.
If the app terminates during a long DMA transfer, the DMA abort may trigger a
DMA done interrupt. This, in turn, calls the SGL DMA cleanup
routine. Additionally, the DMA close operation also called the SGL DMA
cleanup. The result is multiple instances of the cleanup routine running
and corrupting the buffer pages reference count.
The fix involves a short sleep after the DMA close routine aborts the
DMA. This allows time for the DMA interrupt to occur and for the driver
DPC routine to perform SGL cleanup. The DMA close routine will then not
need to perform additional cleanup.
Affected files: PlxSdk\Linux\Driver\Source.PlxDma\ApiFunc.c
PlxSdk\Linux\Driver\Source.Plx9000\Chip\9080\PlxChipApi.c
PlxSdk\Linux\Driver\Source.Plx9000\Chip\9054\PlxChipApi.c
PlxSdk\Linux\Driver\Source.Plx9000\Chip\9056\PlxChipApi.c
PlxSdk\Linux\Driver\Source.Plx9000\Chip\9656\PlxChipApi.c
PlxSdk\Linux\Driver\Source.Plx9000\Chip\8311\PlxChipApi.c
·
[PLX Linux Drivers] PLX drivers improper use of ISR spin lock for
generic local-to-PCI interrupt
For PLX 9000 series drivers, when the generic Local-to-PCI interrupt is
detected, the PLX driver masks it in the Interrupt Control/Status register in
the DPC routine. To avoid conflicts with the ISR, a spin lock is used.
The DPC routine used the kernel function spin_lock(), which
doesn’t save IRQ state. On an SMP system, the DPC could execute at the
same time as another thread modifying the interrupt CSR to enable the
interrupt. This race condition could cause system lockup.
The fix involved replacing the call to spin_lock() with spin_lock_irqsave(),
which correctly saved the IRQ state and prevents corruption.
Additionally, all PLX ISRs were modified to use spin_lock() instead
of spin_lock_irqsave(),which results in a slight performance
improvement. Since IRQ state is automatically saved during ISR execution,
there is no need for the PLX driver to save the state again.
Affected files: PlxSdk\Linux\Driver\Source.Plx<DriverName>\PlxInterrupt.c
PlxSdk\Linux\Driver\Source.Plx9000\<PlxChip>\PlxInterrupt.c
· Added support for the PLX 8625 and 8636 switches.
· Latest versions of Sirius and Cygnus databook register tables have been updated in the PDE GUI application.
· Added support in the NT kernel drivers for Lane Status Change Interrupts.
· Added an option in the Serdes Eye screen of PDE GUI to support Lane reversal. This support is only available for Sirius and Cygnus devices namely - 8619, 8615, 8609, 8618, 8617, 8614, 8613, 8608, 8606, 8604, 8696, 8680, 8664, 8649, 8636 & 8625.
· Added support for the new multi-root PLX 8600 switches namely 8696, 8680, 8664 and 8649. Over and above the basic features like Eeprom, Memory mapped access & Config access, this includes support for all Cygnus special features like Serdes Eye, Performance Monitor, and Multi-root.
· Added support for PLX 8600 switches that contain DMA engines namely 8619, 8615, and 8609
· Added support for the BA revisions of 8618, 8617, 8614, 8613, 8608, 8606, and 8604.
· Added basic support for Multi-root switch 8696
· Following additions to the PEX Device Editor (PDE) GUI application:
· Save data from eeprom diff screen to a text file.
· Dynamic update of Lane status panel
· PCI Capabilities for Non-PLX devices
· I2C Improvements:
- Simplified I2C device search screen
- When PDE is first started it will automatically scan for any I2C devices connected. If found they will appear in the Device Selector on the left side of the GUI screen.
· Global Error detector and indicator
· Display all error registers when needed
· NT type (Virtual/Link) in Lane status panel
· Tree View of all PCI/PCIe devices in the system
· PlxCm now supports an ‘I2C’ command to access PLX switches over I2C.
· Following changes were done to the GenMon Application:
· Added logging performance data to a text file
· Running average of Payload byte rate
· PLX API and Type Changes: SDK 6.10 includes some API and data type/structure changes that affect applications written with a previous SDK version. The following is a general list of changes. For additional API or structure details, please refer to the PLX SDK User’s Manual. The majority of the changes are related to the PLX DMA API functions to properly support the new DMA controller in PLX 8600 switches.
· PlxPci_PciRegisterRead_Unsupported renamed to PlxPci_PciRegisterRead_BypassOS
· PlxPci_PciRegisterWrite_Unsupported renamed to PlxPci_PciRegisterWrite_BypassOS
· PlxPci_ChipTypeGet and PlxPci_ChipTypeSet - ChipType parameter changed from 32-bit to 16-bit
· Added PlxPci_DmaGetProperties and PlxPci_DmaSetProperties. This allows for a more flexible and simpler use of controlling the DMA controller’s properties.
· PLX_INTERRUPT structure was modified to consolidate interrupts of the same type. For example, instead of having separate fields for a DMA channel (e.g. DmaDone_0, DmaDone_1, etc), a field is now specified by the number of bits (e.g. DmaDone:4). Bit positions correspond to the channel number, i.e. bit 0 = DMA channel 0, bit 1 = DMA channel 1, etc. The same principle applies to other interrupt fields, such as LocalàPCI interrupt, Message, DMA error, etc. Note that many interrupt field names have been changed.
· PLX_DMA_PROP structure was modified to add fields that support 8600 DMA
· PLX_DMA_PARAMS structure was modified to simplify programming the DMA. The structure now accepts 64-bit addresses in a single field. Some fields apply only to 9000 DMA controllers (e.g. LocalAddr) and some apply only to 8600 DMA (e.g. AddrSource).
· The PLX Linux package was modified to also support Big Endian CPUs, typically used in embedded platforms (e.g. MIPS, PPC)
·
[PLX 8000 NT Drivers] Driver failed to distinguish between NT Virtual
and Link side
The PLX 8000 NT driver NT Virtual vs. Link detection algorithm was modified
in the previous SDK release to use the internal NT Link BAR register as part of
the detection. The algorithm, however, was executed before the driver
mapped BAR 0 for access to the internal registers. As a result, internal
register accesses were not yet possible and the algorithm defaulted to the NT
Virtual side.
The fix involved moving the NT detection algorithm after the driver maps BAR 0
for accesses to internal registers.
Affected files: PlxSdk\<Windows> or
<Linux>\Driver\Source.Plx8000\Driver.c
·
[PLX API] Fixed issue with connecting to a device over I2C and the
upstream is not port 0
The I2C portion of the PLX API was not able to properly probe a PLX switch
it was connected to if the upstream port is set to be other than port 0.
The PLX API now first probes some registers in the switch to determine which
port is upstream to obtain the required information needed to probe remaining
ports.
Affected files: PlxSdk\<Windows> or
<Linux>\PlxApi\PlxApiI2cAa.c
·
[PLX Linux Drivers] Spinlock held when a device is started could
cause kernel panic
PLX Linux PnP drivers support starting/stopping of devices when they are
selected/released. When a device is started, the PLX driver holds a
spinlock to ensure it’s the only thread that is starting/stopping the
device. During the start procedure, some kernel calls could sleep, which
could result in a deadlock since a spinlock is held. If the kernel is
built with the flag CONFIG_DEBUG_SPINLOCK_SLEEP, a kernel error
is displayed similar to “BUG: sleeping function called from invalid
context at…”.
The fix involved replacing the spinlock with a mutex. PLX drivers now
hold a mutex instead of a spinlock during device start/stop.
Affected files: PlxSdk\Linux\Driver\Source.Plx<DriverName>\DrvDefs.h
PlxSdk\Linux\Driver\Source.Plx<DriverName>\Dispatch.c
PlxSdk\Linux\Driver\Source.Plx<DriverName>\Driver.c
·
[PLX Linux Drivers] Kernel panic when cancelling a sleeping PLX
Notification object from another thread
In a multi-threaded application, if one thread is sleeping (PlxPci_NotificationWait)
and another thread cancels the same object (PlxPci_NotificationCancel),
a kernel panic will arise. The cancel routine releases the kernel memory
for the wait object before the sleeping thread wakes up and exits. The
sleeping thread could still access the object after it wakes.
The fix involved some synchronization between the cancel thread and any other
thread that is sleeping. An atomic counter was added to the object to
keep track of the number of sleeping threads on it. Additionally, the
object’s state is now kept track of. If it is marked for deletion, it
will not be used any further in threads wishing to wait. If other threads
are sleeping on the object, the cancel thread wakes them up, relinquishes its
CPU time slice for the other threads to wake, then frees the wait object.
Affected files: PlxSdk\Linux\Driver\Source.Plx<DriverName>\DrvDefs.h
PlxSdk\Linux\Driver\Source.Plx<DriverName>\ApiFunc.c
PlxSdk\Linux\Driver\Source.Plx<DriverName>\SuppFunc.c
· Added support for the new PLX PCIe Gen-2 devices (8618, 8617, 8614, 8608, 8607, 8606, 8605, 8604, 8603)
· Updates to Performance Monitor and Packet Generator.
· Following additions to the PEX Device Editor GUI application:
· Serdes Eye feature enhancements
· Default to last known revision for any new device revisions.
· Lane status panel enhancements.
· EEPROM editor ensures register 1DC is always the first register.
· Updates to Probe Mode feature (For internal Debug only)
· Windows Vista 64-bit Kernel Driver Signing has been implemented.
· [Linux Applications] The Curses library is no longer used in PLX Linux applications. Some console functions were re-written using calls to the TTY driver, which eliminated the need for the [n]curses console library.
·
[Windows Drivers] Windows Power Management code in PLX drivers
updated
The Power Management code in all PLX drivers has been completely
re-written. This fixed numerous issues and limitations with the Power
Management code. The PM modules also contain updates to handle the PM
changes introduced with Vista.
Affected files: PlxSdk\Windows\Driver\Source.Plx6000\Power.c
PlxSdk\Windows\Driver\Source.Plx8000\Power.c
PlxSdk\Windows\Driver\Source.Plx9000\Power.c
·
[Windows Drivers] Removed 64MB Mapping Limitation of PLX Physical
Memory to User Space
Due to a limitation with Windows Memory Descriptor List (MDL) structures,
mappings of PLX allocated DMA buffers to user space were limited to ~64MB in
32-bit Windows and ~32MB in 64-bit Windows. This affected the API calls PlxPci_PhysicalMemoryMap()
and PlxPci_CommonBufferMap() if the respective buffer exceeded the
mapping limitation.
To resolve this issue, PLX drivers now limit the mapping of an MDL to ~62MB but
map multiple MDLs to cover the entire size of the buffer. MDLs are
chained together using a Next field already provided in the
structure. This assures proper unmapping and cleanup later.
Note: Mappings may still fail if Windows does not have enough
Page-Table Entries (PTE) to perform a mapping.
Affected files: PlxSdk\Windows\Driver\Source.Plx6000\ApiFunc.c
PlxSdk\Windows\Driver\Source.Plx6000\SuppFunc.c
PlxSdk\Windows\Driver\Source.Plx8000\ApiFunc.c
PlxSdk\Windows\Driver\Source.Plx8000\SuppFunc.c
PlxSdk\Windows\Driver\Source.Plx9000\ApiFunc.c
PlxSdk\Windows\Driver\Source.Plx9000\SuppFunc.c
·
[Linux Drivers] Resolved Race Condition between DPC Routine and
Driver Stopping a Device
In PLX Linux drivers, a race condition existed if the device asserts an
interrupt at the same time the driver is stopping the device. If an
application terminates and the device is not being used by any other
application, the PLX driver automatically stops the device, which includes the
release of resources. If the device has a pending interrupt, the ISR
could trigger and schedule a DPC task to complete interrupt processing.
The DPC could start to execute after the driver stopped the device, which
caused a kernel panic because kernel mapping for register access were released.
To resolve this issue, some synchronization was added between the main driver
code and the ISR/DPC routines. Before the device is about to be stopped,
the driver sets a flag informing the ISR not to schedule any more DPC
tasks. If a DPC is already pending, the main driver waits until it
completes before releasing resources. The DPC also includes an error
check to make sure that the device registers are accessible before continuing;
otherwise, it aborts.
Affected files: PlxSdk\Linux\Driver\Source.Plx6000\Driver.c
PlxSdk\Linux\Driver\Source.Plx6000\DrvDefs.h
PlxSdk\Linux\Driver\Source.Plx6000\PlxInterrupt.c
PlxSdk\Linux\Driver\Source.Plx8000\Driver.c
PlxSdk\Linux\Driver\Source.Plx8000\DrvDefs.h
PlxSdk\Linux\Driver\Source.Plx8000\PlxInterrupt.c
PlxSdk\Linux\Driver\Source.Plx9000\Driver.c
PlxSdk\Linux\Driver\Source.Plx9000\DrvDefs.h
PlxSdk\Linux\Driver\Source.Plx9000\PlxInterrupt.c
·
[Linux Drivers] PlxPci_DeviceFind Failed when Searching non-Primary
device using Subsystem ID as Criteria
When PlxPci_DeviceFind() is called, the PLX drivers compares the
information provided with the properties of each device the driver
manages. When the driver starts, it scans for supported devices and fills
in the PLX_DEVICE_KEY for each one. The Subsystem ID and PCI Revision,
however, were only determined for the first device found. If an
application attempted to search for one of these devices using the Subsystem ID
or PCI Revision as search criteria, the search always failed.
To resolve this issue, the subsystem ID and PCI revision fields are now filled
in the PLX_DEVICE_KEY when every supported device is detected.
Affected files: PlxSdk\Linux\Driver\Source.Plx6000\Driver.c
PlxSdk\Linux\Driver\Source.Plx8000\Driver.c
PlxSdk\Linux\Driver\Source.Plx9000\Driver.c
· Added I2C support to the PLX GenMon utility.
· Windows PLX Service driver now supports allocation of PCI buffers (PlxPci_CommonBufferXxx & PlxPci_PhysicalMemoryXxx API calls)
· Added native support for I2C into the Windows PLX API. Only Aardvark USB I2C is currently supported.
· Updated PLX GenMon (previously called “PLX Exerciser”). GenMon is a utility that allows control of the Packet Generator and Performance Counters found only in PLX 8600 series devices. The Performance Monitor may be executed without running the Packet Generator and includes graphical depiction of PCI Express performance for each active port.
· Some minor internal changes to Serdes Eye feature.
· Updated Probe Mode feature to use internal Mode and capture data from Debug RAM. This is for Internal Debug purposes only.
· Enabled Port-4 in the PEX Device Editor for 8624, 8616 & 8612.
· Different levels of device access based on the NDA signed with PLX.
· Added support for PLX 8600 devices.
· Added Packet Generator application
· Added the following new features in the PDE GUI application:
· Serdes Eye Width (For 8600 series only)
· Performance Monitoring (For 8600 series only)
· Save Memory Mapped Screen Data to text file and read back from text file in offline mode
· Enhancements to Eeprom Diff tool
· Probe Mode for Internal Debugging purposes(For 8600 series only)
· For PLX Windows drivers, the debug version of the drivers may be configured to dump debug log messages to a file instead of relying on a connected Windows debugger (e.g. over serial connection). To enable this feature, the driver must be rebuilt after enabling the #define PLX_LOG_TO_FILE statement in the respective DriverDefs.h driver file or by setting PLX_LOG_TO_FILE=1 in the environment variables.
· Bugs Fixed
·
[Windows Drivers] System Crash (blue screen) in Windows Vista during
Hibernate or Shutdown
When Windows Vista is powered off either because the user selected
Hibernate or Shutdown, the system crashed and resulted in a BSOD. This
has been determined as a PLX driver issue in the Power Management code.
In SDK 5.20, when the PLX driver receives the power message IRP_MN_SET_POWER,
the driver ignores the message if the system is going into Hibernate or
Shutdown state.
Affected files: PlxSdk\Windows\Driver\Source.Plx6000\Power.c
PlxSdk\Windows\Driver\Source.Plx8000\Power.c
PlxSdk\Windows\Driver\Source.Plx9000\Power.c
·
[9000-series Windows Drivers] PlxPci_DmaTransferUserBuffer sometimes
doesn’t transfer all data properly on Windows 2003 Server with 3GB or more RAM
If Windows 2003 Server 32-bit edition is used on a system with 3GB or more
installed system RAM, the PLX API call PlxPci_DmaTransferUserBuffer()
may not properly transfer all parts of the supplied buffer. Although this
is a 32-bit version of Windows, it was determined that some pages of the
user-mode buffer reside outside the 32-bit addressable region. When the
PLX drivers setup the SGL descriptors to transfer the buffer, the upper 32-bits
of the user page’s physical address was ignored.
To resolve this issue, the PLX driver first parses all the physical page
addresses that describe the user buffer to determine if 64-bit addressing is
required. If at least one page requires an address greater than 32-bits,
the PLX driver enables DMA Dual-Addressing in the PLX chip and creates 32-byte
Dual-Addressing descriptors for the transfer. If only 32-bits are
required, the standard 16-byte descriptor format is used and Dual-Addressing is
disabled.
Affected files: PlxSdk\Windows\Driver\Source.Plx9000\SuppFunc.h
PlxSdk\Windows\Driver\Source.Plx9000\SuppFunc.c
PlxSdk\Windows\Driver\Source.Plx9000\Chip\9080\PlxChipApi.c
PlxSdk\Windows\Driver\Source.Plx9000\Chip\9054\PlxChipApi.c
PlxSdk\Windows\Driver\Source.Plx9000\Chip\9056\PlxChipApi.c
PlxSdk\Windows\Driver\Source.Plx9000\Chip\9656\PlxChipApi.c
PlxSdk\Windows\Driver\Source.Plx9000\Chip\8311\PlxChipApi.c
Note: The PLX 9080 device does not support DMA Dual-addressing. If
the PLX 9080 driver detects that 64-bit DMA is required for a particular
transfer, it will return an error of ApiUnsupportedFunction.
·
[Windows PLX API] PlxPci_NotificationStatus API doesn’t work
The PLX API call PlxPci_NotificationStatus had an issue in that it
sent the incorrect information to the PLX driver to query the status of the
notification object. The API call was updated to resolve this issue.
Affected files: PlxSdk\Windows\PlxApi\PlxApi.c
· Added
support for new devices and revisions
Support for new devices and revisions was added (i.e. 8112 & 8500 series).
· Added
Support for Windows Vista (32-bit only)
The PLX SDK has been tested with and now supports Windows Vista 32-bit.
Vista 64-bit requires signed drivers, which PLX drivers are not currently.
· PCI
SDK & PCI Express (PEX) SDK Merger
As of PLX SDK v5.0, the PLX PCI SDK and PLX PEX SDK are now merged into the PLX
SDK. The PLX SDK maintains only a single PLX API (i.e. PlxPci_Xxx)
and supports all PLX 9000, 6000, & 8000 series devices. The PLX API traditionally
used for PLX 9000 devices has been deprecated and is no longer supported.
There is an API translation layer provided in the PLX SDK called PlxLegacyApi
to allow existing applications to run. It is recommended that
applications are ported to use the newer API.
· PEX Device Editor GUI Feature additions
o All Memory mapped, Config register and Eeprom features are available through the I2C. Users of this feature will need to get a USB to I2C device from TotalPhase and install its drivers in the system before they can use this feature.
o All the register table information from the Databooks have been integrated into the PEX Device editor.
o Added Set Chip Type feature which allows a device that shows up as a non-PLX device to be set to a particular PLX chip type.
o Eeprom diff can be done for Altair and 8111 devices too.
o Some columns can be hidden from view in the PEX Device Editor GUI.
o The Eeprom Editor GUI screen now shows the CRC value and whether it is correct or not. There is also a button to update the CRC after any changes are made to the Eeprom locations.
· PLX
Windows Drivers Increased Write Performance for Prefetchable BAR Spaces
Refer to 9. Increase Host CPU Write (“Direct Slave”) Performance to PLX 9000
& 8000 BAR Spaces.
· Bugs Fixed
o
[PLX 9000 Drivers] DMA engine not halted if application terminates
abnormally
When an application terminates or closes a PLX device, the PLX driver
contained cleanup code to release resources owned by the application, including
the closing of DMA channels. If an SGL DMA transfer was still in
progress, this could result in an unstable system because the PLX driver would
release the SGL descriptor buffer as well as unlock the pages of the user-mode
buffer. If the DMA engine continued to transfer data, it could then
corrupt system memory that it no longer owned.
In SDK 5.0, the DMA channel close functions were revised to additionally abort the
DMA transfer before releasing any resources used by the DMA. This halts
the DMA engine from transferring any more data and corrupting system memory.
Affected files: PlxSdk\<Windows or
Linux>\Driver\Source.Plx9000\Chip\9080\PlxChipApi.c
PlxSdk\<Windows or Linux>\Driver\Source.Plx9000\Chip\9054\PlxChipApi.c
PlxSdk\<Windows or Linux>\Driver\Source.Plx9000\Chip\9056\PlxChipApi.c
PlxSdk\<Windows or Linux>\Driver\Source.Plx9000\Chip\9656\PlxChipApi.c
PlxSdk\<Windows or Linux>\Driver\Source.Plx9000\Chip\8311\PlxChipApi.c
o
[Windows Driver] SGL descriptor build code incorrect parsing of
physical page list on Windows x64
When an application calls PlxDmaSglTransfer, the PLX driver
page-locks the passed user-mode buffer and determines its physical page
addresses to build the SGL descriptors for the DMA engine. The page list
is located after the MDL structure that describes the user-mode buffer.
The PLX driver always assumed the page list was a series of 32-bit values;
however, on Windows x64, the pages are specified as 64-bit values, even though
the upper 32-bits are always 0. As a result, the PLX 64-bit driver would
not get the correct page list.
The PLX driver was modified to use 32-bit or 64-bit page list depending upon
which version of the driver was built.
Affected files: PlxSdk\Windows\Driver\Source.Plx9000\SupportFunc.c
o
[Linux Drivers]: Fixed global namespace conflict of PLX global driver
object between PLX drivers
In the PLX Linux drivers, the drivers create a global DRIVER_OBJECT that
manages all the devices assigned to the driver. To access this object,
the drivers referred to the global variable pGbl_DriverObject.
It turns out, however, that this variable ended up in the global
namespace. If two or more PLX drivers are loaded at the same time, such
as a 9054 and 9030, they would end up referencing the same DRIVER_OBJECT
variable. Once one of the drivers was uninstalled, it released the DRIVER_OBJECT
memory and prevents the other PLX driver from functioning properly.
To resolve this issue, each PLX driver was given a unique name for its global
object pointer based on the chip type. During compilation, the global
variable takes on a name like pGbl_DriverObject_9054, pGbl_DriverObject_9030,
or pGbl_DriverObject_8000. With a unique pointer name for
each driver, the namespace conflict was resolved.
Affected files: PlxSdk\Linux\Driver\Source.9000\DriverDefs.h
PlxSdk\Linux\Driver\Source.9000\Driver.c
· Various bug fixes and new API calls added
· Introduced the PEX Device Editor GUI
· Replaced DAPI & PAM architecture from PEX SDK v1.x with PLX API and driver.
· 64-bit Windows & Linux drivers for PLX 8000 devices
· Support
for Linux Kernel 2.6
PLX PCI SDK 4.40 now supports Linux kernel 2.6 in addition to kernel 2.4.
Linux kernel 2.2 is no longer supported. Please refer to the PLX Linux Host
Support Release Notes for additional information.
· Support for 64-bit Windows & Linux
PLX PCI SDK 4.40 now supports 64-bit Windows & Linux
platforms. For Windows, the PLX drivers have only been tested with x64 on
an AMD64 system running Windows x64. The Linux drivers were also tested
on an x64 system, as well as an IA64 system (SGI Altrix 350). PLX source
code remains consistent between 32-bit & 64-bit. The same source is
used to build drivers for either environment. Please refer to the PLX SDK
User’s Manual for additional information.
· Added Support for 8111,
8311, & 6466 Devices
Added support for new chips including the PLX 8111, 8311, and
6466. This includes support in PLXMon, as well as API support in PLX
Windows & Linux drivers. For the PLX 8111, the PLX PCI Service driver
will probe the system ACPI tables to search for PCI Express Enhanced
Configuration Access Mechanism (ECAM) address. If found, this will be
used to access PCI Express registers (offsets >= 100h), since current Windows
& Linux versions do not support PCI Express registers.
Note: The 8311 will show up as 2 devices in PLXMon. The
first will be an 8111 and the second will be an 8311.
· Added a Simple GUI
Application for Windows
A very simple Graphical User Application (GUI) application was added to
the SDK for Windows. This provides an example of how to call the PLX API
from within a GUI. The app was created with Visual C++ and uses
MFC. It is located in PciSdk\Windows\Samples\SampleAppGUI.
· Added new PCI register
“Fast” API functions
In previous SDK, when a PCI configuration register was accessed with
the API (e.g. PlxPci_PciRegisterRead), the PLX API had to scan the system each
time in an effort to connect to an existing PLX driver, even if a device was already
open. To minimize the overhead, new PLX API functions were added that
accept a PLX_DEVICE_OBJECT instead of the bus/slot/function combination.
In the new functions, the API simply submits the request to the active driver
instead of scanning the system for an available one.
Please refer to the PCI SDK Programmer’s Reference Manual for additional
details. The new functions are:
PlxPciRegisterReadFast
PlxPciRegisterWriteFast
PlxPci_PciRegisterReadFast
PlxPci_PciRegisterWriteFast
· Removed Windows Driver SGL
Limitation (MaxSglTransferSize option)
In previous PLX SDK releases, the driver referred to a MaxSglTransferSize
parameter either in the registry or reverted to a default value. This
option was used by the PLX driver to pre-allocate enough resources to be used
when applications call the PLX API PlxDmaSglTransfer. Depending
upon the SDK version, the default setting was either 1MB or 3MB, which means
buffers larger than this size could not be transferred without modifying the
registry followed by a reboot.
In SDK 4.4, the SGL build code in the Windows driver was re-written to now use
dynamically allocated buffers, which could later be re-used if large
enough. This modification eliminated the need for MaxSglTransferSize
and results in improved performance. The PLX Linux driver already works
this way.
Note: SGL transfers are still limited to approximately 63MB due to
a limitation in Windows Memory Descriptor Lists (MDL).
o
[Linux Driver] System sometimes hangs when device is closed on
kernels 2.6.15 & up
On kernels 2.6.15 & higher, if an applications calls either PlxPciBarMap()
or PlxPciPhysicalMemoryAllocate(), the system completely freezes when
the device is closed or the app terminates. It was determined that this
occurs if the driver calls remap_pfn_range outside the PLX driver’s Dispatch_mmap()
routine. The kernel Virtual Memory subsystem underwent quit a few changes
in kernel 2.6.15, which caused a problem with the PLX driver.
The fix involved moving the calls to remap_pfn_range into the Dispatch_mmap()
routine. The PLX API was modified to accommodate for the new mapping
protocol.
Affected files: PlxLinux\Linux\Api\PciApi.c
PlxLinux\Linux\Driver\Common\Dispatch.c
PlxLinux\Linux\Driver\Common.6000\Dispatch.c
PlxLinux\Linux\Driver\Common\SupportFunc.c
PlxLinux\Linux\Driver\Common.6000\SupportFunc.c
o
[Windows Driver] PLX driver internal SGL buffer memory leak
In previous PLX SDKs, the PLX driver managed an internal buffer which was used
to temporarily hold SGL descriptors when PlxDmaSglTransfer was
called. It turns out that the PLX memory management routines contained a
memory leak because they failed to release memory properly. After
numerous SGL transfers, the buffer could eventually report insufficient
resources for a new transfer request.
Since the SDK 4.4 SGL code was completely re-written, PLX drivers no longer use
the PLX internal buffer management. As a result, the memory leak is no
longer an issue starting with SDK 4.4.
o
[Windows Driver] IRP status not set properly when IRP_MN_SET_POWER
received
When the PLX WDM driver receives an IRP_MN_SET_POWER message, it sets the device’s
power state by sending another message to itself to set the device’s power
state.. The problem is that when a new IRP is created, the status was not
initialized to STATUS_NOT_SUPPORTED, which is required. Although this
does not cause a problem in most systems, those with the Microsoft Driver
Verifier tool installed could result in a system bug check (blue screen) due to
the Driver Verifier flagging the error.
This was fixed by simply initializing the newly created IRP’s status to
STATUS_NOT_SUPPORTED.
Affected files: PciSdk\Windows\Driver\Common\Wdm\Power.c
PciSdk\Windows\Driver\Common.6000\Wdm\Power.c
o
[Windows PLX INF File] On certain Windows 2000 systems, the PLX
device driver won’t install
In some cases on Windows 2000 systems, the PLX driver will not be installed
even though Windows 2000 processes the PLX INF file properly. This tends
to happen on systems which have had the PLX driver added and removed multiple
times.
It was found that Windows 2000 INF parser sometimes has an issue if the
device’s Class GUID is not specified in the INF. Since PLX drivers are
generic, the devices fall into the “Unknown” class of devices, which is
specified in the INF. The GUID, however, was not specified. The fix
was to set the ClassGuid.directive to the GUID for the unknown
class of devices. For those interested, the GUID is {4d36e97e-e325-11ce-bfc1-08002be10318}.
Affected files: PciSdk\Windows\Driver\Wdm\PciSdk.inf
· Windows
98/Me Support for the PLX PCI 6000 Series PCI-to-PCI Bridge Chips
SDK 4.20 introduced support for the PLX PCI 6000 family of PCI-to-PCI bridge
chips, but only for the Windows NT/2000/XP operating systems. SDK 4.30
now includes support for PCI 6000 series for Windows 98/Me. The driver is
a generic PLX PCI Service VxD that will be installed by the SDK
installation. The new driver supports the complete PCI 6000 PLX API and
the latest version of PLXMon.
· Non-Transparent
Mode Windows and Linux Drivers for the PLX PCI 6254 and 6540 Chips
New drivers are included to support the PLX PCI-to-PCI bridge chips
that support non-transparent mode. Drivers are provided for Windows and
Linux.
· PLXMon
Performance Measure Dialog
PLXMon v4.3 introduces a new Performance Measure Dialog. The
dialog will perform DMA or Direct Slave transfers to/from the local bus and
then provides a software measure of the transfer rate. By setting
different options in the chip, such as burst or read-ahead, the relative impact
on performance can then be measured to obtain optimal performance. Refer
to the PLXMon section of the SDK User’s Manual for more information.
· Updated PLX Driver Options
Wizard
The PLX Driver Options Wizard has been updated to work in all versions
of Windows and now supports configuration of all available options for PLX
drivers. Users should no longer need to manually modify the
registry. Refer to the SDK User’s Manual for additional details.
· New
PCI 9000-Series Interrupt Notification API Functions
SDK 4.3 introduces a new interrupt notification model, which improves
performance and stability. The functions PlxIntrAttach and PlxIntrWait
have been removed and replaced with the functions PlxNotificationRegisterFor,
PlxNotificationCancel, and PlxNotificationWait. With the
new functions, registration for interrupt notification need only be done once
and application signaling by the driver has been simplified, resulting in
improved performance. Refer to the details of these functions in the
SDK Programmer’s Reference Manual.
· Bugs Fixed
o
[Windows & Linux Drivers]: Fixed SGL keep local address constant
flag does not get cleared once set
For all PLX master devices that contain a DMA engine, the PLX SDK includes API
functions to support SGL mode operation. One of the options for SGL mode
is to keep the local address constant, which the PLX driver stores internally
as a flag when the DMA channel is opened. When the PLX driver builds SGL
descriptors, it will use this flag to determine whether the local address
should be incremented or remain constant.
The problem occurs when the SGL DMA channel is first opened with the keep local
address constant option enabled, which causes the driver to update its internal
flag. If the SGL channel is later opened with the option disabled, the
PLX driver fails to clear the flag. So, once the flag is set, it could
never be cleared.
The fix was simply to add code that clears the flag if the option is
disabled. This is added to the PlxSglDmaChannelOpen API in the PLX
driver.
Affected files: PciSdk\Windows\Driver\Common\PlxChip\Pci9080\ApiFunctions.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9054\ApiFunctions.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9056\ApiFunctions.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9656\ApiFunctions.c
PlxLinux\linux\driver\common\PlxChip\Pci9080\ApiFunctions.c
PlxLinux\linux\driver\common\PlxChip\Pci9054\ApiFunctions.c
PlxLinux\linux\driver\common\PlxChip\Pci9056\ApiFunctions.c
PlxLinux\linux\driver\common\PlxChip\Pci9656\ApiFunctions.c
o
[InterruptEvent Sample Application]: Fixed interrupt not triggered
properly for 9050/9052/9030 chips
The InterruptEvent sample application demonstrates how to wait for an
interrupt with the SDK API. For the PLX 9050/9052/9030 chips, the sample
waits for local interrupt 1 to trigger. The sample manually triggers the
interrupt by inverting the polarity bits. The problem occurs when the
polarity is already in a triggered state, so the sample actually halts the
interrupt.
The fix is to first put the polarity in a state that de-activates the interrupt
before inverting it.
Affected files: PciSdk\Windows\Samples\IntEvt\IntEvt.c
PlxLinux\Samples\InterruptEvent\InterruptEvent.c
· Windows
Support for the PLX PCI 6000 Series PCI-to-PCI Bridge Chips
SDK 4.20 introduces support for the PLX PCI 6000 family of PCI-to-PCI bridge
chips. The Windows support includes a generic PLX PCI service driver and
an updated version of PLXMon, which now supports the PCI 6000 series. A
new PCI host API is added to support the features of the new driver.
PLXMon (through the driver) contains new dialogs to view and modify the PCI
6000 PCI registers and configuration EEPROM values.
· Linux
Support for the PLX PCI 6000 Series PCI-to-PCI Bridge Chips
Linux support for the PLX PCI 6000 family of PCI-to-PCI bridge chips is also
included in SDK 4.20. The Linux support includes a generic PLX PCI
service driver, which supports the new PCI host API. The API contains
function to read and write to the PCI 6000 PCI registers and configuration
EEPROM values.
· Bugs Fixed
o
[Windows Drivers]: Fixed limitation of mapping large PCI BAR spaces
to user virtual space
In Windows systems, in order to map a PCI BAR space into user virtual space, a
Memory Descriptor List (MDL) must first be allocated to describe the
buffer. Although it is not documented in the Windows DDK, it turns out
there is a limitation on the amount of memory a single MDL can describe.
This is due to the fact that IoAllocateMdl only allocates 64k for
the MDL structure and the list of physical page pointers. Typically,
Windows uses 4k pages sizes, which limits the MDL to describe just under 64MB.
The PLX driver works around this issue by creating multiple MDLs for large
buffers. The MDL structure already contains a Next field,
which the PLX driver uses to link the MDLs. Additional code was also
added to properly free all MDLs and map and unmap all MDLs for a PCI space.
Affected files: PciSdk\Windows\Driver\Common\DriverDefs.h
PciSdk\Windows\Driver\Common\CommonApi.c
PciSdk\Windows\Driver\Common\SupportFunc.c
o
[Windows Drivers]: Fixed incorrect unmapping of user-mode virtual
addresses to the Common Buffer
When an application calls PlxPciCommonBufferMap, the PLX driver provides
a user-mode virtual address that the application can use to access the
buffer. The driver stores the mapping information in an internal list to
ensure proper cleanup if the application does not eventually call PlxPciCommonBufferUnmap.
On some systems, if multiple applications call PlxPciCommonBufferMap,
the assigned virtual address may be identical between one or more applications.
When the application calls PlxPciCommonBufferUnmap to unmap the address,
the driver searches its internal list to locate information about the
mapping. The problem was that the driver would use the virtual address as
the key to locate the mapping item in the list. Since, it turns out, the
virtual addresses are not necessarily unique, the driver would mistakenly
identify an incorrect mapping object in the list. The eventual result is
that the driver may go into an endless loop constantly trying to locate a
mapping item. This causes applications to hang when they call PlxPciDeviceClose.
In order to fix this, the PLX driver was modified to additionally compare the owner
of a mapping item, as well as the virtual address. The owner
is a unique object ID assigned by Windows to each application. This
guarantees proper unmapping, even if multiple applications share the same
virtual address.
Affected files: PciSdk\Windows\Driver\Common\Dispatch.c
PciSdk\Windows\Driver\Common\CommonApi.c
PciSdk\Windows\Driver\Common\SupportFunc.c
o
[Linux Drivers]: Fixed SGL build of descriptors if the user buffer
exists in Linux High Memory
In Linux systems with a large amount of memory (> 1GB), user-mode buffers
are typically allocated from the High Memory region. High Memory is
defined as the region for which the kernel does not have logical addresses and
is enabled with the kernel option CONFIG_HIGHMEM. The
memory addressing limitations are due to the Linux memory region split of the
kernel and user virtual spaces.
The PLX driver problem arises during the build of the SGL descriptors, which
describe the user-mode buffer, when the PlxSglDmaTransfer() API is
called, in the support function PlxLockBufferAndBuildSgl().
Originally, the PLX driver obtained the PCI (logical) address by mapping a page
with kmap(), then calling the function virt_to_bus() to obtain
the PCI address. It turns out that virt_to_bus() does not work for
virtual addresses in high memory. As a result, an invalid PCI/bus address
is returned, so the PLX DMA engine would transfer from incorrect locations and
could easily corrupt system memory.
To resolve the issue, the mechanism used to obtain the PCI address was
modified. Rather than using kmap() and virt_to_bus(), the
PLX driver now use pci_map_page(), which returns a valid PCI address
even if a page is in high memory. pci_map_page() is not available
on Linux 2.2 kernels, but that kernel does not support high memory
anyway. Plx_sysdep.h takes care of implementing this for kernel
v2.2. Note that additional cleanup was required in PlxSglDmaTransferComplete()
to unmap the pages.
Affected files: PlxLinux\linux\driver\common\Plx_sysdep.h
PlxLinux\linux\driver\common\DriverDefs.h
PlxLinux\linux\driver\common\SupportFunc.c
Note: This issue was actually fixed in SDK 4.1, but the updated files were not included in the SDK 4.1 file PlxLinux.tar. Instead, a patch was provided on the SDK 4.1 CD for end-users to apply. SDK 4.20 includes the updated files in the PLX Linux TAR file. An additional patch is no longer necessary.
· Building
PLX WDM Drivers with the XP DDK
In previous SDK versions, the PLX WDM drivers were built with the Windows 2000
DDK and Visual C++ 6.0. The PLX drivers can now be built with the XP DDK
and they remain compatible with the Windows 2000 DDK.
Note: The XP DDK includes the tools necessary to build
drivers. Visual C++ is no longer needed in conjunction with the DDK.
· Windows
Driver Physical Memory Allocation with DMA Adapter Objects
In previous SDK versions, PLX Windows drivers allocated physical memory (e.g.
Common buffer) with Memory Manager driver support routines (i.e. MmAllocateContiguousMemory,
MmGetPhysicalAddress, etc.). Although this method works on current
architectures, it is not recommended when physical memory will be used with I/O
devices. The problem is with the addressing of the memory. The Host
CPU physical address to a buffer may be different than the PCI address, which
is the address used by an I/O device.
The correct method, then, for allocating and working with physical memory is to
use a DMA Adapter Object. This object provides routines to
allocate physical memory and also provide a Logical address, which both
the Host CPU and an I/O device can use to access the same physical
buffer. In SDK 4.1, the PLX drivers have been updated to use DMA Adapter
Objects instead of the Memory Manager routines.
Refer to the Windows DDK documentation for details about DMA Adapter Objects.
· Windows
Drivers Physical Memory Cacheable Option
A new option was added to the PLX-specific driver options in the
registry. In previous SDK releases, physical memory allocated by the
driver was always configured as non-[data] cacheable. Although greater
performance can be achieved by enabling caching, there were concerns with data
cache coherency issues since I/O devices, as well as the Host CPU, can update
physical memory. It is believed that the Host CPU “snoops” the bus to
maintain cache coherency, but PLX cannot guarantee this on all platforms.
As a result, the cacheable option is disabled by default, but users can now
modify the registry entry to enable caching.
Refer to the registry settings section in the Plx User’s Manual for
more information.
· Centralized
Driver Options in Registry for Windows 98/Me
In Windows 98/Me, there is no documented central location for OEM
driver-specific options. In previous SDK releases, PLX drivers just used
the registry path provided by the OS when the driver starts. In Windows
98/Me, the registry settings could be scattered in difficult to locate paths
and could be replicated numerous times, depending upon the number of devices
installed.
In SDK 4.1, PLX centralized the PLX-specific driver options in Windows
98/Me. The new path is HKLM\Software\Plx Technology,
Inc.\DriverOptions\<DriverName>. Users can now easily find and
modify the PLX driver settings.
Refer to the registry settings section in the Plx User’s Manual for
more information.
· Support
for Linux RedHat 7.x, 8.0, and 9.0
The PLX Host-side Linux support has been updated to support newer releases of
RedHat.
· PLXMon
– New “View All PCI Devices” Dialog
In PLXMon, a new dialog box was added, which scans the PCI bus and displays a
list of all PCI devices found in the system, including non-PLX devices.
Additionally, the complete 256 bytes of PCI configuration space can be
viewed. This is helpful, for example, when trying to determine the PCI
BAR address of a secondary device.
Note: A valid PLX device (& PLX driver) MUST be
installed for this feature to work. The dialog box is not available in
serial mode. Additionally, PLXMon does not allow modification of the PCI
registers of an arbitrary device. The registers can only be read/viewed.
· Bugs Fixed
o [Linux
Drivers]: For PlxIntrWait, replaced interruptible_sleep_on_timeout()
with Plx_wait_event_interruptible_timeout()
The Linux function interruptible_sleep_on_timeout() is
susceptible to race conditions and its use is no longer recommended. In
PLX drivers, this function was used to wait for an interrupt event. A
race condition existed between checking of the Pending flag of the interrupt
wait object, which determines if interruptible_sleep_on_timeout()
gets called, and the calling of the DPC routine. This resulted in timeout
conditions even if the interrupt event already occurred. This was fixed
by implementing the function Plx_wait_event_interruptible_timeout()
to replace interruptible_sleep_on_timeout(). The new
function periodically checks a condition, which allows it to exit before the
timeout is reached.
Affected files: PlxLinux\linux\driver\common\Plx_sysdep.h
PlxLinux\linux\driver\common\CommonApi.h
o
[Linux Drivers]: Added support for “Local Address Remains Constant”
feature in PlxDmaSglTransfer API call
In the support function, PlxLockBufferAndBuildSgl(), when the
descriptors are built to transfer a user-mode buffer, the “Local Address
Remains Constant” field was ignored. This was fixed by only incrementing
the local address in the descriptors if “Local Address Remains Constant” is
disabled.
Affected files: PlxLinux\linux\driver\common\SupportFunc.c
o
[Linux Drivers]: Fixed DMA channel 1 interrupt handling
In the DPC routine for DMA master chips, the check for the DMA channel 1
interrupt flag referred to the wrong variable. As a result, DMA channel 1
interrupts may not get handled properly, resulting in a constant calling of the
Interrupt Service Routine. The variable was corrected to properly
identify and handle the interrupt.
Affected files: Linux\Driver\PlxChip\Pci9080\PlxInterrupt.c
Linux\Driver\PlxChip\Pci9054\PlxInterrupt.c
Linux\Driver\PlxChip\Pci9056\PlxInterrupt.c
Linux\Driver\PlxChip\Pci9656\PlxInterrupt.c
o
[Local-side API]: Fixed SGL DMA API waits forever for DMA completion
In the local-side PlxDmaSglTransfer() API call, the function
waits for DMA completion by polling a field in a structure in a while()
loop. The Interrupt Service Routine updates the field when a DMA done
interrupt occurs, resulting in an exit of the while() loop. In the
Release build of an image, however, a compiler optimization prevents the
loop from noticing the new value after the ISR has updated it. It is
possible that the field is checked from a register rather than directly from
memory (the use of “volatile” did not help). The result is an endless
loop condition and PlxDmaSglTransfer() never returns.
This issue was fixed by implementing a timeout feature and additionally poll
DMA done bit. This prevents the endless loop condition when waiting for a
DMA completion.
Affected files: PciSdk\Iop\Api\9054\DmaFunctions.c
PciSdk\Iop\Api\9056\DmaFunctions.c
PciSdk\Iop\Api\9656\DmaFunctions.c
o [Local-side
API]: Fixed Shuttle DMA API never starts the DMA engine
In the local-side PlxDmaShuttleChannelOpen() API call,
the function sets up the DMA channel with a circular SGL list (DMA descriptors)
and starts the DMA engine. The problem is when the DMA Command/Status
register is written to enable and start the DMA engine, an invalid value is
written to the register. The original code wrote the variable "RegValue"
to the chip without first initializing it to the value currently in the
Command/Status register. "RegValue" actually contained
the value from a previous read of the DMA threshold register.
This issue was fixed by updating the PlxDmaShuttleChannelOpen()
API call to read the DMA Command/Status register before writing to it.
Affected files: PciSdk\Iop\Api\9054\DmaFunctions.c
PciSdk\Iop\Api\9056\DmaFunctions.c
PciSdk\Iop\Api\9656\DmaFunctions.c
· [VxWorks
Host]: Added a VxWorks Host-side driver for the 9054, 9056, & 9656
This driver is minimal. It demonstrates how to load the driver and access
the PLX chip. The tested platform was VxWorks running on a Motorola
MCP750 Host board.
· [Linux Drivers]: Fixed compile errors with SMP kernel source
· [Linux
Drivers]: Fixed virtual mappings to user space by marking the pages as Reserved
Affected files: PlxLinux\linux\driver\common\PciSupport.c
· [Embedded Linux BSP]: Added an Embedded Linux BSP to support the Compact PCI 9x56-860 RDKs.
· [9030
& 9050/52 Windows Drivers]: Fixed InterruptSource variable not
cleared in ISR
In OnInterrupt() ISR routine for the 9030 and 9050/9052, when the
routine starts to query the chip for the interrupt source, it sets flags in a
variable for each active interrupt. The problem was that the variable InterruptSource
was not cleared before settings the flags. As a result, its initial value
was undefined. The fix was to set reset the variable by setting it to
INTR_TYPE_NONE.
Affected files: PciSdk\Windows\Driver\Common\PlxChip\Pci9030\PlxInterrupts.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9050\PlxInterrupts.c
· [Host-side API]:
Revised the DMA_ELEMENT structure
In an effort to provide a cleaner interface and improve performance, the
DMA_ELEMENT structure has been generalized to support all PLX chips instead of
a different definition for each chip. This makes coding simpler and
portable when using different PLX chip types. The DMA_ELEMENT structure
is used in the PlxDmaBlockTransfer and PlxDmaSglTransfer API
calls. Please refer to the definition in the PlxTypes.h header
file or refer to the DMA sample applications, which use the DMA_ELEMENT
structure.
Affected file: PciSdk\Inc\PlxTypes.h
· [Windows
Drivers]: Fixed possible incorrect interrupt reporting with shared
interrupts
In previous SDK releases, the Windows driver Interrupt Service Routine (ISR)
may erroneously report that a PLX chip interrupt is active. This is
because some interrupt status bits denote an active status, regardless of any
mask bits. Previous ISRs only checked the status bits to verify that an
interrupt is active. This issue may arise only if the PLX chip shares an
interrupt with another PCI device. This behavior does not cause errors,
but may impact performance slightly since the PLX driver could erroneously
claim the interrupt as its own. Since the PCI interrupt is then masked,
the true interrupting device's ISR would then get called.
To resolve this, the ISR now verifies the source of any active interrupt by
checking the mask bit, as well as the status bit. The ISR and DpcForIsr
function were modified to incorporate this efficiently.
Affected files: PciSdk\Windows\Driver\Common\PlxChip\<DriverName>\PlxInterrupts.c
· [PLX BSPs]: Fixed
incomplete PPC register saving during exceptions
In all provided PLX BSPs, it was found that some PPC registers were not saved
on the stack during an exception. These are the Count Register (CTR) and
Floating-point Exception register (XER). This could affect code, which
uses these registers, when an interrupt occurs. The memcpy()
function is one example, which typically uses the CTR register. To fix
this, the stack frame of all exception vectors was modified to additionally
save these 2 registers upon entry and restored when the exception handler
completes.
Affected files: PciSdk\Iop\Bsp\<Board>.rdk\PlxOemCpuInterrupts.as
· [Windows
Drivers]: Fixed issues with synchronization to interrupt register in SMP
systems
This issue arose in multi-CPU systems with a high rate of PLX
interrupts. The PLX Driver interrupt routine, DPC for ISR, and PLX
Interrupt Enable/Disable API calls all access the Interrupt Control/Status
register. The API calls were synchronized with the ISR, but that allowed
them to pre-empt the DPC routine. This resulted in corruption of the
Interrupt Control/Status register. The fix was to incorporate
synchronized access to the interrupt register in the DPC routine.
Affected files: PciSdk\Windows\Driver\Common\PlxChip\<DriverName>\PlxInterrupts.c
· [Windows
Drivers]: Fixed the 9030/9050/9052 Software Interrupt not handled
The previous PLX drivers ignored the Software Interrupt feature of these
chips. When a developer attempted to manually set the interrupt, the
result was a system hang because the PLX driver ISR would continuously get
called, resulting in a non-responsive system. The fix was to modify the
ISR and DPC to handle the software interrupt. A field was added to the
PLX_INTR structure and the DPC routine disables the interrupt if it is
active. Applications are also now able register for Software Interrupt
notification.
Affected files: PciSdk\Inc\PlxTypes.h
PciSdk\Windows\Driver\Common\PlxChip\Pci9030\ApiFunctions.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9030\PlxInterrupts.c
PciSdk\Windows\Driver\Common\PlxChip\Pci9050\PlxInterrupts.c
· [Windows
Drivers]: Fixed Blue Screen/system crash result when an application exits
When an application uses the PLX API, the driver uses some memory to track
resources used/opened by the application. This allows the driver to
release the resources if the application exits abnormally. Blue screens
resulted because the driver memory was allocated from the Paged memory.
When the driver acquired the Spin Lock to traverse the list of resources, a
Page Fault could occur if the list was not in physical memory. Since Page
Faults are not allowed while a Spin Lock is held, the result is a blue
screen/system crash. To fix this issue, the driver memory allocation
routine was modified to use Non-Paged memory to avoid Page Faults.
Affected files: PciSdk\Windows\Driver\Common\SupportFunc.c