Using a USB2.0 debug port with an RMH

[JGolt1]

I have been using the USB2.0 debug port with various chips for several years. With the new chips/chipsets using an RMH it is necessary to bypass the RMH to use the debug port. Unfortunately the information on how to bypass the RMH appears to be "classified" (requires an NDA). After a month going back and forth with Intel support this is ALL I've been able to learn. I've also been unable to discover how an independent developer would go about signing an NDA or even if this is possible. (I've never looked into this before since I haven't needed to in spite of writing low level software for x86 since before the 386 was released! - The low level Intel documentation is usually excellent.) I'm at a loss to understand why this requires an NDA. It's a small detail that simply allows continued use of a previously well documented feature. Any help with this would be appreciated. It's probably something simple.like one or two bits in a register or a set features command to the RMH but I would just as soon not have to spend the time trying to guess what it is (and maybe get it subtly wrong)

[Gabriel_T_Intel]

Hello JohnGoltz

Welcome to the Embedded Community.

What chips/chipsets are you using?

We are going to verify if we can help you to get an NDA.

Regards

Gabriel Thomas

[JGolt1]

Hi Gabriel,

Thanks for the quick response. I'm currently testing with an E3815 SoC in an NUC DE3815TYKE but this appears to be generic to ALL of the newest Intel chipsets with an EHCI. At least I hope the RMH by-pass is done the same on all of them.

John

[Natalie_Z_Intel]

Hello, John! While Gabriel is looking into the documentation that may be helpful to you, I'm going to provide instructions to you to request an upgrade to your Basic EDC account to a Privileged account should you decide you need access to Intel Confidential (NDA) content. Go to http://www.intel.com/content/www/us/en/intelligent-systems/embedded-design-center-contact-us.html Intel® Embedded Design Center Contact and Support and you will see a section called, "Manage Your Intel EDC Account". Then click in "Manage my Intel Profile". On this new page you will see an "Upgrade to Privileged" option. Complete the form with your company information and submit. You can reply back to me once you are done and I will then jump in to facilitate the process to get your application reviewed as quickly as possible. Also, if at any time you would like me to connect you with an Intel representative who covers your geographical area, I can certainly assist you with that, too! LynnZ

[JGolt1]

Hi Lynn,

I have looked at the upgrade instructions. The problem I had was that there were only somewhat vague references to a "standard" NDA. I was not able to find any text that I would be expected to sign. One of my concerns is that a large part of my code is open source (including both sides that use the debug device/cable connected to the debug port) so I need to make sure that I will not violate whatever I sign if I use the information in open source code. I've always tried to avoid NDAs with vendors for just this reason although I did sign one with ATI many years ago (before they were bought by AMD).. I do take signing an NDA pretty seriously. (In the past I've been asked to sign some pretty ridiculous NDAs so I'm a bit nervous about this without seeing the text.) The thing that bothers me about this is that it just does not seem to justify requiring an NDA. It's a small amount of information that allows the continued use of a previously fully documented feature (the USB2.0 debug port). Everything else about the debug port is still fully documented in many public Intel documents. (Well maybe not everything, but certainly enough to use it.) Regardless, I'm certainly open to whatever is the best way to solve this. I really appreciate your offer of assistance with processing an NDA if that is necessary..

Thanks,

John

[Gabriel_T_Intel]

Hello JohnGoltz.

We are working on this issue, we will reply with more information as soon as possible.

Regards,

Gabriel.

[JGolt1]

Thank you.

John

[Natalie_Z_Intel]

Hi, John!

One of our Field Application Engineers, Alex, asked me to provide this information to you that he received from our NUC team, "USB port 1 of the NUC kit in question should support the debug feature. I also found the following link which may be of some value to the customer: http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx".

USB Port 1 supports debug

[Gabriel_T_Intel]

Hello John

The EHCI controller integrates the RMH to support USB1.1 devices.

On EHCI (1/2.0) Port 1 is the debug port of the EHCI controller, it is provided for legacy OS/driver compatibility.

