Project for major energy company derailed by ATOM E6xx, EG20T silicon bug
Custom hardware was developed to us the industrial temperature rated ATOM in a harsh environment. The primary interface to the hardware is the six USB port provided by the EG20T controller hub. All early software/hardware development was tested with the commercial temperature rated ATOM processor and the US15W controller hub without error.
USB traffic to the EG20T causes all USB traffic to stop. This issue is stated in Intel Platform Controller Hub EG20T Specification Update Errata # 12.
“ USB Host: Memory Read Request Address Across DWord Boundary
May Cause Incomplete Transfer
When the Device Read Pre-Fetch Control Register (Packet Hub MEM_BASE+014h) for the USB host is enabled, transfer incompletion may occur if the USB host issues byte or word (16 bit) memory read requests to PCIe and this address is not aligned to a DWord boundary (memory read request address is xxxxxxx0/4/8/Ch).
When transfer incompletion occurs and the invalid transfer continues, the QoS buffer memory of the Intel® PCH EG20T overflows and the system may hang.
Do not issue memory read requests across a DWord boundary. Since memory read requests across the DWord boundary may be issued by the Windows* 7 standard USB driver, use the Intel® PCH EG20T driver for Windows 7 version 1.2 or later. It may reduce the probability of an incomplete transfer.
Upon updating the driver to version 1.2 from http://edc.intel.com/Link.aspx?id=4028 , USB traffic from our devices still causes USB traffic to stop. We have little control over some of our USB device drivers and cannot guarantee that they will not issue a request across a DWord boundary.
Alternate Workaround that we are visualizing is the following but need some guidance/clarifications:
The errata states the problem is caused by the Device Read Pre-Fetch Control Register for the USB host being enabled.
Question1: Will disabling Pre-Fetching solve the problem? If so, what is the proper procedure to accomplish this?
We have seen that the Intel Platform Controller Hub EG20T PHUB Driver Programmer’s Guide specifies(in section 6) that the default value for the Device Read Pre-Fetch Control Register is 0x000ffffa i.e. enabled for the USB Controllers. Section 4.3 states the details of the IOCTLs are located in “ioh_pcieqos_ioctls.h” and “ioh_pcieqos_common.h” however these files are NOT supplied in the v1.2 driver zip file downloaded from the above link even though they are listed in the release notes.
Question2: Are these files the necessary to reconfigure the register? And if so can we have access to them?