Jetson TX2 NX Adaptation and Bring-Up

This topic describes how to port NVIDIA® Jetson™ Linux (L4T) from an NVIDIA® Jetson™ TX2 NX module running on a Jetson Xavier NX Developer Kit to a Jetson TX2 NX module on another hardware platform.
Note:
Jetson TX2 NX does not have a dedicated developer kit. It is used with the carrier board from a Jetson Xavier NX Developer Kit for software development.
The examples described include code for NVIDIA® Jetson Xavier™ NX Developer Kit (P3518).
For information on customizing the configuration files, see the topic Jetson TX2 Series MB1 Platform Configuration.

Board Configuration

Remove the original Jetson Xavier NX module (P3668-0000) from a Jetson Xavier NX Developer Kit’s carrier board (P3509-0000) and replace it with a Jetson TX2 NX module (P3636-0010). The module and carrier board each have an EEPROM where the board ID is saved. The Jetson module (a system on module, or SOM) can be used without any software configuration modifications.
The Jetson TX2 NX module has a provision for attaching a heatsink or fansink. When you attach it to the carrier board of your Jetson Xavier NX Developer Kit, transfer the Jetson Xavier NX module’s fansink to the Jetson TX2 NX module to provide the necessary cooling. See the Jetson TX2 NX Thermal Design Guide for guidance when designing or procuring a thermal solution for Jetson TX2 NX modules used in production.
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.

Board Naming

To support a Jetson TX2 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 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 development 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 Jetson Linux 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 the Jetson Xavier NX Developer Kit board, you must change the pinmux configuration applied by the software.
To define your board’s pinmux configuration, you must customize the Jetson TX2 NX pinmux table. You can download this table as a spreadsheet from the Jetson Download Center.
The spreadsheet shows the locations and default pinmux settings, and defines the pinmux settings in the source code or device tree.
To customize the pinmux spreadsheet
1. Create a copy of the spreadsheet file with a name based on your board name, e.g. <board>_pinmux.xlsm. Note the directory in which you stored the copy; you will need it in the procedure Updating the Bootloader Pinmux.
2. Ensure that the new file is writable.
3. On a Windows PC, open the new file in Microsoft Excel.
4. If Excel displays warnings such as “PROTECTED VIEW” or “SECURITY WARNING,” click the Enable Editing or Enable Content button to enable you to save your changes to the file.
5. Modify the spreadsheet columns grouped under the heading “Filled in by Customers” as required by the pinmux configuration for your board, based on the board’s schematic.
6. Once the spreadsheet reflects the configuration you want, click the Generate DT File button. This runs a macro that exports the configuration data to a set of .dtsi files in the directory where the spreadsheet is stored. The macro prompts you to enter a prefix for the files’ names; enter jetson-tx2-NX-default (the default).
To configure the pinmux setting of i2c-4 and i2c-6
You must make three changes to the device tree to configure the pinmux settings of i2c‑4 (dpaux1) and i2c‑6 (dpaux0):
In the i2c controller node, set pinctrl-0 to point to dpaux-default, and pinctrl-names to "default":
i2c@31b0000 {
pinctrl-names = "default";
pinctrl-0 = <&dpaux_default>;
};
Define the dpaux controller node like this:
host1x {
dpaux@<nodename> {
status = "okay";
compatible = "nvidia,tegra186-dpaux-padctl";
dpaux_default: pinmux@0 {
dpaux_pins {
pins = "dpaux-<port>";
function = "i2c";
};
};
/delete-property/ power-domains;
};
};
Where:
<nodename> is 155c0000 for dpaux0, or 15040000 for dpaux1.
<port> is "0" for depaux0. or "1" for dpaux1.
For more information about this setting, see <TOP>/kernel/nvidia/Documentation/devicetree/bindings/pinctrl/nvidia,tegra186-dpaux-pinctrl.txt.
Updating the Bootloader Pinmux
The Jetson TX2 NX Bootloader uses a .cfg file generated from the device tree files that you created in step 6 of To customize the pinmux spreadsheet.
The pinmux settings are only applied by the Bootloader; they are not reapplied by the Linux kernel.
To update the Bootloader pinmux
1. Enter this command:
$ cd Linux_for_Tegra/kernel/pinmux/t186/
$
2. Review README.txt for information about how the script python pinmux-dts2cfg.py works.
3. Enter this command:
$ python pinmux-dts2cfg.py --pinmux addr_info.txt gpio_addr_info.txt \
por_val.txt --mandatory_pinmux_file mandatory_pinmux.txt \
tegra18x-jetson-tx2-nx-default-gpio-default.dtsi \
tegra18x-jetson-tx2-nx-default-padvoltage-default.dtsi 1.0 \
tegra18x-jetson-tx2-nx-default-pinmux.dtsi 1.0 \
If you specified a prefix other than the one recommended in step 6 of To customize the pinmux spreadsheet, substitute that prefix for jetson-tx2-nx-default in the .dtsi files’ names.
These commands convert the .dtsi files generated in To customize the pinmux spreadsheet to a .cfg file and store it in the L4T release package at Linux_for_Tegra/kernel/pinmux/t186/.
4. To reflash the target device and apply the new pinmux configuration, follow the instructions in the section Basic Flashing Procedures of the topic Flashing and Booting the Target Device.

