Jetson Xavier NX Series Adaptation and Bring-Up
This topic describes how to port NVIDIA® Jetson™ Linux (L4T) from NVIDIA® Jetson Xavier™ NX Developer Kit to another hardware platform.
The examples described include code for the Jetson Xavier NX Developer Kit (P3518).
For information on customizing the configuration files, see the topic Jetson Xavier NX Series and Jetson AGX Xavier MB1 Platform Configuration.
Board Configuration
Jetson Xavier NX Developer Kit includes a P3668-0000 System on Module (SOM) connected to a P3509-0000 carrier board. P‑number P3518 designates the complete Jetson Xavier NX Developer Kit. The SOM and carrier board each have an EEPROM where the board ID is saved. The SOM can be used without any software configuration modifications.
The Jetson Xavier NX modules have a provision for attaching a heatsink or fansink. The module provided with the Jetson Xavier NX Developer Kit has a fansink already attached. See the Jetson Xavier NX Thermal Design Guide for guidance when designing or procuring a thermal solution for production Jetson Xavier NX modules.
Before using the SOM with a carrier board other than P3509, change the kernel device tree, MB1 configuration, ODM data, and flashing configuration to accommodate the new carrier board instead of P3509. An EEPROM ID for your custom board is not required.
You can also use the reference carrier board P3449-0000 (included in the Jetson Nano Developer Kit) with a Jetson Xavier NX module. The L4T installer detects the type of module and carrier board and automatically installs the appropriate drivers and other device-specific components.
Board Naming
To support a Jetson Xavier NX module with your custom carrier board, you must assign the module/carrier board combination a board name. This name must consist of lower case letters, numerals, hyphens, and underscores. You must set the board name in the environment variable BOARD on your Linux host system.
Some examples of valid board names are p3509-0000+p3668-0000, p3518-0000-devkit, and devboard.
The installation process uses the board name in filenames and pathnames, including names in the device tree and proc filesystem.
The placeholder <board> is used to represent the board name throughout this topic. Where this topic shows a command that contains <board>, substitute the name of your custom board.
Note: | Do not modify files whose filenames and pathnames contain your system’s default board name. The default board name refers to the carrier board provided with your Jetson developer kit. If it appears in a file’s name, that file contains code or data that is specific to that board. Make copies of such files that are named with your custom board’s board name, and modify them to support your custom board. |
Root Filesystem Configuration
L4T can use any standard or customized Linux root filesystem (rootfs) that is appropriate for their targeted embedded applications.
However, certain settings must be configured in the rootfs’s boot-up framework to set default configuration after boot, or some of the core functionalities will not run as expected.
For example:
1. The nv.sh and nvfb.sh boot-up scripts do some platform-specific configuration in the kernel.
2. The Xorg and X libraries must be correctly configured for the target device.
3. The nvpmodel clock and frequency must be configured for the target device.
These rootfs configurations and customizations are provided in this driver package in the directory and its subdirectories:
Linux_for_Tegra/nv_tegra/
You must incorporate the relevant customization for your target rootfs from this location.
Note: | For the sample Ubuntu root filesystem provided by NVIDIA, this customization is applied using the script Linux_for_Tegra/apply_binaries.sh. |
MB1 Configuration Changes
Multiple .cfg files define boot time configuration of the hardware. They are applied by Bootloader. The MB1 boot configuration tables are available at:
<l4t_top>/bootloader/t186ref/BCT
Where <l4t_top> is the top-level BSP flashing directory.
Pinmux Changes
If your board schematic differs from that for Jetson Xavier NX Developer Kit board, you must change the pinmux configuration applied by the software.
To define your board’s pinmux configuration, download the Jetson Xavier NX pinmux table from the Jetson Download Center. Be sure to get the right version of the table for your SOM. The table is a spreadsheet provided to:
• Show the locations and default pinmux settings
• Define the pinmux settings in the source code or device tree
You must customize the spreadsheet for the configuration of your board.
Once done, you must convert the .dtsi file generated by Excel to a .cfg. For instructions, see the README file at:
Linux_for_Tegra/kernel/pinmux/t19x/
You must perform the same conversion for gpio.dtsi and padvoltage.dtsi.
GPIO Changes
If you designed your own carrier board, to translate from SOM connector pins to actual GPIO numbers you must understand the GPIO mapping formula below. The translated GPIO numbers can be controlled by the driver.
For example, to check the GPIO number of signal name SPI0_CS1, perform the following procedure.
To check the GPIO number
1. Open the Jetson Xavier NX pinmux table. (See Pinmux Changes, above.)
2. Search the table for SPI0_CS1.
3. Confirm that the Customer Usage field contains the GPIO name GPIO3_PZ.07.
4. Refer to tegra194-gpio.h to determine the GPIO group that the GPIO belongs to and the port index of the GPIO port in the group. The port index is determined by the last letter before the dot in the port name. For example, GPIO3_PZ.07 belongs to the main Jetson GPIO group, and its port index is 25:
#define TEGRA_MAIN_GPIO_PORT_Z 25
5. Because the Linux kernel assigns GPIO ports dynamically, you must search kernel messages to find the base index of each GPIO group, that is, the offset of the first GPIO port assigned to the controller. The command and resulting output are similar to:
$ sudo grep tegra-gpio /sys/kernel/debug/gpio
gpiochip1: GPIOs 256-319, parent: platform/c2f0000.gpio, tegra-gpio-aon:
gpiochip0: GPIOs 320-511, parent: platform/2200000.gpio, tegra-gpio:
In this example the output shows that because GPIO3-PZ.07 belongs to the tegra-gpio group, its base index is 320.
6. The last part of the GPIO name indicates the GPIO’s pin index, that is the index of the pin within the GPIO port. In this example the pin index of GPIO3_PZ.07 is 7.
7. Use this formula to calculate the GPIO number:
Linux GPIO number = (base + (8 * port) + pin)
Where:
• base is the base index the GPIO controller, i.e. the offset of the first GPIO port assigned to the controller by the Linux kernel. In this case it is 320.
• port is the index within the GPIO controller of the Jetson GPIO port that the GPIO belongs to. In this case it is 25.
• pin is the index of the pin within the GPIO port. In this case it is 7.
Hence, the GPIO number of SPI0_CS1 is 320+(8*25)+7 = 527.
PMIC Changes
The PMIC configuration file configures the initial PMIC in the P3668 SOM. Some GPIO expander-based GPIO regulator settings in the P3509 carrier board configurations are also defined. Review this configuration file to replace any references to the P3509 carrier board with references to your custom board. If required, include any regulator information to enable this file.
For example, the following settings configure PMIC to turn on SD4 on I2C address 0x3c. The example is from the configuration file tegra194-mb1-bct-pmic-p3668-0001-a00.cfg.
######################## System Configurations ####
# PMIC FPS to turn SD4 (VDD_DDR_1V1) on in time slot 0
# PMIC FPS to set GPIO2 (EN_DDR_VDDQ) high in time slot 1
# Set SLPEN = 1 and CLRSE on POR reset
pmic.system.block[0].type = -1; # I2C
pmic.system.block[0].controller-id = 4;
pmic.system.block[0].slave-add = 0x78; # 7BIt:0x3c
pmic.system.block[0].reg-data-size = 8;
pmic.system.block[0].reg-add-size = 8;
pmic.system.block[0].block-delay = 10;
pmic.system.block[0].commands[0].0x53.0x38 = 0x00; #_SD4 FPS UP slot 0
pmic.system.block[0].commands[1].0x55.0x38 = 0x10; #_GPIO2 FPS UP slot 2
pmic.system.block[0].commands[2].0x41.0x1C = 0x1C; #_SLPEN=1, CLRSE = 11
Porting the Linux Kernel
It is assumed that you are using a P3668 SOM connected to a P3509 carrier board which has not been modified; the QSPI, PMIC, and DDR are the same with the same routing of lines. The modifications you are making are for the SOM and the carrier board. Consequently, based on the peripherals present on your carrier board, you can modify the .dts files by disabling/enabling the controllers and changing the supplies.
To port the kernel configuration code (the device tree) to your platform, modify one of the distributed configuration files to describe the design of your platform.
The configuration files are available at:
<top>/hardware/nvidia/platform/t19x/
<top>/hardware/nvidia/soc/t19x
The final DTB file used is:
tegra194-p3668-0000-p3509-0000.dtb
By reading the above file, you see which other .dtsi files are referenced by include statements. Common .dtsi files that may be modified to reflect hardware design changes include:
Types of Changes | DTSI Filename or location |
|---|---|
Power supply changes | tegra194-power-tree-p3668.dtsi |
Regulator parameter changes | tegra194-spmic-p3668.dtsi |
Display panel and node changes | |
ODM data based feature configuration | tegra194-plugin-manager-p3668.dtsi |
NVIDIA SoC controller state to enable/disable a controller | soc/t19x/kernel-dts/tegra194-soc/ |
Panels related .dts files | platform/tegra/common/kernel-dts/panels/ |
Verify that no other .dts or .dtsi file, including these .dts files, overrides any changes you make.
As a best practice, create your own set of .dts files based on the NVIDIA® Jetson AGX Xavier™ files already present. Rename your newly created files to the name of your board.
Note: | Use fdtdump or dtc to generate a .dts from the final .dtb file and check if your changes have taken effect. |
The command usage is:
dtc -I dtb -O dts tegra194-p3668-all-p3509-0000.dtb > tegra194-p3668-all-p3509-0000.dts
fdtdump dts tegra194-p3668-all-p3509-0000.dtb > tegra194-p3668-all-p3509-0000.dts
PCIe Controller Configuration
The NVIDIA® Xavier™ SoC has six PCIe controllers that are supported by the HSIO, and NVHS UPHY bricks. All six controllers cannot be enabled at the same time.
The following table shows the PCIe controllers supported by Jetson Xavier NX series. Both controllers support ASPM L0s, L1, L1.1, and L1.2.
PCIE controller | Controller mode | Supported link width | Supported link speed |
|---|---|---|---|
PCIe C4 | Root Port mode | x1 | Gen4 |
PCIe C5 | Root port or Endpoint mode * | Up to x8 | Gen4 |
* The mode is fixed during flashing, and cannot be switched at run time. | |||
Jetson Xavier NX Developer Kit Default PCIe Configuration
The Jetson Xavier NX Developer Kit default PCIe configuration is:
PCIE controller | Controller mode | Supported link width | PCIe slot |
|---|---|---|---|
PCIe C4 | Root Port mode | x1 | M.2 Key E slot; Operates any Key E form factor card (e.g. WiFi). |
PCIe C5 | Root Port or Endpoint mode | x4 | M.2 Key M slot; Operates any Key M form factor card. Cannot operate NVMe cards. |
Enabling PCIe in a Customer CVB Design
To enable PCIe in a custom CVB design:
1. Select a UPHY configuration from UPHY Lane Assignment that suits the CVB design, and update ODMDATA accordingly.
2. Configure the PCIe reset (PEX_L*_RST_N) and clkreq (PEX_L*_CLKREQ_N) according to the following table. To update the pinmux value, refer to Pinmux Changes.
The pinmux settings for Root Port mode are:
Mode | Pinmux | Customer Usage | Pin Direction | 3.3V Tolerance |
Root port | PEX_L*_RST_N | SFIO(PE*_RST_L) | Output | Enabled |
PEX_L*_CLKREQ_N | SFIO(PE*_CLKREQ_L) | Bidirectional | Enabled | |
Endpoint | PEX_L*_RST_N | GPIO(rsvd1) | Input | Enabled |
PEX_L*_CLKREQ_N | SFIO(PE*_CLKREQ_L) | Bidirectional | Enabled |
3. Enable the appropriate PCIe node listed under topic "Here are the PCIe controller DT nodes:":
4. Add the pipe2uphy phandle entries as a phy property in the PCIe controller DT node.
pipe2uphy DT nodes are defined in the SoC device tree in the file <TOP>/hardware/nvidia/soc/t19x/kernel-dts/tegra194-soc/tegra194-soc-pcie.dtsi.
Each pipe2uphy(p2u) node’s phandle name matches with UPHY lanes that are defined in UPHY Lane Assignment.
5. If the Jetson PCIe is operated in Endpoint mode, add the reset-gpios property with the GPIO phandle, the GPIO number connected to PERST#, and flags(GPIO_ACTIVE_LOW).
6. If platform-specific regulators are used to power up endpoints, the regulators can be registered as vpcie3v3-supply and/or vpcie12v-supply in the PCIe controller’s device tree node. The Jetson PCIe controller driver enable the regulators before the PCIe LTSSM sequence starts.
7. For information about Jetson Xavier NX PCIe controller device tree configurations, see the documentation file in the kernel source code tarball.
The file <TOP>/kernel/nvidia/Documentation/devicetree/bindings/pci/nvidia,tegra19x-pcie.txt covers topics that include configuring maximum link speed, link width, advertisement of different ASPM states, and others.
This table describes the PCIe controller device tree nodes:
PCIe controller and mode | PCIe controller device tree node |
PCIe C4 RP | pcie@14160000 |
PCIe C5 RP | pcie@141a0000 |
PCIe C4 EP | pcie_ep@14160000 |
PCIe C5 EP | pcie_ep@141a0000 |
PCIe Configuration Example
This example configures C5 x8 in either Root Port mode or Endpoint mode:
<TOP>/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi
pcie@14160000 {
status = "okay";
nvidia,pex-wake = <&tegra_main_gpio TEGRA194_MAIN_GPIO(L, 2) GPIO_ACTIVE_HIGH>;
vddio-pex-ctl-supply = <&p3668_spmic_sd3>;
nvidia,disable-aspm-states = <0xf>;
nvidia,enable-power-down;
nvidia,max-speed = <3>;
num-lanes = <1>;
phys = <&p2u_11>;
phy-names = "pcie-p2u-0";
};
pcie@141a0000 {
status = "okay";
vddio-pex-ctl-supply = <&p3668_spmic_sd3>;
nvidia,disable-aspm-states = <0xf>;
nvidia,enable-power-down;
nvidia,max-speed = <4>;
phys = <&p2u_12>,
<&p2u_13>,
<&p2u_14>,
<&p2u_15>,
<&p2u_16>,
<&p2u_17>,
<&p2u_18>,
<&p2u_19>;
phy-names = "pcie-p2u-0", "pcie-p2u-1", "pcie-p2u-2", "pcie-p2u-3","pcie-p2u-4", "pcie-p2u-5", "pcie-p2u-6", "pcie-p2u-7";
};
pcie_ep@141a0000 {
status = "disabled";
nvidia,disable-aspm-states = <0xf>;
vddio-pex-ctl-supply = <&p3668_spmic_sd3>;
phys = <&p2u_12>, <&p2u_13>, <&p2u_14>, <&p2u_15>,
<&p2u_16>, <&p2u_17>, <&p2u_18>, <&p2u_19>;
phy-names = "pcie-p2u-0", "pcie-p2u-1", "pcie-p2u-2",
"pcie-p2u-3", "pcie-p2u-4", "pcie-p2u-5",
"pcie-p2u-6", "pcie-p2u-7";
nvidia,pex-rst-gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(GG, 1) GPIO_ACTIVE_LOW>;
};
Debug PCIe Link-Up Failure
After you make device tree changes as described in Enable PCIe in a Customer CVB Design and the PCIe link fails to come up, perform the following debug steps to triage the issue.
To triage link-up failure from the platform side
1. Delete the nvidia,enable-power-down device tree property in the PCIe controller node. After you add this device tree property, lspci lists the root port device as follows:
$ lspci
00:01.0 PCI bridge: NVIDIA Corporation Device 10e5 (rev a1)
2. Make sure that the following signals are being routed properly from the root port to the endpoint:
1. PERST#: Should go high when the root port attempts to link up.
2. CLKREQ#: ASPM is disabled by default, so this signal has no role in link up failure. If you enable ASPM L1-CPM or L1SS by completing the steps in Enabling the PCIe ASPM, verify that this signal is pulled low when the root port attempts to link up.
3. REFCLK: Should flow from the root port to the endpoint. Connect an oscilloscope and observe the spread-enabled 100 MHz clock.
4. Tx and Rx: Verify that the Tx and Rx lanes routed correctly.
5. If any of the signals above go through board level muxes, verify that the muxes are configured correctly.
6. PCIe slot regulators or GPIOs: If PCIe slot regulators are present, verify that they are powered up. If the endpoint expects some GPIO signals to be toggled as part of power up sequence, verify that they are being toggled correctly.
For example, some Wi-Fi cards expect WDISABLE_1 to be asserted before PCIe link up.
To triage link-up failure from the software side
1. Verify that the status of the root port LnkSta is DLActive in the output of a lspci ‑vvv command. This shows whether the link comes up by the time kernel boots to shell (correct) or is taking longer to come up (incorrect).
2. Dump the pinmux values PADCTL_PEX_CTL_PEX_L*_CLKREQ_N_0 and PADCTL_PEX_CTL_PEX_L*_RST_N_0 and check whether their settings are correct.
3. Dump the register PCIE_RP_APPL_DEBUG_0. See the Xavier Series SoC Technical Reference Manual for the register address of each controller. This information will help NVIDIA determine the LTSSM state.
Note that accessing the controller's address when it is not enabled causes a CBB power-down error.
4. Use the device tree properties to reduce the link speed to Gen1 and the link width to x1.
Enabling the PCIe ASPM
To enable the PCIe ASPM:
1. If the card supports L1-CPM or L1SS, delete nvidia,disable-l1-cpm and nvidia,disable-clock-request in the respective controller device tree node.
Enabling this property for an endpoint that does not support L1-CPM or L1SS causes a PCIe link-up failure.
2. To enable the desired ASPM state, clear the respective bit in the nvidia,disable-aspm-states property.
nvidia,disable-aspm-states value | ASPM status |
|---|---|
0xf | All states disabled |
0xe | ASPM L0s enabled, L1, L1.1 & L1.2 disabled |
0xd | ASPM L1 enabled, L0s, L1.1 & L1.2 disabled |
0xC | ASPM L0s & L1 enabled, L1.1 & L1.2 disabled |
0x8 | ASPM L0s, L1 & L1.1 enabled, L1.2 disabled |
0x1 | ASPM L1, L1.1 & L1.2 enabled, L0s disabled |
0x0 | All ASPM states enabled |
Confirm the status of the different ASPM states from the lspci -vvv command’s output and aspm_state_count in the PCIe RP controller's debugfs.
Porting USB (Universal Serial Bus)
Jetson Xavier NX series modules can support one enhanced SuperSpeed USB port and up to three High Speed USB ports. The Jetson Xavier NX P3509 carrier board is designed and verified for one USB3.1 port. If you design your own carrier board, verify the compatibility between P3509 and your own board by consulting the NVIDIA team.
USB Structure
An enhanced SuperSpeed USB port has nine pins:
• VBUS
• GND
• D+
• D−
• Two differential signal pairs for SuperSpeed data transfer
• One ground (GND_DRAIN) for drain wire termination and managing EMI, RFI, and signal integrity
The D+/D− signal pins connect to UTMI pads. The SSTX/SSRX signal pins connect to UPHY and are handled by a single UPHY lane. As UPHY lanes are shared between PCIE, SATA, UFS, and XUSB, UPHY lanes must be assigned according to the custom carrier board’s requirements.
Required Device Tree Changes
This section gives step-by-step guidance for checking schematics and configuring USB ports in the device tree. All of the examples are based on the design of the Jetson Xavier NX P3509 carrier board.
For a Host-Only Port
This section uses U7, a USB 3.1 Gen2 Realtek Enhanced SuperSpeed on-board hub, model number RTS5489-GR (hereafter “Realtek hub”) as an example of a host-only port.
Go Through the Schematics
Note: | The P3509 carrier board’s schematic file is included in the “Jetson Xavier NX Developer Kit Carrier Board Design Files” archive, available from the Jetson Download Center. (Search for some consecutive words separated by spaces, e.g. “Xavier NX Developer Kit Carrier.”) |
Check the Realtek hub on the P3509 carrier board and find the socket location wired to the P3668 SOM.
• USB2 signal pins D+/D- (USP_D_P/USP_D_N) wire out from U7 and lead to module socket pins 117 (USB1_D) and 115 (USB1_D).
• USB3 differential pairs (USP_TX_* and USP_RX_*) wire out from U7 and lead to module socket pins 161 (SBSS_RX) and 168 (USBSS_TX).
Through the schematic, you can conclude that for U7:
• The USB2 signal pair is wired to UTMI pad 1 (USB2 port 1).
• The USB 3 signal pairs are wired to UPHY lane 1 (USB 3.1 port 2).
The xusb_padctl Node
The device tree’s xusb_padctl node follows the conventions of pinctrl-bindings.txt. It contains two groups, named pads and ports, which describe USB2 and USB3 signals along with parameters and port numbers. The name of each parameter description subnode in pads and ports must be in the form <type>-<port_number>, where <type> is "usb2" or "usb3", and <port_number> is the associated port number.
The properties of the pads subnode are:
• nvidia,function: A string containing the name of the function to mux to the pin or group. Must be "xusb".
The properties of the ports subnode are:
• mode: A string that describes USB port capability. A port for USB2 must have this property. It must be one of these values:
• host
• device
• otg
• nvidia,usb2-companion: USB2 port (0, 1, or 2) to which the port is mapped. A port for USB3 must have this property.
• nvidia,oc-pin: The overcurrent VBUS pin the port is using. The value must be positive or zero.
Note: | Overcurrent detection and handling for U7, a Realtek hub on the P3509 carrier board, are controlled by the hub itself. Therefore, you need not set this property. |
• vbus-supply: VBUS regulator for the corresponding UTMI pad. Set to &battery_reg for a dummy regulator.
Note: | As the Realtek hub is always connected to the root hub port on a P3509, you need not control hub power, just enable it with VDD_3V3_SYS. Therefore, you must set dummy regulators for U7 on the P3509 carrier board. |
For the detailed information about xusb_padctl, refer to the documentation at:
kernel/kernel-4.9/Documentation/devicetree/bindings/phy/nvidia,xusb-padctl.txt
As an example, consider U7, the Realtek hub, which is always connected to USB2 port 1 and USB3 port 2 on the root hub. Create a pad/port node and property list for U7 based on the device tree structure described above:
xusb_padctl: xusb_padctl@3520000 {
...
pads {
usb2 {
lanes {
usb2-1 {
nvidia,function = "xusb";
status = "okay";
};
...
};
};
usb3 {
lanes {
usb3-2 {
nvidia,function = "xusb";
status = "okay";
};
};
};
};
ports {
...
usb2-1 {
mode = "host";
status = "okay";
};
...
usb3-0 {
nvidia,usb2-companion = <1>;
status = "okay";
};
};
};
Under the xHCI Node
The Jetson Xavier NX xHCI controller complies with xHCI specifications, which support both USB 2.0 High Speed / Full Speed / Low Speed and USB 3.1 SuperSpeed protocols.
The properties of the node are:
• phys: Must contain an entry for each entry in phy-names.
• phy-names: Must include an entry for each PHY used by the controller. Names must be in the form <type>-<port_number>, where <type> is "usb2" or "usb3", and <port_number> is the associated port number.
• nvidia,boost_cpu_freq: Set the value to which CPU frequency will be boosted. This is only the minimum frequency; DVFS can scale up CPU frequency further based on need and CPU loading. CPU boost frequency is enabled through PMQOS for the xHCI controller only when this field’s value is greater than zero. The boost is applicable only for bulk and ISOC transfers; other endpoints do not need to be boosted.
• nvidia,boost_cpu_trigger: Minimum buffer length of bulk or ISOC transfers beyond which to boost frequency.
• nvidia,xusb-padctl: A pointer to the xusb-padctl node.
For detailed information about xHCI, refer to the documentation at:
kernel/kernel-4.9/Documentation/devicetree/bindings/usb/nvidia,tegra-xhci.txt
Consider U7, the Realtek hub, as an example. Create an xHCI node and property list for U7 based on the device tree structure described above:
tegra_xhci: xhci@3610000 {
...
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-2}>;
phy-names = "usb2-1", "usb3-2";
nvidia,xusb-padctl = <&xusb_padctl>;
status = "okay";
...
};
For an OTG (On-The-Go) Port
USB On-The-Go, often abbreviated USB OTG or just OTG, is a specification that allows USB to act as a host or a device in the same port. A USB OTG port can switch back and forth between the roles of host and device.
This section takes J5, USB2.0 Micro B connector, as an example of an OTG port.
An OTG port adds a fifth pin to the standard USB connector, called the ID pin. An OTG cable has an A-plug on one end and a B-plug on the other end. The A-plug’s ID pin is grounded, while the B-plug’s ID pin is floating. A device with an A-plug inserted becomes and OTG A-device (a host), and a device with a B-plug inserted becomes a B-device (a device).
Note: | Because its ID pin is floating, J5 is fixed in the device role in the Jetson Xavier NX Developer Kit. It cannot function as a host, e.g. to connect a flash drive, keyboard, or mouse. |
Go Through the Schematics
Note: | The P3509 carrier board’s schematic file is included in Jetson Xavier NX Developer Kit Carrier Board Design Files, available from the Jetson Download Center. |
Check the USB connectors on the P3509 carrier board and find the socket location wired to the P3668 SOM.
• USB2 signal pins D+/D− (DP and DN) wire out from J5 and lead to pin 111 (USB0_D) and pin 109 (USB0_D) on the SOM socket.
The USB 2.0 Micro B connector, J5, supports only HighSpeed mode, and does not have USB3 signal pairs.
From the schematic, you can that for J5:
• The USB2 signal pair is wired to UTMI pad 0 (USB2 port 0).
The External Connector Class (extcon)
External connectors, which may have different types of cables attached (USB, TA, HDMI, Analog A/V, and others), often have device drivers that detect state changes at the port, and separate device drivers that do something according to the state changes.
The External Connector Class (extcon), introduced in 2012, supports the use of a notifier for passing information such as state changes between device drivers.
Generally, port switching between the roles of an OTG port is controlled by the host driver (xHCI) and device driver (xUDC), and can be defined by the state of the ID pin and the VBUS_DETECT pin.
Taking GPIO_M3 as the VBUS_DETECT pin and GPIO_Q0 as the ID pin, for example:
1. Find the corresponding GPIO states on the VBUS_DETECT pin and ID pin.
Generally, the ID pin is designed as internal pull high (logical high). With an A-plug connected the ID pin is pulled to ground (logical low), while with a B-plug connected or no cable connected it remains logical high.
The operation of the VBUS_DETECT pin depends on the device’s design. Consider the schematic in the following diagram, for example:
With a B-plug connected VBUS_DETECT is logical low, because VBUS is provided from an external power supply, and when no cable is connected it is logical high.
Note: | VBUS_DETECT is initially logical high, then logical low because VBUS is provided by the host controller. Therefore, the state of the VBUS_DETECT pin does not matter when the OTG port is operating in host mode. |
2. Create the table of GPIO states and their corresponding output cable states:
GPIO_Q0 (ID) | GPIO_M3 (VBUS_DETECT) | EXTCON_STATE |
|---|---|---|
1 | 1 | 0x0 (EXCON_NONE) |
0 | 0 | 0x2 (EXTCON_USB_HOST) |
0 | 1 | 0x2 (EXTCON_USB_HOST) |
1 | 0 | 0x1 (EXTCON_USB) |
Under the extcon Node
Port switching between the roles of an OTG port is defined by the state of the ID pin and the VBUS_DETECT pin and the settings of the external connector class.
• compatible: Value must be "extcon-gpio-states".
• extcon-gpio,name: Name of the extcon device.
• gpios: List of the GPIOs.
• extcon-gpio,irq-flags: IRQ flags for GPIO.
• extcon-gpio,debounce: Debounce time in milliseconds.
• extcon-gpio,wait-for-gpio-scan: Wait timeout for scanning all GPIOs’ states after a GPIO state change is detected and debounce time has passed.
• extcon-gpio,out-cable-names: Output cable names.
• extcon-gpio,cable-states: GPIO states and their corresponding output cable states. The value is an array of bytes. Each even-numbered byte is a GPIO state, and the following odd-numbered byte is the corresponding output cable state.
• cable-connected-on-boot: Name of the output cable connected on boot, expressed as an index into extcon-gpio,out-cable-names. The first element is index 0, and so on. If not specified, the system assumes that no cable is to be connected. This property is valid if no GPIOs are provided for cable states.
• wakeup-source: A Boolean; true if the device can wake up the system.
For the detailed information about extcon, refer to the documentation at:
kernel/kernel-4.9/Documentation/devicetree/bindings/extcon/extcon-gpio-states.txt
• Create an extcon device node and property list based on the device tree structure described above and the table of GPIO states and corresponding output cable states for GPIO_Q0 and GPIO_M3:
vbus_id_extcon: extcon@1 {
compatible = "extcon-gpio-states";
extcon-gpio,name = "VBUS_ID";
extcon-gpio,wait-for-gpio-scan = <0>;
extcon-gpio,cable-states = <0x3 0x0
0x0 0x2
0x1 0x2
0x2 0x1>;
gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(M, 3) 0
&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 0) 0>;
extcon-gpio,out-cable-names =
<EXTCON_USB EXTCON_USB_HOST EXTCON_NONE>;
#extcon-cells = <1>;
};
The USB 2.0 Micro B connector, J5, has the connector’s ID pin floating and the VBUS_DETECT pin of the connector wired out to GPIO00, which corresponds to GPIO_PZ1. Hence J5 can only function in the device role.
This table describes the GPIO states on J5 and the corresponding output cable states:
GPIO_PZ1 (VBUS_DETECT) | EXTCON_STATE |
1 | 0x0 (EXCON_NONE) |
0 | 0x1 (EXTCON_USB) |
This is the extcon device node and property list based on the device tree structure described above and the table of GPIO states and corresponding output cable states for GPIO_PZ1, customized for Jetson Xavier NX, where the ID pin is floating the port is fixed in the device role:
external-connection {
vbus_id_extcon: extcon@1 {
compatible = "extcon-gpio-states";
reg = <0x1>;
extcon-gpio,name = "VBUS";
extcon-gpio,cable-states = <
0x0 0x1
0x1 0x0>;
gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Z, 1) 0>;
extcon-gpio,out-cable-names = <EXTCON_USB EXTCON_USB_HOST EXTCON_NONE>;
wakeup-source;
#extcon-cells = <1>;
};
};
Note: | Check the pinmux spreadsheet for the GPIO that corresponds to the ID pin and VBUS_DETECT pin. |
Under the xusb_padctl Node
xusb_padctl settings for an OTG port are the same as for a host-only port except that the mode must be "otg".
Taking J5, the USB 2.0 Micro B connector, as an example, create a pad/port node and property list:
xusb_padctl: xusb_padctl@3520000 {
...
pads {
usb2 {
lanes {
usb2-0 {
nvidia,function = "xusb";
status = "okay";
};
...
};
};
...
};
ports {
usb2-0 {
mode = "otg";
vbus-supply = <&battery_reg>;
status = "okay";
};
...
};
};
Under the xHCI Node
The xHCI settings for an OTG port are the same as for a host-only port except for the addition of extcon settings:
• extcon-cables: OTG support. Must contain a pointer to the extcon-cable entry for the USB ID pin. When the extcon cable state is 0, the OTG port transitions to host mode.
• extcon-cable-names: Must be "id".
• #extcon-cells: Number of cells in the extcon specifier. Must be 1.
Taking J51 the USB 2.0 Micro B connector, as an example, create an xHCI node and property list based on the device tree structure described in Under the XHCI Node for a host-only port, plus the extcon settings above:
tegra_xhci: xhci@3610000 {
...
extcon-cables = <&vbus_id_extcon 1>;
extcon-cable-names = "id";
#extcon-cells = <1>;
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>;
phy-names = "usb2-0";
nvidia,xusb-padctl = <&xusb_padctl>;
status = "okay";
...
};
Under the xUDC Node
The Jetson Xavier NX xUDC controller supports both USB 2.0 High Speed / Full Speed and USB 3.1 SuperSpeed protocols.
• extcon-cables: OTG support. Must contains an extcon-cable entry which detects the USB VBUS pin. When the extcon cable state is 1, the OTG port transitions to device mode.
• extcon-cable-names: Must be "vbus".
• charger-detector: USB charger detection support. Must be the phandle of the USB charger detection driver DT node.
• phys: An array; must contain pointers to the nodes that define each PHY in phy-names.
• phy-names: An array; must contain an entry for each PHY used by the controller. Names must be in the form <type>-<port_number>, where <type> is one of "usb2" or "usb3", and <port_number> is the associated port number.
• nvidia,boost_cpu_freq: The value to which CPU frequency is to be boosted. This is only the minimum frequency; DVFS can scale up CPU frequency further based on need and CPU load. CPU boost frequency through PMQOS is enabled for the xUDC controller only when this field’s value is greater than zero. The boost is applicable only to large bulk transfers on bulk endpoints; other endpoints do not need to be boosted.
• nvidia,xusb-padctl: A pointer to the xusb-padctl node.
For detailed information about xUDC, refer to the documentation at:
kernel/kernel-4.9
/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
Taking J5, the USB 2.0 Micro B connector, as an example, create an xUDC node and property list for J5 based on the device tree structure described above:
tegra_xudc: xudc@3550000 {
extcon-cables = <&vbus_id_extcon 0>;
extcon-cable-names = "vbus";
#extcon-cells = <1>;
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-0}>;
phy-names = "usb2";
nvidia,xusb-padctl = <&xusb_padctl>;
nvidia,boost_cpu_freq = <1200>;
status = "okay";
};
Flashing the Build Image
When flashing the build image, use your specific board name. The flashing script uses the configuration in the <board>.conf file during the flashing process.
Setting Optional Environment Variables
flash.sh script updates the following environment variables based on board EEPROM and other parameters passed. If you want to give specific values to these variables, define them in the board-specific file <board>.conf to override the default values.
# Optional Environment Variables:
# BCTFILE ---------------- Boot control table configuration file to be used.
# BOARDID ---------------- Pass boardid to override EEPROM value
# BOARDREV --------------- Pass board_revision to override EEPROM value
# BOARDSKU --------------- Pass board_sku to override EEPROM value
# BOOTLOADER ------------- Bootloader binary to be flashed
# BOOTPARTLIMIT ---------- GPT data limit. (== Max BCT size + PPT size)
# BOOTPARTSIZE ----------- Total eMMC HW boot partition size.
# CFGFILE ---------------- Partition table configuration file to be used.
# CMDLINE ---------------- Target cmdline. See help for more information.
# DEVSECTSIZE ------------ Device Sector size. (default = 512Byte).
# DTBFILE ---------------- Device Tree file to be used.
# EMMCSIZE --------------- Size of target device eMMC (boot0+boot1+user).
# FLASHAPP --------------- Flash application running in host machine.
# FLASHER ---------------- Flash server running in target machine.
# INITRD ----------------- Initrd image file to be flashed.
# KERNEL_IMAGE ----------- Linux kernel zImage file to be flashed.
# MTS -------------------- MTS file name such as mts_si.
# MTSPREBOOT ------------- MTS preboot file name such as mts_preboot_si.
# NFSARGS ---------------- Static Network assignments; client, server,
# & gateway IP addresses & netmask in format:
# <c_IP>:<s_IP>:<g_IP>:<netmask>
# NFSROOT ---------------- NFSROOT, an IP address, colon, and path,
# e.g. 127.0.0.1:/exported/rootfs_dir.
# ODMDATA ---------------- Odmdata to be used.
# PKCKEY ----------------- RSA key file to use to sign bootloader images.
# ROOTFSSIZE ------------- Linux RootFS size (internal emmc/nand only).
# ROOTFS_DIR ------------- Linux RootFS directory name.
# SBKKEY ----------------- SBK key file to use to encrypt bootloader images.
# SCEFILE ---------------- SCE firmware file such as camera-rtcpu-sce.img.
# SPEFILE ---------------- SPE firmware file path such as bootloader/spe.bin.
# FAB -------------------- Target board's FAB ID.
# TEGRABOOT -------------- lowerlayer bootloader such as nvtboot.bin.
# WB0BOOT ---------------- Warmboot code such as nvtbootwb0.bin
Note: | All the parameters must be added below the reference to the p3668.conf.common file to be reflected in the flashed image. |
Here is an example of environment variable settings for the Jetson Xavier NX Developer Kit .conf file, p3509-0000+p3668-0000-qspi-sd.conf:
source "${LDK_DIR}/p3668.conf.common";
BLBlockSize=1048576;
EMMC_CFG=flash_l4t_t194_spi_sd_p3668.xml;
RECROOTFSSIZE=100MiB
To flash the build image
• Execute the following command:
$ sudo ./flash.sh <board> mmcblk0p1