Hello,
Can I get Third USB from pins ? I need it to using keyboard in my project. Is it possible? If yes, how can I do it?
So far as I know there is no USB D+/D- going to header pins. The JTK1 has this going to the mini-PCIe slot, but for the JTX1 the solution is either a HUB on existing USB or a USB add-on via PCIe.
Thank you for your answer but I have more questions:
When I use for example HUB that gives me 3 USB and I connect keyboard, mouse and the most important Dynamixel2USB (I dont know if you heard about this, I will use it to control servo). How the system will be see it? as 3 independent USB? or may be some problems with transmission?
And the same question to PCIe options: how the Jetson will see it?
There is a general theme as to how USB works (and PCIe is very similar in logic), and how the kernel works with USB. Each USB device, upon plugin, is enumerated. Enumeration involves a query of each device as to what it is, including things like identifiers (run “lsusb” to see this), or any additional information needed to electrically connect (usually meaning standby capabilities or low power type information).
The part you are interested in for the additional information is that a USB device includes in its reply information about what kinds of pre-defined generic class the device might be. These pre-defined classes include common devices such as keyboard, mouse, hard drive (i.e., Humain Interface Device or Bulk Storage). Using sudo, you can see this extended information on USB with “sudo lsusb -vvv” (or for PCI, “sudo lspci -vvv”).
Upon enumeration there will be a message broadcast in the kernel notifying drivers of the insert of the specific device ID, plus the device class. If the device has a standardized class, then generic drivers will claim the device and this is when the device is actually useful (USB is a pipe to notify of existence, it is the driver that gives the device life). Should the device not have a standardized interface, then it is necessary for a driver to assume ownership based on the driver recognizing the exact device ID. Items with a standard interface class do not need custom drivers; all devices without a standardized interface must be serviced by a driver specific to that device.
Note that PCIe can have hotplug, but this is not supported in Jetson. This isn’t generally a problem since you are not allowed to add and remove from the mini-PCIe (or full sized PCIe) slot while the system runs…this is what USB excels at.
PCIe and USB are no different in a Jetson than in any other computer. It is “sort of true” that the drivers are also no different in a Jetson than in any other Linux desktop system. I say “sort of true” because not all drivers are ported to all CPU architectures. What people often do not expect is that desktops ship with almost every imaginable kernel module possible for common drivers, but embedded systems tend to be more specialized and only ship with pre-built drivers for known necessary drivers and perhaps a few which are exceedingly common to need. Whether a specialized device works or not, if it works on the desktop, is often just a case of adding the driver which exists in the Linux kernel, but which is not currently configured. Your keyboard/mouse type devices are standard, they will just work; the Dynamixel2USB will show up on USB, but whether or not it needs a driver added depends on whether it is a standardized device class or a custom device class.
Also note that for both PCIe and USB that one physical package can logically contain multiple devices, e.g., a programmable keyboard might show up as containing a keyboard and also a mouse where a mouse button is emulated by a macro from a key press (in that case the driver won’t know the mouse button press was from a macro on the keyboard, it would think the button press was from a separate mouse). A video card might show up as both a video device and an audio device (audio would be for sending audio to the monitor over HDMI, DisplayPort, or DVI).
A mini-PCIe slot actually has connection to the D+/D- lines of a USB port (this is optional, but JTK1 does implement this) so that the mini-PCIe slot can also be used for a USB device in that mount format. However, that would not be hot-pluggable, you wouldn’t want to add or remove something while it runs…enumeration would only be by power on or upon request by the root HUB (this is the master HUB built into the Jetson or desktop unit).
Thank you for your answer.
I bought a PCIe-USB controller(UPC-30-2P, Chipset: NEC D720200F1) but I have issues with it.
Here is what I get after connecting this controller to Jetson TX1. Everything that I tried to connect didnt work.
lspci shows the PCIe side and correctly detects and queries the device as to what it is. After that, it’s up to the driver which is specific to that hardware to make use of the hardware (the USB HUB built into the card).
Looking at lsusb on a Jetson with no USB connected, Bus 1 should be the micro-USB connector, Bus2 should be the USB3 connector (root HUBs). I see other root HUBs on bus 004 and bus 005, which are probably from your PCIe card having two ports served by two separate HUBs. I can’t guarantee that because I don’t know about everything attached, but odds are good this is the case. It looks as if those ports/HUBs are recognized by the USB driver, else the 004 and 005 buses would not show up.
So the next question is what is it that didn’t work, e.g., did you plug in a keyboard or mouse and find this failed? A keyboard or mouse would be the simplest test because a keyboard or mouse is only required to work at USB1.1 speeds (or even USB1) and are a very common generic interface class not requiring special drivers. Should your test device be something else, and not show up, it might indicate that PCIe plus USB worked, but the driver serving the specific device failed (implying a custom device requiring a specific driver and not served by a generic interface class). More information on what failed or gave trouble would help.
FYI, you can use a tree view of lsusb and get an idea of the chain of HUBs and devices and how they connect (“lsusb -t”).
Thanks for your answer again :)
Here is what we get from lsusb -t(without controller and with it):
External Media
I try connected keyboard and mouse but It didnt work. I think we dont have supply on the ports and I have question: We have controller USB3.0 and I dont know if it is needed to use external power ??
lshv command gives me:
External Media
USB should be able to deliver enough power without external power, but some HUBs may not be designed to run any way other than external power (I don’t know of any though, and certainly a PCIe version won’t require special power connections unless it is something unusual…HUBs implementing external power usually do so for higher output current capacity and fall back to lower current delivery without external power). When testing the keyboard, I assume it has a caps or caps lock indicator LED…and some mice have a visible red optical output…was any of that showing power? Does this PCIe card have an auxiliary power connector?
Looks like the PCIe card provides 2 buses. Apparently you have two human interface devices (HID) already connected to a non-PCIe USB2 HUB prior to adding the PCIe USB card. However, the lsusb tree prior to adding the card shows the built-in USB3 connector has the r8152 driver associated with it, and thus the tree after adding the card where one USB3 port has the r8152 driver associated and one without a driver tells us that the add-on card is the listing without the r8152 driver association. Was there any keyboard or mouse plugged in to the PCIe USB card while running this “lsusb -t”? Did the tail of dmesg show any output as a keyboard or mouse was plugged/unplugged to the PCIe card? Everything indicates that the HUB itself is there and working, it just doesn’t have anything plugged in to it according to this.
Hi there,
we have the same issue here, we are using
4-Port PCI Express SuperSpeed USB 3.0 Controller Card Adapter with SATA Power PEXUSB3S4V.
The issue is the usb3.0 randomly work, when it dose not work, nothing show up with ‘lsusb’ command.
Those are the debug message when it doesn’t work, we are using L4T R21.4 for our development right now.
ubuntu@tegra-tx1-dev:~$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
ubuntu@tegra-tx1-dev:~$ lspci
00:01.0 PCI bridge: NVIDIA Corporation Device 0fae (rev a1)
01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
ubuntu@tegra-tx1-dev:~$ dmesg | grep xhci
[ 5.095953] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 5.101195] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 5.136254] usb usb1: Manufacturer: Linux 3.10.96-PMI-A002655-V1.2.0B3 xhci_hcd
[ 5.148640] xHCI xhci_add_endpoint called for root hub
[ 5.148654] xHCI xhci_check_bandwidth called for root hub
[ 5.157258] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 5.162548] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 5.189208] usb usb2: Manufacturer: Linux 3.10.96-PMI-A002655-V1.2.0B3 xhci_hcd
[ 5.201744] xHCI xhci_add_endpoint called for root hub
[ 5.201756] xHCI xhci_check_bandwidth called for root hub
[ 5.290200] tegra-xhci tegra-xhci: XUSB device id = 0xfac (T210)
[ 5.602309] usb 1-1: new low-speed USB device number 2 using xhci_hcd
[ 6.392772] usb 1-2: new high-speed USB device number 3 using xhci_hcd
[ 9.629199] tegra-xhci tegra-xhci: Firmware File: tegra21x_xusb_firmware (132608 Bytes)
[ 9.629392] tegra-xhci tegra-xhci: Firmware DMA Memory: dma 0x0000000080040000 mapped 0xffffff80007c1000 (132608 Bytes)
[ 9.629400] tegra-xhci tegra-xhci: num_hsic_port 0
[ 9.631524] tegra-xhci tegra-xhci: Firmware timestamp: 2015-11-18 07:02:37 UTC, Version: 50.11 release, Falcon state 0x20
[ 9.631604] tegra-xhci tegra-xhci: Nvidia xHCI Host Controller
[ 9.631619] tegra-xhci tegra-xhci: new USB bus registered, assigned bus number 3
[ 9.632432] tegra-xhci tegra-xhci: irq 71, io mem 0x70090000
[ 9.632533] usb usb3: Manufacturer: Linux 3.10.96-PMI-A002655-V1.2.0B3 tegra-xhci
[ 9.632537] usb usb3: SerialNumber: tegra-xhci
[ 9.632767] xHCI xhci_add_endpoint called for root hub
[ 9.632774] xHCI xhci_check_bandwidth called for root hub
[ 9.712233] tegra-xhci tegra-xhci: Nvidia xHCI Host Controller
[ 9.712251] tegra-xhci tegra-xhci: new USB bus registered, assigned bus number 4
[ 9.712434] usb usb4: Manufacturer: Linux 3.10.96-PMI-A002655-V1.2.0B3 tegra-xhci
[ 9.712439] usb usb4: SerialNumber: tegra-xhci
[ 9.712817] xHCI xhci_add_endpoint called for root hub
[ 9.712824] xHCI xhci_check_bandwidth called for root hub
[ 10.172681] usb 4-1: new SuperSpeed USB device number 2 using tegra-xhci
[ 10.312958] usb 4-1: reset SuperSpeed USB device number 2 using tegra-xhci
[ 30.072868] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[ 30.072954] xhci_hcd 0000:01:00.0: Assuming host is dying, halting host.
[ 30.073210] xhci_hcd 0000:01:00.0: HC died; cleaning up
R21.4 is for a TK1, I assume you mean R24.1 (for TX1).
If you could post the output from this we can look at what PCIe thinks (assumes the above lspci with slot 01:00.0 is still correct):
sudo lspci -s '01:00.0' -vvv
It would be important to show the above lspci output on a freshly booted Jetson when USB has been found to work correctly, followed by the same lspci command while a failure is occurring. This might narrow the failure to PCIe or other.
Also, what devices are connected to that USB card at the time of failure, and does the card use external power other than from the PCIe slot?
Hi, I printed out both situations. Top is the normal bootup, I do not see any difference so far with the bad one. Tx1 seems can emulate the usb devices at bootup, then, no response on the xhci host, and hang eventually.
[ 45.010943] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[ 45.011051] xhci_hcd 0000:01:00.0: Assuming host is dying, halting host.
[ 45.011388] xhci_hcd 0000:01:00.0: HC died; cleaning up
Indeed, this expansion pcie card have extra sata power connector, we tried several times with providing extra power, and this problem seems still exist.
ubuntu@tegra-tx1-dev:~$ sudo lspci -s '01:00.0' -vvv
[sudo] password for ubuntu:
01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 130
Region 0: Memory at 13000000 (64-bit, non-prefetchable)
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=0 offset=00001000
PBA: BAR=0 offset=00001080
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [150 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Kernel driver in use: xhci_hcd
ubuntu@tegra-tx1-dev:~$ sudo lspci -s '01:00.0' -vvv
[sudo] password for ubuntu:
01:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 130
Region 0: Memory at 13000000 (64-bit, non-prefetchable)
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=0 offset=00001000
PBA: BAR=0 offset=00001080
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [150 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Kernel driver in use: xhci_hcd
I had hoped that there might be an indication that PCIe found or corrected an error, but as you mentioned, it seems the two versions of lspci are identical. This would lead me to believe the error is not in the PCIe end, but instead in the USB end.
How hard would it be for you to try R24.2 instead of R24.1? There may be slight differences in the firmware file for xhci between those two versions. I’d like to find out if perhaps the newer version does not have this issue…otherwise things might get more difficult to find out what’s going on (e.g., it’d be interesting to see a protocol analyzer tell us if the endpoint stop is an error of host side or device side…not so easy to do compared to flashing).