GPIO Changes

If you designed your own carrier board you must translate from SOM-connector pins to actual GPIO numbers, and to do this 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 UFS0_REF_CLK:
1. Search for UFS0_REF_CLK in Jetson TX2 NX pinmux spreadsheet.
2. Confirm that the Customer Usage field is applied to GPIO3_PBB.00.
3. Refer to tegra186-gpio.h to determine the GPIO group that the GPIO belongs to and the index of the GPIO in the group. For example, GPIO3_PBB.00 belongs to the main Jetson GPIO group, and its port number is 21:
#define TEGRA_MAIN_GPIO_PORT_BB 21
4. Because the SoC device registers GPIOs dynamically, you must search kernel messages to find the base index of each GPIO group. 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 the GPIO groups and their base indices are:
tegra-gpio, at base index 320
tegra-gpio-aon, at base index 256
5. Because PBB00 belongs to the tegra-gpio group, its base index is 320. Use the following formula to calculate the GPIO number:
The GPIO number of UFS0_REF_CLK is therefore 320 + (8 * 21) + 0 = 488.

PMIC Changes

The PMIC configuration file configures the initial PMIC in the P3636 module. It also defines some GPIO expander-based GPIO regulator settings in the P3509 carrier board configurations. Review this configuration file to replace any references to the P3509 carrier board to your custom board. If necessary, include any regulator information to enable this file.
For example, remove the following section, which writes to a slave on the I2C controller 0 address 0x74 in the P3509 carrier board. Additionally, update the number of blocks and array number for other entries of the block in /pmic/tegra186-mb1-bct-pmic-p3636-0001-a00.cfg.

Porting the Linux Kernel

This section assumes that you are using an unmodified P3636 SOM; the eMMC, PMIC, and DDR are the same, with the same routing of lines. Thus the modifications you make to the device tree are only for the carrier board that hosts the peripherals. Consequently, based on the peripherals present on your carrier board, you can modify the .dts files to disable and enable 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 these locations:
<top>/hardware/nvidia/platform/t18x/
<top>/hardware/nvidia/soc/t18x/
The final DTB file used is:
tegra186-p3636-0001-p3509-0000-a01.dtb
You can read this file to 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
tegra186-p3636-0001-a00-power-tree.dtsi
Regulator parameter changes
tegra186-p3636-0001-a00-spmic.dtsi
Display panel and node changes
For details, see the section Display Configuration and Bringup in the topic Kernel Configuration.
ODM data based feature configuration
tegra186-p3636-0001-odm-data-plugin-manager.dtsi
NVIDIA SoC controller state to enable/disable a controller
soc/t18x/kernel-dts/tegra186-soc/
Panels related .dts files
tegra/common/kernel-dts/panels/
Verify that no .dts or .dtsi files, including these .dts files, override any changes you make.
As a best practice, create your own set of .dts files based on the Jetson TX2 NX files already present. Give your newly created files filenames that incorporate the name of your carrier board.
Note
Use fdtdump or dtc to generate a .dts from the final .dtb file and verify that your changes have taken effect.
The command usage is:
$ dtc -I dtb -O dts tegra186-p3636-0001-p3509-0000-a01.dtb
> tegra186-p3636-0001-p3509-0000-a01.dts
$ fdtdump dts tegra186-p3636-0001-p3509-0000-a01.dtb \
> tegra186-p3636-0001-p3509-0000-a01.dts

