ATOM E6xx, EG20T, USB Host silicon bug driver workaround needed

[MAnge4]

Project for major energy company derailed by ATOM E6xx, EG20T silicon bug

Overview:

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.

The Issue:

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

Problem:

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

Implication:

When transfer incompletion occurs and the invalid transfer continues, the QoS buffer memory of the Intel® PCH EG20T overflows and the system may hang.

Workaround:

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.

Status:

No Fix

"

Upon updating the driver to version 1.2 from http://edc.intel.com/Link.aspx?id=4028 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 ...

[FMcNu1]

Hello and Welcome to the Intel® Embedded Community.

Since you are using Intel® Atom, I want to make you aware of a special place to go with your technical questions. The Intel e-Help desk is staffed by Intel representatives dedicated to answering embedded Intel® architecture product, design and development questions for select Intel processors..

The Intel e-Help desk is only available to registered private users. Before you can access e-Help, you will first have to upgrade your community membership to private status. Private account status also allows you to access special documents and tools at the Intel® Embedded Design Center. Note that it usually takes a few days for the approval process, and it normally requires that your company has a Non-Disclosure Agreement (NDA) with Intel. If you are interested, follow the link below to your 'My Account' page and request registered private access.

http://edc.intel.com/User/My-Account/ http://edc.intel.com/User/My-Account/

(Look for this on the right side of page: Manage Intel ® Embedded Design Center Privileged Account )

I hope this helps

Felix

J. Felix McNulty

Community Moderator (Intel contractor)

[MAnge4]

Thanks Felix. We(co-worker) have already requested access to the priviledge access, and I hope it doesn't take the full 10days to get it granted :) as we are at a very critical production stop point in our project for our major customer.

Any pointers from the software intel experts meanwhile can really help us keep rolling if we can be pointed/sent the header files that seem to allow us to re-configure to turn off the pre-fetching mode on the driver (if that can by-pass the existing silicon bug)

regards,

miguel

[MAnge4]

On question # 1: We still will like to know from the HW experts who know the EG20T USB to comment if disabling the mode will enable us to by pass the silicon bug all together or not?

On question# 2 We have received the missing driver files. Thanks.

regards,

Miguel

[RBloo1]

Hi,

We are seeing similar problems. Is there a resolution to this?