EHCI handoff fails on Baytrail

[BBerg7]

Hi,

To understand my questions, see the included figure. In figure 1, the photo you can notice the following:

The 3 hexadecimal values in the top line are dumpings of the USB2 ULSEC register shown in figure 2. The first value is the value at SMM handler entry, The second value is after BIOS semaphore has been reset and read by memory mapped I/O. The third is the same, but read with the standard I/O method.

The test program below reads the ULSEC register using the I/O method. This register is read before and after the SMM handler resets the BIOS owner semaphore.

As you can see that even though the BIOS semaphore bit is cleared by the SMM handler, it's still set when the application reads the ULSEC register. I also tried this using a debugger and direct register I/O in assembly language. Same result. The registers are properly updated in SMM context, but the stale value is still read in application context.

I run my tests from MSDOS, so there are no interfering layers of software. Any ideas?

Best regards,

B-O

[CarlosAM_INTEL]

Hello B-O,

Thank you for contacting the Intel Embedded Community.

The information that may help you is stated in sections 2.1.7, 2.1.8, and 5.1, on pages 11, 12, 121, 122, and 123 of the http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf Enhanced Host Controller Interface (EHCI) Specification for Universal Serial Bus (USB) Revision 2.0.

By the way, it is important to let you know that you should address your EHCI consultations to the channels listed on page 5 of the document mentioned on this communication.

We hope that this information is useful to you.

Best Regards,

Carlos_A.

[BBerg7]

Hi Carlos,

I'm sorry, but this has nothing to do with the EHCI specification. What is clearly shown, is that the chipset fails to adhere to the EHCI specification due to some obscure reason. The question is, why doesn't the write of the BIOS semaphore bit makes it trough to the application level? According to the EHCI specification it should, so what is keeping it from making it. Is it an ERRATA, prefetch or some lock bit or something else keeping it from making it through.

There are many occasions when Linux fails the EHCI handoff with different BIOSes on various Intel platforms. It may be a good idea to sort this out now, so further EHCI handoff failures can be avoided in the future. It should be in all parties interests that the EHCI handoff works on Intel platforms.

Regarding the ULSEC register, it's behavior is not documented enough. For example a 32-bit read, then modifying the OS semaphore bit and writing it back does not trigger a SMI. Only a 8-bit write to the OS semaphore byte do. The EHCI specification doesn't say anything about the mechanics behind the OS and BIOS semaphore bits, except that they should be writable. And that is exactly what doesn't happen with the BIOS semaphore bit.

Best regards,

B-O

[CarlosAM_INTEL]

Hello B-O,

Thanks for your update.

We will contact you via email to help you.

Best Regards,

Carlos_A.

[BBerg7]

Thank you!

[CarlosAM_INTEL]

Hello B-O,

You are welcome and we are glad that the provide information was useful.

Please do not hesitate to contact us again if you have more questions related to Intel Embedded products.

Best Regards,

Carlos_A