Porting USB (Universal Serial Bus)

Jetson TX2 NX supports one SuperSpeed USB port. The Jetson Xavier NX Developer Kit has a built-in hub which supports up to four SuperSpeed USB devices.
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 UPHY lane mapping and compatibility between P3509 and your custom board by consulting the NVIDIA team.

USB Structure

An enhanced SuperSpeed USB port has nine pins, as shown in the diagram below:
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
Diagram Description automatically generated with medium confidence
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.

UPHY Lane Assignment

UPHY is an acronym for universal physical layer, a physical I/O interface layer that can serve multiple types of interfaces, e.g. USB, PCIe, SATA, and UFS. A UPHY lane can support multiple types of interfaces, shown in the following table.
Config
Jetson TX2 Pin Names
PEX1/
USB_SS0
PEX_RFU
PEX2
USB_SS1
PEX0
SATA
Jetson TX2 Lanes
Lane 0
Lane 1
Lane 3
Lane 2
Lane 4
Lane 5
Available Outputs from Jetson TX2 NX
 
 
 
 
 
 
USB 3.0
PCIe
SATA
 
 
 
 
 
 
1
1
2x1 + 1x2
1
PCIe#2_0
USB_SS#1
un-used
PCIe#0_1
PCIe#0_0
SATA
Jetson TX2 NX and the released software support the configuration described in the table above. However, the device tree and ODMDATA must be set to support the configuration you want to use. For further information, see the NVIDIA Jetson TX2 Technical Reference Manual (TRM). Consult with NVIDIA before designing your custom board.
Lane assignment can be defined by the uphy node in the configuration file bpmp-dtb, or by ODMDATA, defined in tegra186-bpmp-p3636.dtsi. If both sources define lane assignment, the assignments in ODMDATA take priority.
If your design requires custom UPHY lane assignments, NVIDIA recommends defining them through ODMDATA, because it can set related properties, such as MUX function properties, at the same time. You may prefer to perform lane assignment by modifying bpmp-dtb if you are thoroughly familiar with UPHY and UPHY lane assignment. Consult NVIDIA for further assistance if you are considering this.
bpmp-dtb
The Boot and Power Management Processor (BPMP) is a processor in the Jetson TX2 SOM that handles the boot process and offloads power management, clock management, and reset control tasks from the CPU. UPHY lane assignment is configured in bpmp-dtb under the device node uphy:
/ {
uphy {
lane0-owner = <TEGRA186_UPHY_LANE_PCIE>;
lane1-owner = <TEGRA186_UPHY_LANE_XUSB>;
lane2-owner = <TEGRA186_UPHY_LANE_PCIE>;
lane4-owner = <TEGRA186_UPHY_LANE_PCIE>;
lane5-owner = <TEGRA186_UPHY_LANE_SATA>;
};
};
ODMDATA and the Plugin Manager
ODMDATA and the plugin manager support special properties of various products’ device trees.
While loading the BPMP firmware (BPMP-FW), Bootloader gets ODMDATA, checks the ODMDATA UPHY lane configuration bit, and updates the UPHY lane owners in bpmp-dtb. Later, BPMP-FW configures the UPHY lanes as defined by the updated DTB. This provides flexibility to maintain multiple board configurations during development
Required Device Tree Changes
This section gives step-by-step guidance for checking schematics and configuring USB ports in the device tree. All the examples are based on the design of Jetson TX2 NX’s 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. Check the Realtek hub on the P3509 carrier board and find the socket location wired to the P3636 SOM. (The P3509 carrier board’s schematic file is included in the Jetson Xavier NX Developer Kit Carrier Board Design Package archive.)
USB2 signal pins D+/D- (USP_D_P and USP_D_N) wire out from U7 and lead to module socket pins 117 (USB1_D) and 115 (USB1_D).
Diagram Description automatically generated
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).
Diagram Description automatically generated
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).
Set 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"
<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
vidia,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, see 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-0 {
nvidia,function = "xusb";
status = "okay";
};
...
};
};
};
ports {
usb2-1 {
mode = "host";
vbus-supply = <&vdd_usb0_5v>;
status = "okay";
nvidia,oc-pin = <1>;
};
...
usb3-0 {
nvidia,usb2-companion = <1>;
status = "okay";
};
...
};
};
Set the xHCI node. The Jetson TX2 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"
<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:
xhci@3530000 {
...
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-0}>;
phy-names = "usb2-1", "usb3-0";
nvidia,xusb-padctl = <&xusb_padctl>;
status = "okay";
...
};
For an OTG (On-The-Go) Compatible 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-compatible port. (It does not conform to all parts of the OTG specification.)
This 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).
Diagram, schematic Description automatically generated
Note
Because J5’s ID pin is floating, J5 is fixed in the device role in 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. Check the USB connectors on the P3509 carrier board and find the socket location wired to the P3636 SOM. (The P3509 carrier board’s schematic file is included in Jetson Xavier NX Developer Kit Carrier Board Design Package, available from the Jetson Download Center.)
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.
Diagram Description automatically generated
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).
About 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) 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.
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_PL4. Hence J5 can only function in the device role.
Diagram, schematic Description automatically generated
This table describes the GPIO states on J5 and the corresponding output cable states:
GPIO_PL4 (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_PL4, customized for Jetson TX2 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,wait-for-gpio-scan = <0>;
extcon-gpio,cable-states = <
0x0 0x1
0x1 0x0>;
gpios = <&tegra_main_gpio TEGRA_MAIN_GPIO(L, 4) 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.
Set 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 = <&vdd_usb0_5v>;
status = "okay";
};
...
};
};
Set 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-compatible port transitions to host mode.
extcon-cable-names: Must be "id".
#extcon-cells: Number of cells in the extcon specifier. Must be 1.
Taking J5 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:
xhci@3530000 {
...
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";
...
};
Set the xUDC node. The Jetson TX2 NX xUDC controller supports USB 2.0 High Speed / Full Speed.
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-compatible 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 "usb2" or "usb3"
<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, see 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:
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";
};

