12 Replies Latest reply on Oct 20, 2014 3:32 PM by LynnZ

    Using a USB2.0 debug port with an RMH

    JohnGoltz Green Belt

      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)

        • Re: Using a USB2.0 debug port with an RMH
          gabriel.thomas Brown Belt

          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

            • Re: Using a USB2.0 debug port with an RMH
              JohnGoltz Green Belt

              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

              • Re: Using a USB2.0 debug port with an RMH
                LynnZ Brown Belt

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

                  • Re: Using a USB2.0 debug port with an RMH
                    JohnGoltz Green Belt

                    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

                      • Re: Using a USB2.0 debug port with an RMH
                        gabriel.thomas Brown Belt

                        Hello JohnGoltz.

                         

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

                         

                        Regards,

                         

                        Gabriel.

                            • Re: Using a USB2.0 debug port with an RMH
                              LynnZ Brown Belt

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

                               

                              USB Port 1 supports debug


                              Capture.PNG

                                • Re: Using a USB2.0 debug port with an RMH
                                  gabriel.thomas Brown Belt

                                  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

                                  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

                                    • Re: Using a USB2.0 debug port with an RMH
                                      JohnGoltz Green Belt

                                      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.

                                    • Re: Using a USB2.0 debug port with an RMH
                                      JohnGoltz Green Belt

                                      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

                                      • Re: Using a USB2.0 debug port with an RMH
                                        JohnGoltz Green Belt

                                        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