TX1 USB3.0 design

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hi
I want to design two USB3.0 interface baseed on TX1 module.
In the JetsonTX1_OEM_Product_DesignGuide-1000010-13 page22 there is a Table about the USB configuration, I want to use the configuration 3 or 4, but the manual said The USB 3.0 controller #2 interface can optionally be brought out on the PEX1 or USB_SS1 pins, and has been verified on the module. However, that configuration may not be supported/tested with the released Software.
Did anybody redesign USB port? please help. thank you.

2

Any nvidia engineer can answer my question??

3

Hi,

I can’t answer you but a good lead is Auvidea who has some engineers coming here (on the forum) from time to time.
Have a look at their board :
[url]http://www.auvidea.eu/index.php/2015-11-08-08-01-27/2016-02-03-12-30-02/j100-single-tx1-carrier-lite#[/url]
So with PCIe x4 and SATA, normally it lets the 2 USB 3.0 on PEX1 & USB_SS0…
Maybe someone from Auvidea can tell you about how hard (or easy) it is to bring the software with this configuration.

Regards,
Ale

4

Hello, bangbanghb:
Jetson TX1 has only 1 USB 3.0 port.
So it may need some software change for a new board with 2 USB 3.0 port enabled, according to your hardware design.

Generally, you need to check the following configurations in DTS:
portmap, ss_portmap, laneowner.

You can paste your USB port design block if further support needed.

Also, I will check internally for a more detailed document.

br
ChenJian

5

Hi bangbanghb,

Can you please post this part schematic so as to confirm your ports design following design guide?

6

Hi alejuventina

Thank you for your reply, this link is exactly what I am looking for.

7

Hi Jachen & Trumany,
Thank you for your reply. I use USB_SS1 for the second USB3.0 port.
You can refer to Use case 5, Table 10, page 22 on the JetsonTX1_OEM_Product_DesignGuide-1000010-16.pdf.
As the note said the USB_SS1 has bee verified on the module.

8

Hi Jachen & Trumany,
Thank you for your reply. I use USB_SS1 for the second USB3.0 port.
You can refer to Use case 5, Table 10, page 22 on the JetsonTX1_OEM_Product_DesignGuide-1000010-16.pdf.
As the note said the USB_SS1 has bee verified on the module.

9

i am working on two USB3.0 interface baseed on TX1 module,too.i think i think the one can refer to the development board,the other can use PEX1.（ figure 11, page 28 on the JetsonTX1_OEM_Product_DesignGuide ）
but i have question，if you use USB_SS1 for the second USB3.0 port,the PCIE X4 can not work.you do not use PCIE X4 ?

10

who can help me？

11

Use case 5 is for 3 USB3.0 ports, it is not supported with the released software as OEM Design Guide Notes said.

12

Hello all…
I am also looking at modifying the Jetson TX1 module’s configuration from the Jetson TX1 Development platform with only one USB 3.0 port to two USB 3.0 ports along with other changes… I have the hardware to support the changes, but need to address the Software side of things…

My understanding is that you need to modify the pinmux on the TX1 controller to switch the appropriate PCIe lanes to USB 3.0 lanes… Lets for sake of argument, ignore the actual hardware and focus on the Software process needed to support the change…

First you start out by modifying the pinmux spreadsheet, Jetson_TX1_Generic_Customer_Pinmux_Customer_Release.xlsm found at [url]https://developer.nvidia.com/embedded/dlc/jetson-tx1-module-pinmux[/url]… Once changes are completed, there is a macro button to creates a new dtsi file…

Next… I have no idea what to do with this file… Is there detailed instructions on this process…? If not can someone point me to the next step…?
Thanks,

13

I have followed the instructions in the spreadsheet, “Jetson_TX1_Generic_Customer_Pinmux_Release.xlsm”, and generated a CSV file and both dtsi files… One of the dtsi files is labeled “-gpio-default.dtsi” and the other “-pinmux.dtsi”…

I have searched for instruction on how to use these files, but haven’t found a procedure to do so…

How do I integrate these files onto my Jetson TX1 Dev board so they are used in the boot…?

14

