Jetson Module Adaptation and Bring-Up: Jetson Xavier NX Series ¶
This topic is for engineers who are developing production software for an NVIDIA ® Jetson Xavier™ NX series module. It describes how to port NVIDIA ® Jetson™ Linux and Bootloader from a Jetson Xavier NX Developer Kit to a custom hardware platform and bring up a working system on the new platform.
The examples described include code for the Jetson Xavier NX Developer Kit (P3518).
For information on customizing the configuration files, see the section MB1 Platform Configuration .
Two other topics are closely related to this one:
-
Jetson Module Adaptation and Bring-Up: Checklists contains lists of steps to perform to complete the parts of the adaptation task.
Board Configuration ¶
Jetson Xavier NX series has three variants:
-
Jetson Xavier NX (development, P3668-0000), with 8 GB of RAM and an on-module microSD card socket. Is intended only for software development, and is sold only as a component of Jetson Xavier NX Developer Kit. You can program it by flashing a microSD card in place, or by flashing it on a host computer and then installing it on the module.
-
Jetson Xavier NX (production, P3668-0001), with 8 GB of RAM but no microSD card socket. This module is sold as a separate unit. It is intended for production use but may also be used in a Jetson Xavier NX Developer Kit. You program it in the conventional way, by flashing software to on-board eMMC memory.
-
Jetson Xavier NX 16GB (P3668-0003), with 16 GB of RAM. This variant is identical to P3668-0001 in all respects except RAM size.
Jetson Xavier NX Developer Kit, P3518, includes a P3509-0000 reference carrier board as well as the P3668-0000 SOM. 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.
Jetson Xavier NX series modules have a provision for attaching a heatsink or fansink. The module provided with a Jetson Xavier NX Developer Kit has a fansink already attached. See the Jetson Xavier NX Thermal Design Guide for guidance on designing or procuring a thermal solution for production Jetson Xavier NX series modules.
Before using the SOM with a carrier board other than P3509, you must 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 series module. The Jetson Linux 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 series 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 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 file system.
The placeholder
is used to represent the board name throughout
this topic. Where a command contains
,
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 File System Configuration ¶
Jetson Linux can use any standard or customized Linux root file system (rootfs) that is appropriate for its 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:
-
The
nv.sh
andnvfb.sh
boot-up scripts do some platform-specific configuration in the kernel. -
The Xorg and X libraries must be correctly configured for the target device.
-
The nvpmodel clock and frequency must be configured for the target device.
Jetson Linux provides these rootfs configurations and customizations in this 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 file system 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:
/bootloader/t186ref/BCT
Where
is the top-level BSP flashing directory.
Pinmux Changes ¶
If your carrier board schematic differs from that of the reference carrier board in Jetson Xavier NX Developer Kit, 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 pinmux table is a spreadsheet that:
-
Shows the locations and default pinmux settings
-
Acts as a data source for software that defines the pinmux settings in the source code or device tree
You must customize the spreadsheet for the configuration of your board, then convert the
.dtsi
file generated by Excel to a
.cfg
file. 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.
To check a GPIO number ¶
This example procedure checks the GPIO number of signal name
SPI0_CS1
.
-
Open the Jetson Xavier NX pinmux table. (See Pinmux Changes , above.)
-
Search the table for
SPI0_CS1
. -
Confirm that the Customer Usage field contains the GPIO name
GPIO3_PZ.07
. -
Search PZ.07 using the following command:
cat /sys/kernel/debug/gpio | grep PZ.07
-
For example Output:
gpio-xxx (PZ.07 )
-
GPIO number of
SPI0_CS1
is xxx.
PMIC Changes ¶
The PMIC configuration file configures the initial PMIC in the P3668 SOM. 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 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 an unmodified P3509
carrier board; the QSPI, PMIC, DDR, and routing of lines are all unchanged.
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:
/hardware/nvidia/platform/t19x/
/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. The following table describes common
.dtsi
files that may be modified to reflect hardware design changes.
Types of Changes |
DTSI Filename or location |
---|---|
Power supply changes |
|
Regulator parameter changes |
|
Display panel and node changes |
For details, see the topic Display Configuration and Bringup . |
ODM data based feature configuration |
|
NVIDIA SoC controller state to enable/disable a controller |
|
Panels related .dts files |
|
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
file from the final
.dtb
file and check whether 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 PCIe host controller is based on Synopsis Designware PCIe intellectual property, and thus inherits all the common properties defined in the information file at:
$(KERNEL_TOP)/nvidia/Documentation/devicetree/bindings/pci/nvidia,tegra19x-pcie.txt
PCIe Controller Features ¶
Jetson Xavier NX series has two PCIe controllers with these specifications:
-
Lane width and speed :
-
C5 : x4 and Gen4
-
C4 : x1 and Gen3
-
-
Controllers: Controllers C0, C4 and C5 support dual mode, that is, can be configured as endpoints.
-
ASPM : All controllers support ASPM.
The Jetson Xavier NX PCIe configuration is:
-
C5 : x4
-
C4 : x1
These PCIe slots available on Jetson Xavier NX series:
-
M.2 Key M : C5 controller operates in x4 mode. Any M.2 Key M form factor NVMe cards can be connected.
-
M.2 Key E : C4 controller operates in x1 mode. Any M.2 Key E form factor cards like Wi-Fi can be connected.
For information about Jetson Xavier NX series-specific PCIe controller configuration, see the device tree documentation file at:
$(KERNEL_TOP)/nvidia/Documentation/devicetree/bindings/pci/nvidia,tegra19x-pcie.txt
This file covers topics that include configuring maximum link speed and link width, and advertisement of different ASPM states.
Porting USB (Universal Serial Bus) ¶
The Jetson Xavier NX series 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 , available from the Jetson Download Center.
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_*
andUSP_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 USB3 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
, where
is
"usb2"
or
"usb3"
, and
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 overcurrentVBUS
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
Because 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-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 inphy-names
. -
phy-names
: Must include an entry for each PHY used by the controller. Names must be in the form- "usb2"
or"usb3"
, and -
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 thexusb-padctl
node.
For detailed information about xHCI, see 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
andDN
) 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:
-
Find the corresponding GPIO states on the
VBUS_DETECT
pin and the 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 becauseVBUS
is provided by the host controller. Therefore, the state of theVBUS_DETECT
pin does not matter when the OTG port is operating in host mode. -
Create the table of GPIO states and their corresponding output cable states:
GPIO_Q0 (ID)
GPIO_M3 (VBUS_DETECT)
EXTCON_STATE
1
1
0x0 (
EXTCON_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.
The properties of the
extcon
node are:
-
compatible
: Value must be"extcon-gpio-states"
. -
extcon-gpio,name
: Name of theextcon
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 GPIO states after a GPIO state change is detected and debounce time has elapsed. -
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 intoextcon-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 detailed information about
extcon
, see 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 forGPIO_Q0
andGPIO_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-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 (
|
0 |
0x1 (
|
This is the table of GPIO states and corresponding output cable states for GPIO_PZ1:
GPIO states and corresponding output cable states |
||
---|---|---|
GPIO_PZ1 (ID) |
GPIO_PCC4 (VBUS_DETECT) |
EXTCON_STATE |
1 |
1 |
0x0 (EXTCON_NONE) |
0 |
0 |
0x2 (EXTCON_USB_HOST) |
0 |
1 |
0x2 (EXTCON_USB_HOST) |
1 |
0 |
0x1 (EXTCON_USB) |
This is the
extcon
device node and property list based on the device tree structure and GPIO states described above:
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 = ;
wakeup-source;
#extcon-cells = <1>;
};
};
Note
Check the pinmux spreadsheet for the GPIO that corresponds to the ID pin and
VBUS_DETECT
pin.
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 theextcon-cable
entry for the USB ID pin. When theextcon
cable state is 0, the OTG port transitions to host mode. -
extcon-cable-names
: Must be"id"
. -
#extcon-cells
: Number of cells in theextcon
specifier. Must be 1.
Taking the USB 2.0 Micro B connector, J51, 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 anextcon-cable
entry which detects the USBVBUS
pin. When theextcon
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 thephandle
of the USB charger detection driver DT node. -
phys
: An array; must contain pointers to the nodes that define each PHY inphy-names
. -
phy-names
: An array; must contain an entry for each PHY used by the controller. Names must be in the form- "usb2"
or"usb3"
, and -
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 thexusb-padctl
node.
For detailed information about xUDC, see the documentation at:
kernel/kernel-4.9/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
Taking the USB 2.0 Micro B connector, J5, 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 you flash the build image, use your specific board name. The
flashing script uses the configuration in the
file during
the flashing process.
Setting Optional Environment Variables ¶
flash.sh
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
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:
# :::
# 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 of the parameters must be added below the reference to the file
p3668.conf.common
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 ¶
-
Enter the command:
$ sudo ./flash.sh
mmcblk0p1