question regarding USB 3.0 device mode

In Xavier data sheet, we have:

xHCI host controller with integrated PHY (up to) 3 x USB 3.1, 4 x USB
2.0; USB 3.0 device controller with integrated PHY | PCIe: x8, x4, x2, (2x) x1 | SD/MMC controller (supporting eMMC 5.1, SD 4.0, SDHOSTSB 3.0 device controller with integrated PHY
4.0 and SDIO 3.0) | 5 x UART | 3 x SPI | 5 x I2C | 2 x CAN | 4 x I2S: support
I2S, RJM, LJM, PCM, TDM (multi-slot mode) | GPIO

Anyone knows in the Xavier devkit, which USB connector is routed to "USB 3.0 device controller”?

Both Type-C ports can be device.

Thanks @Trumany,

Any code/script example to show how to switch these type-c ports to device? Or it is automatic if I connect my PC (type-A) to Xavier (type-c)?

Thanks again.

Hi guo, it is automatic.

Hi, good info, I am curious, what type of device will the port present itself.

hi sato, CC pins decide host or device modes.

I think the question is: When the port is in device mode, do we get any device classes automatically implemented, or do we need to write our own device class presentation modules?

I saw L4T-README (15.9 MB) as the usb device/volume from the windows host

Interesting…plugging on my host shows two network devices, plus a mass storage. Mounting the mass storage shows about 4.2GB of VFAT space.

The actual file image used for the USB bulk storage gadget is:


Neither of the network devices being emulated have an IP address. I wonder if perhaps this is intended for future flash use such that ethernet over the wired cable could be ignored and the USB used instead as a “pretend” ethernet card.

If you want to remove this as automatically happening, just remove the symbolic link in “/etc/systemd/system/nv-l4t-usb-device-mode.service”. Adding that symbolic link back would enable this once again. Editing the systemd files in “/opt/nvidia/l4t-usb-device-mode/” would edit the behavior. Changing the file “filesystem.img” into some other loopback mountable image would change the bulk storage emulation backing device. One could of course edit the script and point at something like “/home” instead.

FYI, one could get about 4.3GB of eMMC back by first removing the “/etc/systemd/system/” symbolic link, rebooting, and then removing the actual image in “/opt/nvidia/l4t-usb-device-mode/”.

All the good stuff seems to live in in /opt/nvidia/l4t-usb-device-mode
You can configure which devices it brings up for gadget/device mode there.
For me, the “filesystem.img” is 16 MB after a fresh flash.
I don’t think you can trivially point it at “/home” because “filesystem.img” is a file that emulates a block device of type FAT, whereas “/home” is a file system that doesn’t emulate FAT.

Here are the devices it creates by default:

# Ethernet using the RNDIS protocol.
# CDC ACM serial port/UART.
# Ethernet using the CDC ECM protocol.
# USB Mass Storage (virtual disk drive/USB memory stick).

# The IP address shared by all USB network interfaces created by this script.
# The associated netmask.
# The IPv6 address shared by all USB network interfaces created by this script.
# This should be a link-local address.

By default, the TTY device seems to spawn a console serial port:

picocom -b 1000000 /dev/ttyACM0

Type [C-a] [C-h] to see available commands

Terminal ready
xavier login:

This device is ttyGS0 on the Xavier side:

tynvidia@xavier:~$ tty

So, if we can disable this serial console, presumably we can use it for serial communication.

1 Like