Connecting Two NVIDIA TK1 Dev Kits Via USB Type A

Hello, I was wondering if it was within the specification for the USB3.0 Ports on the NVIDIA TK1
to support USB3.0 Communication between two TK1 Dev Boads across a USB cable Type-A.

I know in the Linux Kernel, there is a Gadget API for communicating between two HOSTS. But I wanted to identify if there is( or was ) a UDC on the TK1 for 3.0.

It seems like this Post Confirms the possibility with the 2.0 Port, but I’m not sure.

That is undefined, and type-A to type-A cannot work.

For USB3 type-C connector the two ends of the cable “seem” to be swappable. In reality, the wiring used in a type-C implies one end will still be in host mode, and the other end in device mode (type-C adds more wires…the connectors appear to be uniform, but the wiring used is not).

If we talk about type-A, then that end works only with a host, and the other end must be type-B, and that end must be device mode.

There is no possibility of a type-A to type-A cable, the wiring does not contain any ability to interact with a device, and pairing host-to-host is undefined.

The “On the Go” port (“OTG”) is a special USB2 port. The micro-OTG connector can accept either a type-A micro connector, or a type-B micro connector. However, there is an ID pin for detecting which type of connector has been inserted. The cable itself will not violate the mandatory requirement that one end be type-A (host mode), and the other end being type-B (device mode). The OTG port can be used for this purpose if that port is in device mode, and talks to a host with a type-A at the other end.

I am curious about this too. I see in the TK1 TRM that the USB 3.0 controller can connect to xHCI (Master) or Device (slave).

Pg. 980

Does this imply that USB3 to USB3 communication between two TK1’s is possible at the silicon level? If so, then are there drivers that support this?

The use case I am attempting to do is creating a PCB that has two TK1 SoC’s on it that have the two USB3 signals tied together. As a result, I can physically connect the signals up any way I want (i.e. control over the ID pin). I need the throughput that USB3 provides for TK1 to TK1 communication.

It would be great to test this out between two Jetson TK1 dev kits before making the board and from what linuxdev is saying, it looks like we would have to potentially create a custom cable to facilitate this?

I have not built a custom board for this, but the device tree and physical wiring generally mean there is more than one way to wire a custom board for putting a USB port in device mode. In terms of customizing, this is possible (but I don’t know about specific controllers and specific wiring cases).

The part which is not possible is to use device mode on a connector which is physically type-A. The connector must be type-B for the device end, or else USB-C with wiring for device mode.

Someone else would need to answer about specific controller and wiring options in a customized carrier board, but there is no possibility of a type-A connector ever being used as a device without some serious violation of standards.

It is advancing function and not supported on TK1. It is also not supported on other Jetson platforms by default. The platform close to this request is Drive AGX, which has two Xaviers.

Hello DaneLLL,

I have a follow up question:


mean it is ‘not supported’ in the software or ‘not supported’ in the TK1 sillicon package, or just the TK1 dev board? Assuming it is just ‘not supported’ from a software/driver standpoint, I could certainly make my own driver for my specialized platform using the chip.

Specifically, is the support missing from the silicon itself? Please let me know if this functionality works WITHIN the S.o.C silicon package, regardless of the board or software package it is presented on.

Thank You DaneLLL!

Please check
[TK1 platform design guide]
[TK1 techinical Reference Manual]

Theoretically, it should work if you run USB2.0 Controller#1 in device mode and USB2.0 Controller#2 in host mode simultaneously. However, it is not verified and you may try to work out the driver.