This may or may not apply for your particular situation, but in general the dtsi files are in kernel source at some architecture-dependent location, e.g., “arch/arm64/dts/tegra210-platfors/*.dtsi”. These can be built during kernel compile, e.g., the “make dtbs” command will compile this into the binary “.dtb” format. For u-boot, this in turn is put in your “/boot/” directory in the “.dtb” format, and the “FDT” key/value pair of extlinux.conf names the file for u-boot to load.

You can also reverse the dtb into dts, or back from dts to dtb with just the dts compiler scripts of the kernel source. The original dts files have comments and naming which would be more readable than a reverse of a dtb decompiled back into dts. To see what is in a dtb, you could do this (assumes “./scripts/dtc/dtc” exists which is part of kernel source):

scripts/dtc/dtc -I dtb -O dts -o /tmp/extracted.dtb /boot/the_firmware_in_extlinux.dts
15

Hell,
Here are the descriptions of XUSB controllers. DTS may have to update according to hardware design.

br
ChenJian

Tegra SOC XUSB controllers

The device node for a USB controller that is part of a Tegra
SOC is as described below:

Required properties :
XHCI:

  • compatible : Should be “nvidia,tegraxxx-xhci” where xxx represents chipid
    supported so far are 114,124,132,210

  • nvidia,portmap : List of all ports (2.0/3.0) available for XUSB controller
    Each bit represents port and bit is set for ports controlled by XUSB.
    0-7 bits represent USB3.0 ports with Port 0 on LSB.
    8-15 bits represent USB2.0 ports with Port 0 on bit 8.
    16-23 bits represent HSIC ports with Port 0 on bit 16.
    Ex: <0x0e02> represents following ports are enabled
    USB3.0 Port1 & USB2.0 Port 1,2,3.

  • nvidia,common_padctl : reference to pad control dt which has details
    about port mapping. Padctl is also used by xudc driver.
    PADCTL:

  • nvidia,ss_portmap : Mapping between USB2.0 port and USB3.0 port available
    on a single connector.
    Each nibble represents a USB3.0 port starting from LSB. Matching USB2 port
    has to be entered. Enter 7 if ss port is not in use or not available.
    Ex: <0x7730> represents following mapping
    ssport0<–>usb2port0
    ssport1<–>usb2port3
    ssport2<–>disabled
    ssport3<–>disabled
    For USB3.0 standalone ports without USB2.0 port, we still require a mapping
    to a USB2.0 port that is valid host port.
    Two USB3.0 ports can be mapped to a single USB2.0 port with same role and
    may not represent the end connector mapping in standalone ports case.

  • nvidia,lane_owner : PEX/HSIO Lanes used by USB3.0 ports
    Each nibble represents a USB3.0 port starting from LSB. Matching lane number
    has to be entered. Enter 0xF if port is not in use or no lane is mapped.
    Ex: <0xFF56> represents following mapping
    ssport0<–>lane6
    ssport1<–>lane5
    ssport2<–>not in use
    ssport3<–>not in use

  • nvidia,otg_portmap : Indicates if a port is OTG port or not
    Each bit represents port and bit is set for ports that are OTG capable.
    0-7 bits represent USB3.0 ports with Port 0 on LSB.
    8-15 bits represent USB2.0 ports with Port 0 on bit 8.
    Ex: <0x0101> represents USB3.0 port 0 and USB2.0 port 0 are OTG capable.

Optional properties:

  • nvidia,gpio_controls_muxed_ss_lanes : SATA lane on some boards is muxed
    between SATA and XUSB. This property indicates if SATA lane is muxed and
    controlled by gpio or is it dedicated to XUSB. Assumed no gpio is present
    if this property is not defined.
  • nvidia,gpio_ss1_sata : reference to gpio that controls SATA lane muxed
    between XUSB & SATA. Only valid if above property is set. XUSB will be
    selected by setting this gpio to 1 in the driver.
  • utmi_padX : X can take number of USB2.0 ports on device.
    Ex: utmi_pad0, utmi_pad3
    provides details about vbus type used and ref to enable pin
    Over current detection is possible if vbus is controlled by XUSB.
    If not defined, vbus is assumed to be fixed and controlled by regulator
    framework. It contains 2 sub nodes.
    • nvidia,vbus_en_type : vbus source for XUSB ports. Possible values
      are 0-2 explained below. Defaults to zero when not defined.
      0 = VBUS enabled by GPIO, without PADCTL OC detection
      vbus is controlled by gpio and owned by regulator framework.
      XUSB padctl over current detection is disabled.
      1 = VBUS enabled by GPIO, with PADCTL OC detection
      vbus is controlled by gpio and owned by regulator framework.
      XUSB padctl over current detection is enabled
      2 = VBUS enabled by XUSB PADCTL with OC detection
      vbus is controlled by XUSB driver using VBUS_EN pins.
      XUSB padctl overcurrent detection is disabled.
    • nvidia,vbus_en_pin : If vbus is controlled by XUSB, enable pin for
      controlling vbus.
16

Can this be clarified for the jetson tx1 to be configured in android otg device mode for USB0?