Broadcom PCI/PCIe SDK

 

Release Notes

 

Version 8.23

November 2020

Contents

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

4.     PCI/PCIe SDK and I2C

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:

PCI/PCIe SDK 8.23

PCI/PCIe SDK 8.10

PCI/PCIe SDK 8.0

PLX SDK 7.25

PLX SDK 7.24

PLX SDK 7.23

PLX SDK 7.20

PLX SDK 7.10

PLX SDK 7.00

PLX SDK 6.50

PLX SDK 6.42

PLX SDK 6.41

PLX SDK 6.40

PLX SDK 6.30

PLX SDK 6.20

PLX SDK 6.10

PLX SDK 6.00

PLX SDK 5.22

PLX SDK 5.21

PLX SDK 5.20

PLX SDK 5.10

PLX SDK 5.00

PEX SDK 2.10

PEX SDK 2.0

PCI SDK 4.40

PCI SDK 4.30

PCI SDK 4.20

PCI SDK 4.10

PCI SDK 4.0

PCI SDK 3.5

PCI SDK 3.4

PCI SDK 3.3

Important Notes

1.    NDA Required for Full Software Support of PLX PCI Express Switches

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.

2.    Distribution of PCI/PCIe SDK Components

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.

3.    Shipping a Product with a Broadcom/PLX chip

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.

4.    PCI/PCIe SDK and I2C

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.

5.    PCI/PCIe Debug Tools Per-chip Support

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.

6.    Compatibility with Newer Versions of Microsoft Visual Studio & Managed Code

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

7.    PCI/PCIe SDK Drivers and the 9050 BAR Errata

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.

8.    Increase Host CPU Write (“Direct Slave”) Performance to PLX 9000 & 8000 BAR Spaces

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.

9.    Working with the Generic Local-to-PCI Interrupt (LINT) or GPIO Interrupts

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.

10.  Using the PCI/PCIe SDK API Statically Instead of as a Dynamic Link Library (DLL)

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.

11.  PCI/PCIe SDK Digitally Signed Windows Drivers

[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.

12.  Windows IA64 is not supported

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.

13.  Access to PCIe Extended Configuration Space on UEFI Systems via Windows PCI/PCIe Service driver

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.

SDK Changes

PCI/PCIe SDK 8.23

·           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.

PCI/PCIe SDK 8.10

·           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 SDK 8.0

·         Windows Drivers

·         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

PLX SDK 7.25         

·         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 SDK 7.24

·           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 SDK 7.23

·     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 SDK 7.20

·         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

PLX SDK 7.10

·         [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

PLX SDK 7.00

·           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.

PLX SDK 6.50

·           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.

PLX SDK 6.42

·         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

PLX SDK 6.41

·            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.

PLX SDK 6.40

·         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

PLX SDK 6.30

·         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.

PLX SDK 6.20

·         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.

PLX SDK 6.10

·         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

·         I2C support in the PLX API was updated to support required changes for using Aardvark API DLL v2.x.

·         I2C support was added to the PLX API in Linux, but PLX has not tested this feature on a Linux platform.

·         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

·         Presentation mode for GenMon Performance monitor to display important data in large font for demo purposes.

·         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)

·         Bugs Fixed

·         [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

PLX SDK 6.00

·         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.

·         Bugs Fixed

·         [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

PLX SDK 5.22

·         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.

PLX SDK 5.21

·         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.

PLX SDK 5.20

·         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

PLX SDK 5.10

·   Added support for new devices and revisions
Support for new devices and revisions was added (i.e. 8112 & 8500 series).

PLX SDK 5.00

·   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

PEX SDK 2.10

·   Various bug fixes and new API calls added

PEX SDK 2.0

·   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

PCI SDK 4.40

·   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).

·   Bugs Fixed

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

PCI SDK 4.30

·   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

PCI SDK 4.20

·   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.

PCI SDK 4.10

·   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

PCI SDK 4.0

·   [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.

PCI SDK 3.5

·   [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

PCI SDK 3.4

·   [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

PCI SDK 3.3

·   [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