USB, PEX, & SATA Use Case 2 -- Three USB 3 Ports

From the Jetson TX1 OEM Product Design Guide tables 10 and 11 I see that there is a configuration mode where one could configure the TX1 module to provide PCIex1, PCIex4, USB_SS#1, USB_SS#0, AND USB_SS#3 (mux’d on the SATA pins). At least that is what Table 10 shows. Table 11 only shows 1 USB 3 port in that case.

So the question is, what is the difference between those tables? I’d be making my own carrier boards so I wouldn’t be limited to the h/w of the reference carrier board.

Also, there is a note about muxing the USB_SS#3 and SATA pins and that it was verified at the chip but not on the module and that software would have to support it. Has there been any recent change to that? Has anyone been able to get this to work? If so, how?

As Note 5 said: Table 11 shows configurations compatible with Jetson TX1 and possible future pin-compatible modules. You can make your own carrier board following table 10.

For the support question of software, below topic shows details:
https://devtalk.nvidia.com/default/topic/925646/jetson-tx1/tx1-usb3-0-design/

Thanks Trumany.

It looks like the “Jetson_TX1_Generic_Customer_Pinmux_Customer_Release.xlsm” file doesn’t support the configuration for USB, PEX, & SATA Use Case 2 as per Table 10.

Is that intended? There is no alternate function to select for the SATA pins.

Yes, the USB_SS3 option was removed from SATA pins in JTX1 module pinmux.

So is it available or not? I’m confused.

Is the SATA/USB_SS#3 switching available on the chip but not on the TX1 module? Or is it available on the module but not on the development carrier board?

I’m confused because above you said that if we were making our own Carrier Board then we could use Table 10. I interpret that to say that those signals are available in the TX1 module pinout. But that isn’t clear.

Can you clarify please? In what case does Table 10 apply:

  1. we make our own custom board with raw X1 chip on it

or

  1. we design our own Carrier Board (i.e. make a custom board with TX1 module interface on it, like the NVIDIA development board but with our own shape and external peripherals)?

If it is 2) then how do we enable USB_SS#3 on the SATA pin?

Hi JamesMorrison,

As note 1 said: The USB 3.0 controller #3 on the SATA pins has been verified at the chip level, but not on the module, and is not supported with the released Software.

To hardware, you can use case #5 ( USB_SS#0 is used for LAN on Jetson TX1 module in case #2) of table 10 to achieve 3 USB3.0 ports on your own carrier board in which SATA routing should follow layout rules of USB3.0, but to software you need to tune it by your own as it’s not supported with released software.

So how would we configure the SATA bus to have USB_SS#3 functionality? The pin mux doesn’t allow for that. We can tune the software but how do we get the pin mux configuration details?

ping…

Hello,
Here are the DTS details about USB SS. You may have to change the DTS 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.