reading data from USB 3.0 port on jetson custom carrier


I woul like to know if drivers exist for reading data from a USB 3.0 port on the jetson where the jetson is active as a device. Are there any reference examples which show how to read from a USB 3.0 port on jetson from a computer which acts as a host?

I see on the manual that there is a USB 3.0 port which can act as adeice. Are there any examples on how to use this? libusb on the computer would request a bulk transfer. How do I get jetson to respond to this transfer and send some data out?

If you are using the dev carrier board, then the answer is “no”. The full-sized port is not wired to be a device (it is a type-A only port). The micro-OTG port (which can act as type-A or type-B depending on what is connected to it) is not wired for USB3, so it can attain only USB2 speeds. If you are designing your own carrier board, then you can probably do what you want (though there may be some limitations against isochronous mode).

It is a custom carrier board. How do I get the jetson to sho up as a UVC device? Do you have any links about the driver and if it is already part of the jetson?

I don’t know how your board is wired, but that sounds like either the port is a dedicated type-B port, or else an OTG port. If it is OTG, then there will be a detect pin you need to set up with device tree should auto-detect be desired (you could just force it to device mode). I can’t help much with details on a custom board.

There is some common content between the various Tegra SoCs for this, especially there are similarities between a TX1 and TX2 even though the device tree edits will differ (they use the same carrier boards).

Below are some related topics, but there will be differences depending on L4T release version and whether the module is TK1, TX1, or TX2:

The kernel code you have to edit is from the gadget framework (being in device mode only says it is a device…you have to actually implement what device you want it to be):

The bottom line is that either the port must be forced into device mode, or else the detect pin must be set up such that having a type-B connector forces the port into device mode. “/sys” is one way of controlling this, device tree is another. Being in device mode does not cause any specific device to be implemented, you still have to do that yourself.

Someone else may be able to give more details on customizing, but you’ll want to give details on what is wired to that port.

You may find looking at the files from this while reading on the topic can help:

sudo find /sys -name '*otg*'

Do drivers by NIDIA already exis for using the USB 3.0 port in device mode? I see that the manual says there is a USB 3.0 device. Where is the driver located for this(gadget driver is one level higher, I am wondering if NVIDIA has drivers which can configure the USB 3.0 port as a device)

The USB controller has drivers…but device mode doesn’t complete its setup by having drivers. Drivers normally bind hardware to what is essentially a data tunnel with the ability to query any device to ask it what it is. It is up to you to provide what you want the device to be (either by physically attached hardware, or software pretending to be hardware).

Just for illustration, imagine you have a computer with ethernet. Someone connecting might expect a web server. You’d need to add the web server. Someone might expect ssh access. You’d have to add the ssh daemon. Someone might want to mount an NFS disk on their system. You’d have to provide the NFS export setup and partition. USB in device mode is similar…your USB port, in device mode, already has a driver…but if there is no device to bind to it, then “the lights are on, but nobody is home”. The gadget framework, using the existing drivers, gives you everything you need to bind your device to a USB port which can be queried. There are definitions of how to use certain standard device classes, but you need to fill in details of how it responds to a query or actual use/behavior.

The simplest of devices would be bulk storage or ethernet devices. The gadget framework makes the final device for these fairly simple, but some details must still be manually configured. Other devices may take a lot of work. What kind of device do you want this USB port to behave as? Knowing this would allow a more specific answer.

FYI, NVIDIA drivers provide only the USB driver…it is gadget framework which makes attaching devices to the driver something more or less standardized (the gadget framework is standard…the tegra-specific controller driver gadget uses is already in place). One thing I have not looked at is how much difference there is between creating a USB2 device via the gadget framework, versus a USB3 device via the gadget framework. A USB3 device does need to provide more information from a query than does a USB2 device and I’ve never examined whether gadget has anything special for dealing with that.

Just as an example, to see what information a device provides, run a verbose lsusb for a mouse or keyboard. Start with just “lsusb”, which provides an ID. If you see your mouse has ID “264a:1009”, then verbose listing limited to this one device is via “sudo lsusb -d 264a:1009 -vvv”. If you run this same query on a device you want your gadget to emulate, then you’ll see what has to be provided, e.g., if you want to emulate an external USB hard drive, then check the verbose lsusb on any USB hard drive.