The EHCI is not used when the xHCI is used. The EHCI is primarly present for legacy usage, in cases when xHCI support is not available.We recommend using the xHCI controller for the USB2.0 ports irrespective of whether USB3.0 ports are implemented. Using the xHCI controller will deliver significant power and performance benefits.

Please take a look at this pdf file, it is the Intel Atom Processor E3800 Product Family, Datasheet:

https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-e3800-family-datasheet.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-e3800-family-datasheet.pdf

especially at the section 18, USB Host Controller Interfaces (xHCI, ECHI).

I hope this information helps you, please let us know any update and feel free to make any other question.

Regards

Gabriel

[JGolt1]

Hi Lynn,

Although it does not solve my problem that information is useful. Thanks. It is the first definite statement as to which port on the NUC is the debug port that I have seen. There seems to be a lot of confusion on this (see my response to Gabriel).

I have tried booting it with an Ajays debug device connected to that port. Unfortunately, nothing special happens. It comes up with the RMH fully enabled with the debug device connected to port 2 on the primary RMH. (The one that is directly connected to the EHCI.)

The documentation in several places does state that the "ECHI will detect the debug device and disable the RMH". I have been trying to figure how this would work since the only way to detect the debug device is to send it some commands that are unique to the debug device. This seems a bit much for the EHCI to do by itself. Thus I'm wondering if this could be a BIOS problem.I'm running version 19. I updated to version 34 and the EHCI completely disappeared so I went back to 19! I submitted a support ticket on this and was told that I need to update to every available version in between in turn. That I could not jump from 19 to 34. I have not tried this yet and I'm wondering if this is accurate.

I have seen that blog post. It's a pretty good detailed description of how to use a debug device with MS Windows thus mostly does not apply to my case. It does mention a couple of things I have discovered the hard way some time ago, such as the fact that many BIOS's get very unhappy and sometimes hang if a debug device is connected when booting.

John

[JGolt1]

Hi Gabriel,

Unfortunately it is not helpful. I have gone over the EHCI section of the E3800 family datasheet many times. I have almost memorized the part that talks about the RMH!

I know that the E3800 datasheet describes the EHCI as only being included for legacy support. Unfortunately the RMH/debug port issue extends beyond this. While I do plan to eventually support the xHCI Intel introduced the RMH BEFORE including an xHCI. In particular the 5-series and 3400-series chipsets (document 322169-004) appear to have an EHCI with an RMH without an xHCI. Thus it appears that there are machines out there with this configuration.

There is actually quite a bit more information about the RMH for these chipsets. I have no way of knowing if this also applies to the E3800 SoCs but I'll be surprised if it does not. In partictular there are a number of bits in various chipset setup register that effect port mapping with and without the RMH enabled. There are numerous register settings that are marked as "only effective when the RMH is enabled".

What is still missing is any description of how the RMH is enabled and disabled. At this point it appears this is ALL I need to know. Is it a magic bit in one of the chipset registers or is it a command that is sent to the RMH?

The image is either very confusing or outright wrong! The problem is the port numbering. According to the USB2.0 spec and the UHCI 1.0 spec port numbers are 1-based. There is no port 0. A command to a hub that specifies port 0 actually acts on the hub itself, not on any of the down-stream facing ports. In the image the ports on the EHCI and xHCI blocks are correctly numbered P1-Pn. The muxes and the external ports are incorrectly (I believe) numbered from 0 to n-1. Thus any references to a specific port are ambiguous. Also, it says nothing about the RMH since that is inside the box labeled EHCI.

[JGolt1]

Hi Lynn & Gabriel,

I've been looking at the other new Intel embedded products (Quark and Edison) and it's becoming obvious that if I'm serious about using any of these I will need to sign an NDA. Arguing about what should and should not be under an NDA is obviously a loosing proposition. Can you direct me to someone who can answer the following:

1. Exactly what do I need to sign.

2. What hoops do I need to jump through in addition to signing the document.

3. How will signing this affect being able to use the information obtained under the NDA in open source code.

Thanks,

John

[Natalie_Z_Intel]

Hi, John! I have notified the Intel representative covering your geographical territory to respond to your questions about CNDA and to assist you. LynnZ