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.
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.
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:
we make our own custom board with raw X1 chip on it
or
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?
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?
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.