Removing the DRAM ECC Partition

Only Jetson TX2i uses ECC DRAM, but the default Jetson Linux flashing partition layout reserves regions for ECC support on all Jetson TX2 series devices. If you want to remove such regions to save secondary storage, perform these steps:
1. Edit bootloader/t186ref/BCT/tegra186-mb1-bct-misc-si-l4t.cfg (the pathname is relative to the flashing directory) and set these two flags:
enable_blacklisting = 0;
disable_staged_scrub = 1;
2. Edit bootloader/t186ref/cfg/flash_l4t_t186.xml (also relative to the flashing directory) and remove these partitions:
DRAMECCNAME
BADPAGENAME
BADPAGENAME_b

Flashing the Build Image

When you flash the build image, use your specific board name. The flashing script uses the configuration in the file <board>.conf during the flashing process.
Setting Optional Environment Variables
The flash.sh script updates the following environment variables based on board EEPROM values and other parameters. If you want to override these environment variables’ default values, set them in <board>.conf:
# 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.
# <C-ipa>:<S-ipa>:<G-ipa>:<netmask>
# NFSROOT ---------------- NFSROOT i.e. <my IP addr>:/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 of the parameters must be added below the reference to the file <xxx>.conf.common to be reflected in the flashed image.
Here is an example of environment variable settings:
source "${LDK_DIR}/p3636-0000.conf.common";
PINMUX_CONFIG=" tegra186-mb1-bct-pinmux-p3636-0001-a00.cfg";
BPFDTB_FILE= tegra186-bpmp-p3636-0001-a00-00.dtb;
DTB_FILE= tegra186-p3636-0001-p3509-0000-a01.dtb;
TBCDTB_FILE= tegra186-p3636-0001-p3509-0000-a01.dtb;
EMMC_BCT="P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02.cfg";
MISC_COLD_BOOT_CONFIG=" tegra186-mb1-bct-memcfg-p3636-0001-a01.cfg";
To flash the build image
Execute the command:
$ sudo ./flash.sh <board> mmcblk0p1