Nvidia JETSON NANO User manual

DA_09361-002 |
July 2, 2019
L4T Driver Package
JETSON NANO PLATFORM
ADAPTATION AND BRING-UP
GUIDE

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | ii
Document Change History
DA_09361-002
Version Date Authors Description of Change
v1.0 18 Mar 2019 jsachs Initial release
v1.1 2 Jul 2019 jsachs Corrected initial release

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | iii
Table of Contents
Platform Adaptation and Bring-Up.................................................1
Board Configuration............................................................................. 1
Board Naming.................................................................................... 2
Placeholders in the Porting Instructions...................................................... 2
Root Filesystem Configuration................................................................. 3
Pinmux Changes................................................................................. 3
Exporting Pinmux for U-Boot .................................................................. 4
Accessing GPIOs via “gpio” Device Labels ................................................... 6
Exporting Pinmux for the L4T Linux Kernel.................................................. 6
Porting U-Boot................................................................................... 6
Porting the Linux Kernel........................................................................ 7
Porting USB ...................................................................................... 9
USB Structure................................................................................. 9
UPHY Lane Assignment...................................................................... 9
Required Device Tree Changes............................................................12
For a Host-Only Port..................................................................... 12
For an OTG (On-The-Go) Port..........................................................16
Fan speed control mapping table ............................................................25
Other Considerations When Porting ......................................................... 26
Boot Time Reduction...........................................................................26
Root Filesystem..............................................................................26
Kernel .........................................................................................27
Hardware Bring-Up Checklist .................................................................27
Before Power-On ............................................................................28
Initial Power-On .............................................................................28
Initial Software Flashing....................................................................28
Power .........................................................................................29
Power Optimization ......................................................................... 29
USB 2.0 PHY .................................................................................29
USB 3.0 .......................................................................................30
HDMI..........................................................................................30
Audio..........................................................................................30
UART..........................................................................................30
SD Card (SDMMC1) .........................................................................31
Fan ............................................................................................31
Sensors I2C: General .......................................................................31
Sensors I2C: Touch Screen (Optional)....................................................31

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | iv
PEX (Optional) ...............................................................................31
Embedded Display(s) (Optional)...........................................................32
Imager(s) (Optional)........................................................................32
Software Bring-Up Checklist ..................................................................33
Preparation...................................................................................33
Bring-up Hardware Validation..............................................................33
U-Boot Port and Boot Validation...........................................................33
Kernel and Peripherals, Port and Validation..............................................33
System Power and Clocks ..................................................................34
List of Figures
Figure 1. An OTG port connector ...............................................................16
Figure 2. Example of an OTG port's general design..........................................18
List of Tables
Table 1. Available outputs for the P3449 carrier board ...................................... 10
Table 2. UPHY lane assignment use cases .................................................... 10
Table 3. GPIO states and corresponding output cable states...............................19

Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002| 1
Platform Adaptation and Bring-Up
This document is for software developers whose target is the NVIDIA®Jetson Nano™
module. It describes how to port the NVIDIA®Tegra®Linux Driver Package (L4T) and
the U-Boot boot loader from NVIDIA®Jetson Nano™ Developer Kit to other hardware
platforms.
For all of the procedures in this document, the L4T release includes code for the Jetson
Nano Developer Kit (P3450) that can serve as an example.
Board Configuration
The Jetson Nano Developer Kit consists of a P3448 System on Module (SOM) connected
to a P3449 carrier board. The number P3450 designates the complete Jetson Nano
Developer Kit. The SOM and carrier board each has an EEPROM where the board ID is
saved.
The SOM sold for incorporation into customer products is designated P3448-00201. It
differs from the SOM included with the developer kit, which is designated P3448-0000.
It offers 16GB eMMC storage instead of a microSD card slot, has a five year operating
lifetime, and is qualified for deployment in a commercial environment. P3448-0020 can
be used with the P3449 carrier board.2
Before you use a P3448 SOM with a carrier board other than P3449, change the kernel
device tree, bootloader configuration, ODM data, and flashing configuration to
configure for the new carrier board instead of P3449. An EEPROM ID for your custom
board is not required.
1900-13448-0020-000 is the full SOM part number.
2Version A02 of the P3449 carrier board is not compatible with the P3448-0020 SOM.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 2
Board Naming
To support a Jetson Nano module together with your carrier board in L4T, you must
choose a simple lower-case, alphanumeric name for your board, possibly including
dashes (-) or underscores (_), but no spaces. Following are some examples of valid board
names:
jetson-nano
jetson-tx1
p3450
The name you choose will appear in file names and path names in U-Boot and Linux
kernel source code and in user-visible device tree file names, and will be exposed to the
user via the U-Boot command prompt and various Linux kernel /proc files.
You must also choose a similarly constructed vendor name. The same character set rules
apply, as in this example:
nvidia
In this document:
•<board> represents your board name.
•<vendor> represents your vendor name.
Note: Do not simply re-use and modify the existing Jetson Nano Developer
Kit code without choosing and using your own board name. If you do
not use your own board name it will not be obvious to Jetson Nano
users whether modified source code supports your board or the
original Jetson Nano Developer Kit carrier board.
Placeholders in the Porting Instructions
The sections below refer to filenames and pathnames that contain the following
placeholders. Substitute an appropriate value for each placeholder when you enter the
commands.
•<function>is a functional module name, such as power-tree, pinmux, sdmmc-
drv, keys, comm (Wi-Fi/Bluetooth®), camera, etc.
•<board> is a name you have chosen to represent your carrier board with Jetson
Nano module. For example, p3450 could represent the carrier board from a Jetson
Nano Developer Kit with a Jetson Nano module. Note that NVIDIA <board> names
use lower case letters only.
•<som>is a System on a Module (SOM) board name, such as p3448.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 3
•<version> is a board version number, such as a00. Files for NVIDIA reference
boards include a version number. Files for customer platforms need not include one.
•<vendor> is your organization’s name, or the name of your board’s vendor.
•<root>is the device that holds the platform’s root file system. At present the only
supported value is emmc/sdcard.
Root Filesystem Configuration
Tegra Linux platforms 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 system must be configured to execute the nv.sh, nvfb-early.sh, and
nvfb.sh scripts in etc at boot-up because they perform some basic default board
initialization in the kernel. It is advisable to add to the etc folder but never delete
anything from it.
2. The Xorg and X libraries must be correctly configured for the target device.
3. In the target device’s nvpmodel, the number of cores, clock, and frequency must be
configured.
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.
Pinmux Changes
If your board schematic differs from that for Jetson Nano Developer Kit carrier board,
you must change the pinmux configuration applied by the software.
To define your board’s pinmux configuration, you must obtain
Jetson_Nano_customer_pinmux_release.xlsm from NVIDIA and customize it
for the configuration of your board using the following procedures.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 4
To customize the pinmux spreadsheet
1. Create a copy of the file with a name based on your board name, e.g.
<board>_pinmux.xlsm.
2. Ensure that the new file is writable.
3. On a Windows PC, open the new file in Microsoft Excel.
4. If Microsoft Excel displays any warnings such as “PROTECTED VIEW” or
“SECURITY WARNING,” click Enable Editing or Enable Content, so that you can
save your changes to the new file.
5. Rename the Jetson Nano Configuration tab based on the name of your board:
1. Right click the Jetson Nano Configuration tab at the bottom of the window.
2. Click the Rename menu option.
3. Type your board name into the tab, then press ENTER.
6. Modify columns AE through AO of the spreadsheet as required by the pinmux
configuration for your board, based on the schematic.
Once the spreadsheet reflects the configuration you want, export the configuration data
in a format that U-Boot and the Linux kernel can use.
Exporting Pinmux for U-Boot
U-Boot uses a header file to define the pinmux configuration. You can generate this
header file using the tegra-pinmux-scripts tool.
To customize tegra-pinmux-scripts for your board
1. Obtain tegra-pinmux-scripts by running the following commands on your
Linux system:
$ git clone https://github.com/NVIDIA/tegra-pinmux-scripts.git
$ cd tegra-pinmux-scripts
2. In the tegra-pinmux-scripts directory, open csv-to-board.py in a text
editor.
3. Locate the definition of the supported_boards data structure, at approximately
line 50.
4. Add an entry for your board to the supported_boards data structure as in this
example, substituting the board’s name for <board>:
'<board>': {
# <board>_pinmux.xlsm worksheet <board>
'filename': 'csv/<board>.csv',

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 5
'rsvd_based': 0,
'soc': 'tegra210',
},
Copy any other T210 board entry, replacing the reference to <board>.csv with
your CSV file’s name, e.g. csv/my-new-board.csv.
5. Save the file and exit the editor.
6. Commit the change to your local Git repository:
$ git add csv-to-board.py
$ git commit –a –m "Add support for <board>" –s
csv-to-board.py reads a CSV (Comma Separated Values) version of the pinmux
spreadsheet as input. This script (like other pinmux scripts) is customarily stored in the
directory tegra-pinmux-scripts.
To save the spreadsheet in CSV format
1. In Microsoft Excel, click the File tab.
2. On the File tab, click Save As.
3. From Save as type, choose CSV (MS-DOC) (*.csv).
4. Verify that the file name ends in .csv, but otherwise matches the file name in your
changes to csv-to-board.py. (See Pinmux Changes.)
5. Click Save.
6. Copy the CSV file to the csv/ directory of tegra-pinmux-scripts on your Linux
system.
To generate the U-Boot pinmux header file
1. Enter the following command in the tegra-pinmux-scripts directory to import
the data into the tegra-pinmux-script internal format:
$ ./csv-to-board.py <board>
Optionally, use the --csv <csv_file_name> command line option to specify the
CSV file to import. This allows you to copy the CSV file to an arbitrary location on
your Linux system.
2. Enter the following command to generate the U-Boot pinmux header file:
$ ./board-to-uboot.py <board> > pinmux-config-<board>.h
Later you will copy pinmux-config-<board>.h into the U-Boot source tree.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 6
Accessing GPIOs via “gpio” Device Labels
You can access GPIOs (routed to the 40-pin GPIO expansion header) via device labels
that begin with gpio. The file /sys/kernel/debug/gpio lists these labels.
For example, to access gpio-19, enter this command:
$ gpiofind SPI0_CS0
This command displays output like:
gpiochip0 19
Exporting Pinmux for the L4T Linux Kernel
The Linux kernel uses device tree files to define the pinmux configuration. You can
generate these files directly from the Excel spreadsheet.
To generate device tree files for your pinmux configuration
1. In the spreadsheet, click Generate DT.
2. Answer “yes” to the prompt that asks whether you wish to generate the DT files.
3. Provide the name of your board when prompted.
The device tree files are saved in the same location as the Excel spreadsheet. After the
file is generated, make sure that the file name matches the one you use in your kernel
code. Correct the file name if there is a mismatch. Later, you will copy the device tree
files into the Linux kernel source tree.
Porting U-Boot
Perform the following actions in the U-Boot source code to add support for your board.
1. Copy include/configs/ p3450-porg.h to include/configs/<board>.h.
2. Edit the set of enabled devices and features in <board>.h as appropriate for your
board. For example, you must change the following:
#define CONFIG_TEGRA_BOARD_STRING "NVIDIA P3450-Porg"
3. Copy arch/arm/dts/tegra210-p3450-porg.dts to
arch/arm/dts/tegra210-<board>.dts.
4. Edit the set of enabled devices and their parameters (e.g. GPIO and IRQ IDs) in
tegra210-<board>.dts as appropriate for your board.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 7
You may have to add, remove, or edit nodes and properties.
Note:U-Boot and the Linux kernel do not always use exactly the same device
tree schema (bindings) to represent the same data. Follow examples from
U-Boot rather than from the Linux kernel.
5. Add tegra210-<board>.dtb to arch/arm/dts/Makefile.
6. Copy configs/p3450-porg_defconfig to configs/<board>_defconfig.
7. Edit <board>_defconfig to refer to your board name.
8. Edit arch/arm/mach-tegra/tegra210/Kconfig to add target config and
Kconfig.
9. Copy the board/nvidia/p3450-porg/directory to
board/<vendor>/<board>/.
10. Edit all of the files in board/<vendor>/<board>/ to refer to your board name
rather than to P3450-Porg. The files in this directory contain many instances of the
P3450-Porg board name.
11. Edit board/<vendor>/<board>/MAINTAINERS to provide the correct maintainer
contact information for your board.
12. Edit board/<vendor>/<board>/<board>.c to provide the correct PMIC
programming for your board, if required.
13. Copy the pinmux header you generated (pinmux-config-<board>.h) to the
board/<vendor>/<board>/ directory.
Porting the Linux Kernel
If you replace the standard P3449 carrier board with your own board, or you
enable/disable any feature from the P3449 device tree, you must review the .dts file in
hardware/nvidia/platform/t210/porg.
1. To see the complete device tree node, run these commands to convert the final
provided .dtb file:
dtc -I dtb -O dts tegra210-porg-p3448-0000-a00.dtb > ~/tegra210-
porg-p3448-0000-a00.dts
dtc -I dts -O dtb ~/tegra210-porg-p3448-0000-a00.dts > tegra210-
porg-p3448-0000-a00.dtb
You can then make any necessary changes to the nodes defined in the folder and
regenerate the DTB. You can also add your board specific DTSI file and include it in
the main .dts file.
If you are replacing the P3449 with your own carrier board, look out for "P3449"
strings in the DTB and make sure you understand them and replace them according
on your needs.
2. Copy the generated DTB to the following directory for flashing:

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 8
Linux_for_Tegra/kernel/dtb/
To provide plugin manager support, the kernel DTB is not included in the file
system along with the kernel image in the boot directory. Instead, the kernel DTB is
selected from the DTB partition and modified by CBoot. CBoot passes it on to
U-Boot, which in turn passes it to the kernel without changing any of the data.
●To flash the Linux kernel DTB, copy the image to the
Linux_for_Tegra/kernel folder, then execute this command:
sudo ./flash.sh -k DTB <config> mmcblk0p1
Where <config> is the basename of the flash configuration file:
•jetson-nano-sd for a SKU 0000 device
•jetson-nano-qspi for a SKU 0020 device
Optionally, you can perform a secure copy to copy the kernel image to the boot
partition of the target system and reboot. To update the kernel DTB, though, you
must flash again.
3. Copy Linux_for_Tegra/jetson-nano.conf to
Linux_for_Tegra/<config>.conf.
4. Edit SYSBOOTFILE in <config>.conf to refer to your board.
For the detailed information about .dts files, refer to the documentation at
Documentation/devicetree/bindings in the NVIDIA released Linux kernel
source package.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 9
Porting USB
Jetson Nano can support up to three SuperSpeed USB ports. In some implementations
not all of these ports can be used because of UPHY lane sharing among PCIE and XUSB.
The Jetson P3449 carrier board is designed and verified for one USB 3.0 port. If you
design your own carrier board, consult Jetson Nano Product Design Guide to verify that
your board’s UPHY lane mapping is functionally compatible with that of P3449.
USB Structure
A SuperSpeed USB port has nine pins:
•VBUS
•GND
•D+/D−
•SSTX+/SSTX− (SuperSpeed data transmit)
•SSRX+/SSRX− (SuperSpeed data receive)
•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 and XUSB, UPHY lanes must be assigned according to the custom carrier board’s
requirements.
UPHY Lane Assignment
Universal Physical Layer (UPHY) is a physical I/O interface layer that can serve multiple
types of interfaces, e.g. USB and PCIe. A single UPHY lane can support multiple types of
interfaces.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 10
The Jetson P3449 carrier board is designed and verified for one USB 3.0 port. The
verified use cases and their UPHY lane assignments are shown in Table 1 and Table 2.
Table 1. Available outputs for the P3449 carrier board
Output
Type Number of Outputs
USB 3.0 1
PCIe 1 x4
Table 2. UPHY lane assignment use cases
Lane Pin Names Functions
0 N/A PCIe x1
C1
1 PEX_TX1
PEX_RX1
PCIe x4
C0
(L3/L2/L1/L0)
2 PEX_TX2
PEX_RX2
3 PEX_TX3
PEX_RX3
4 PEX_TX4
PEX_RX4
5 N/A N/A
6 PEX_TX6
PEX_RX6 USB3.0 P0
Jetson Nano and the supporting software are designed to support the configurations in
these tables. See Tegra X1 (SoC) Technical Reference Manual (TRM) and consult Jetson
Nano Product Design Guide for further information before you design your custom
board. (Note that Tegra X1 Technical Reference Manual applies to Jetson Nano as well as
Jetson TX1.)
Lane assignment can be defined by the PCIe subnode under xusb_padctl in the
corresponding device tree file. The device tree’s xusb_padctl node follows the
conventions of the document:
kernel/kernel-4.9/Documentation/devicetree/bindings/pinctrl/pinctrl-
bindings.txt
The PCIe subnode lists the functions assigned to UPHY lanes.
•nvidia,function

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 11
A string containing the name of the function to mux to the pin or group. It must be
one of these values:
●xusb
●pcie-x1
●pcie-x4
Take Table 2, for example. Create a PCIe subnode and property under xusb_padctl
based on the device tree structure described above:
xusb_padctl@7009f000 {
...
pcie {
status = "okay"
lanes {
pcie-0 {
status = "okay"
nvidia,function = "pcie-x1";
};
pcie-1 {
status = "okay"
nvidia,function = "pcie-x4";
};
pcie-2 {
status = "okay"
nvidia,function = "pcie-x4";
};
pcie-3 {
status = "okay"
nvidia,function = "pcie-x4";
};
pcie-4 {
status = "okay"
nvidia,function = "pcie-x4";
};
pcie-5 {
status = "okay"
nvidia,function = "xusb";
};
pcie-6 {
status = "okay"
nvidia,function = "xusb";
};
};
...
};
Note:UPHY lane 0 and UPHY lane 5 are not exposed, and can only be assigned to the
pcie-x1 and xusb functions.

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 12
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 Nano
P3449 carrier board.
For a Host-Only Port
This section uses U27, a USB 3.0 Realtek SuperSpeed on-board hub, as an example of a
host-only port.
Go Through the Schematics
Note:The P3449 carrier board’s schematic file,
P3449_B01_Concept_schematics.pdf, is included in Jetson Nano
Developer Kit Carrier Board Design Files. Consult your NVIDIA representative
for further information.
Check the USB 3.0 Realtek SuperSpeed hub on the P3449 carrier board and find the pin
names of the wired socket to the P3448.
•USB 2.0 signal pins D+/D- (USB_DP/USB_DM) wire out from U27 and lead to CVM
socket pins 115 (USB1_DN) and 116 (USB1_DP).
•USB 3.0 differential signal pairs (USP_SSTX* and USP_SSRX*) wire out from U27
and lead to CVM socket pins 161 (SBSS_RX_N), 163 (USBSS_RX_P), 166
(USBSS_TX_N), and 168 (USBSS_TX_P).

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 13
Through the schematic, you can conclude that for U27:
•The USB 2.0 signal pair is wired to UTMI pad 1 (USB2 port 1).
•The USB 3.0 signal pairs are wired to UPHY lane 6 (USB 3.0 port 0 according to
UPHY lane mapping).
The xusb_padctl Node
The device tree’s xusb_padctl node follows the conventions of pinctrl-
bindings.txt. It contains two groups of 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 pads Subnode
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 ports Subnode
•mode
A string that describes USB port capability. A port for USB2 must have this property.
It must be one of these values:

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 14
●host
●device
●otg
•nvidia,usb2-companion
The 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 U27, the Realtek SuperSpeed hub on
the P3499 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 SuperSpeed hub is always connected to the root hub port on a
P3449, You need not control hub power, just enable it with VDD_HUB_3V3.
Therefore, you must set dummy regulators for U27 on the P3449 carrier
board.
For the detailed information about xusb_padctl, refer to the documentation at:
kernel/kernel-
4.9/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-
padctl.txt
As an example consider U27, the Realtek SuperSpeed hub, which is always connected to
USB2 port 1 and USB3 port 0 on the root hub. Create a pad/port node and property list
for U27 based on the device tree structure described above:
xusb_padctl: xusb_padctl@7009f000 {
...
pads {
usb2 {
status = "okay";
lanes {
...
usb2-1 {
nvidia,function = "xusb";
status = "okay";
};
...
};
};

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 15
pcie {
status = "okay";
lanes { ...//UPHY lane assignment
};
};
};
ports {
usb2-1 {
mode = "host";
vbus-supply = <&battery_reg>;
status = "okay";
};
...
usb3-0 {
nvidia,usb2-companion = <1>;
status = "okay";
};
...
};
};
Under the xusb Node
The Jetson Nano xHCI controller complies with xHCI specifications, which support both
USB 2.0 HighSpeed/FullSpeed/LowSpeed and USB 3.0 SuperSpeed protocols.
•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 of the
form <type>-<port_number>, where <type> is "usb2" or "usb3".
•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 through PMQOS is enabled for the xHCI controller
only when this field’s 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 the bulk or ISOC transfers beyond which to boost
frequency.
•nvidia,xusb-padctl
A pointer to the xusb-padctl node.
For the detailed information about xHCI, see the documentation at:

Platform Adaptation and Bring-Up
Jetson Nano Platform Adaptation and Bring-Up Guide DA_09361-002 | 16
kernel/kernel-
4.9/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-xusb.txt
Consider U27, the Realtek SuperSpeed hub, as an example. Create an xHCI node and
property list for U27 based on the device tree structure described above:
xusb@70090000 {
...
phys = <&{/xusb_padctl@7009f000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@7009f000/pads/pcie/lanes/pcie-6}>;
phy-names = "usb2-1", "usb3-0";
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 on the same port. A USB OTG port can switch back and
forth between the roles of host and device.
This section uses J28, a USB 2.0 Micro B connector, as an example of an OTG port.
An OTG port adds a fifth pin, called the ID pin, to the standard USB connector. An OTG
cable has a USB Type A plug on one end and a Type B plug on the other end. The
Type A plug’s ID pin is grounded, while the Type B plug’s ID pin is floating. A device
with a Type A plug inserted becomes and OTG A-device (host), and a device with a
Type B plug inserted becomes a B-device (device).
Figure 1. An OTG port connector
Note:Because its ID pin is floating, J28 is fixed in the device role in the Jetson Nano
Developer Kit. It cannot function as a host, e.g. to connect a flash drive,
keyboard, or mouse.