Jetson Orin NX and Nano Series¶
This guide describes how to port and bring up custom platforms using the NVIDIA® Jetson™ Orin™ NX and Nano modules using the NVIDIA Jetson Linux Driver Package.
The examples in this document include code for the Jetson Orin NX and Nano modules connected to the Jetson Orin™ Nano carrier board. Refer to T234 BCT (Boot configuration Table) Deployment Guide for information about customizing the configuration files.
Board Configuration¶
The Jetson Orin Nano Developer Kit consists of a P3767 System on Module (SOM) that is connected to a P3768 carrier board. Part number P3766 designates the complete Jetson Orin Nano Developer Kit. The SOM and carrier board each have an EEPROM where the board ID is saved. The Developer Kit can be used without any software configuration modifications.
Before you use the SOM with a carrier board other than the P3768, you must first change the kernel device tree, the MB1 configuration, the MB2 configuration, the ODM data, and the flashing configuration to correspond to the new carrier board. The next section provides more information about the changes.
Naming the Board¶
To support a SOM with your carrier board, you must assign the module/carrier board combination with a lowercase alphanumeric name. The name can include hyphens (-) and underscores (_) but not spaces. Some examples of valid names are:
p3767-0000-devkitdevboard
The name you select appears in:
Filenames and pathnames
User-visible device tree filenames
This name is also exposed to the user through various Linux kernel proc files.
Note
In this section, <board> represents your board name.
You must also select a similarly constructed vendor name, and the same character set rules apply. Here is an example:
nvidia
In this section, <vendor> represents your vendor name.
Placeholders in the Porting Instructions¶
Placeholders are used throughout this topic, and when executing commands, substitute an appropriate value for each placeholder.
<function>is a functional module name, which might be power-tree, pinmux, sdmmc-drv, keys, comm (Wi-Fi/Bluetooth®), camera, and so on.<board>is the name you selected to represent your platform.For example, p3678 is the name of the carrier board from the Jetson Orin Nano Developer Kit. The NVIDIA <board> names use lower case letters.
<version>is a board version number, such as a00.Files for NVIDIA reference boards include a version number, and files for customer platforms are not required to include a version number.
<vendor>is the name of your organization or the name of the vendor for your board.
Root Filesystem Configuration¶
Jetson Linux can use any standard or customized Linux root filesystem (rootfs) that is appropriate for its targeted embedded applications. However, some settings must be configured in the rootfs’s boot-up framework to set the default configuration after the boot or some of the core functionalities will not run as expected.
For example:
The
nv.shandnvfb.shboot-up scripts complete some platform-specific configurations 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.
In this driver package, these rootfs configurations and customizations are provided in the Linux_for_Tegra/nv_tegra/ directory and its subdirectories.
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 Linux_for_Tegra/apply_binaries.sh script.
MB1 Configuration Changes¶
Starting in version T234, multiple .dts/dtsi files define the boot time configuration of the hardware, and these files are applied by Bootloader. The MB1 boot configuration tables are available at <l4t_top>/bootloader/t186ref/BCT
Refer to T23x Boot Configuration Table for more information about configuring BCT.
Generating the Pinmux dtsi Files¶
To define your board’s pinmux configuration, download the Jetson Orin NX Series and Jetson Orin Nano Series Pinmux table from the Jetson Download Center. The table is a spreadsheet that provides the following information:
The locations and default pinmux settings.
The pinmux settings definitions in the source code or device tree.
To access the spreadsheet:
Search for pinmux and download the spreadsheet for Orin NX and Nano Series.
Before you open the spreadsheet, ensure that macros are enabled.
Ensure the Pin Direction column is consistent with the selected peripheral function.
For example, I2C pins (clock and data) are both bidirectional signals.
The Req Initial State should be consistent with the direction.
For example, the Drive 1 and Drive 0 options are applicable only to the output and bidirectional modes.
The 3.3V Tolerance option is available only for certain pins.
When you enable this option, that pin will function as open-drain.
Customize the spreadsheet to configure your board and click Generate DT File to generate the following files:
Note
The names of the generated files depend on the input you provided during Generate DT File.
pinmux.dtsi
gpio.dtsi
padvoltage.dtsi
Note
Copy the padvoltage.dtsi and pinmux.dtsi files to the
<l4t_top>/bootloader/t186ref/BCT/directory and copy thegpio.dtsifile to the<l4t_top>/bootloader/directory.
After copying the files, ensure that you point these files to the new board.conf file that you created for your board. Refer to Flashing the Build Image for more information.
Changing the Pinmux¶
Starting with the JetPack 5.0.2 GA release, you can change the pinmux in one of the following ways:
Update the MB1 pinmux BCT as mentioned in Generating the Pinmux dtsi Files.
For debugging, you can dynamically change the pinmux.
To dynamically change the pinmux:
Get the pinmux register address.
In TRM, click System Components → Multi-Purpose I/O Pins and Pin Multiplexing (PinMux) → Pinmux Registers.
Search for the pin name (for example, SOC_GPIO37).
Write down the complete pin name.
For example, PADCTL_G3_SOC_GPIO37_0 and the Offset (for example, SOC_GPIO37: Offset = 0x80).
Go to the Jetson Orin Technical Reference Manual at https://developer.nvidia.com/orin-series-soc-technical-reference-manual, and in Table 1-15: Pad Control Grouping, find the G3 pad control block = PADCTL_A0 entry.
On the Memory Architecture page, click Memory Mapped I/O → Address Map.
Search for PADCTL_A0.
The base address is PADCTL_A0 = 0x02430000, and the pinmux register address is PADCTL base address + offset.
For example, SOC_GPIO37 Pinmux register address = 0x02430000 + 0x80 = 0x02430080.
Get the current register value in the device using the devmem tool.
Install devmem.
$ sudo apt-get install busybox $ busybox devmem <32-bit address>
For example, busybox devmem 0x02430080.
To use the pin as GPIO, update the following fields in the PADCTL register:
Find the register information from the Pinmux Registers section in TRM as mentioned in step 2.
Set GPIO to Bit 10 = 0.
For the output, set Bit 4 = 0 ; Bit 6 = 0.
For Input, set Bit 4 = 1 ; Bit 6 = 1.
Use the devmem tool to set the register, for example, busybox devmem 0x02430080 w 0x050.
Verify that the register value is set accordingly.
An Example
To update Pin MCLK05: SOC_GPIO33: PQ6:
Adjust the pinmux to map the pin to GPIO.
Configure the GPIO controller (input, output high, or output low).
To configure the pinmux for this pin:
The Pinmux register base address is 0x2430000.
The Offset is 0x70.
The Pinmux register address is 0x2430070.
Run the following command.
$ busybox devmem 0x02430070The output value is 0x00000054.
To set the pin as the output, run the following command.
$ busybox devmem 0x02430070 w 0x004To confirm, check the output.
$ busybox devmem 0x02430070
After the pinmux register has been configured, configure the GPIO configuration by using sysfs. The following commands show an example of configuring this pin as an output:
Identify the GPIO number by completing the steps in Identifying the GPIO Number.
$ echo 454 > /sys/class/gpio/export
$ cd /sys/class/gpio/PQ.06
$ echo out > direction
$ cat value
# change value and check
Enabling the VPR Carveout¶
By default, the Video Protect Region (VPR) carveout has been disabled on Jetson Orin NX and Nano modules.
It is disabled in the Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb1-bct-misc-p3767-0000.dts file,
which sets the carveout size and alignment to zero and overrides the value from the
Linux_for_Tegra/bootloader/tegra234-mb1-bct-carveout-l4t.dtsi file.
aux_info@CARVEOUT_VPR { pref_base = <0x0 0x0>; size = <0x0 0x0>; // 0MB alignment = <0x0 0x0>; // 0MB };
This code block can be deleted, and the VPR carveout will use the default T234 values. If you want a specific VPR carveout size, the value can be customized.
Identifying the GPIO Number¶
If you designed your own carrier board, to translate from the SOM connector pins to actual GPIO numbers, you must understand the following GPIO mapping formula. The translated GPIO numbers can be controlled by the driver.
The Jetson module dynamically registers GPIOs, so search the kernel messages to check the GPIO allocation ranges for each GPIO group. The command and resulting output are similar to the following output:
root@jetson:/home/ubuntu# dmesg | grep gpiochip
[ 5.726492] gpiochip0: registered GPIOs 348 to 511 on tegra234-gpio
[ 5.732478] gpiochip1: registered GPIOs 316 to 347 on tegra234-gpio-aon
root@jetson:/home/ubuntu#
In the output, there are two Jetson GPIO ports with different base indices:
tegra234-gpio, at base index 348
tegra234-gpio-aon, at base index 316
You can check the GPIO number in one of the following ways:
Using a calculation.
Before you get started, determine how you plan to configure the offset at each available port.
Here is the list of the tegra234 GPIO ports and offset mapping:
Port
Number of Pins
Port Offset
PORT_A
8
0
PORT_B
1
8
PORT_C
8
9
PORT_D
4
17
PORT_E
8
21
PORT_F
6
29
PORT_G
8
35
PORT_H
8
43
PORT_I
7
51
PORT_J
6
58
PORT_K
8
64
PORT_L
4
72
PORT_M
8
76
PORT_N
8
84
PORT_P
8
92
PORT_Q
8
100
PORT_R
6
108
PORT_X
8
114
PORT_Y
8
122
PORT_Z
8
130
PORT_AC
8
138
PORT_AD
4
146
PORT_AE
2
150
PORT_AF
4
152
PORT_AG
8
156
PORT_AA
8
0
PORT_BB
4
8
PORT_CC
8
12
PORT_DD
3
20
PORT_EE
8
23
PORT_GG
1
31
Search for the pin details from the Jetson Orin NX Series and Jetson Orin Nano Series Pinmux table (refer to Generating the Pinmux dtsi Files).
For example SOC_GPIO08 is GPIO3_PB.00.
Identify the port as B and the Pin_offset as 0.
Calculate the pin number with the following formula:
base + port_offset + pin_offsetVerify the following values:
The base is 348.
This value comes from the kernel boot log, it is already noted
tegra234-gpio, at base index 348.port_offsetof port B = 8This value comes from the tegra234 GPIO port and the offset mapping above.
pin_offset = 0
Pin number = 348 + 8 + 0 = 356
Using Kernel debugfs.
Search for the GPIO pin in the Jetson Orin NX Series and Jetson Orin Nano Series Pinmux table (refer to Generating the Pinmux dtsi Files).
For example, SOC_GPIO08, which is GPIO3_PB.00.
Follow the gpio debugfs look up that use the port and offset.
cat /sys/kernel/debug/gpio | grep PB.00The GPIO number is mentioned in the first column as gpio-356.
root@jetson:/home/ubuntu# cat /sys/kernel/debug/gpio | grep PB.00gpio-356 (PB.00
Note
To use a pin as the GPIO, ensure that the E_IO_HV field is disabled in the corresponding pinmux register of the GPIO pin. You can disable the 3.3V Tolerance Enable field in the pinmux spreadsheet and reflash the board with the updated pinmux file.
Changing the GPIO Pins¶
If the pin meets the following conditions, users can dynamically change the pin settings by using the GPIO tools:
The pin is part of the 40-pin header.
To confirm whether the pin is one of the 40-pin headers, check the Jetson Orin NX Series and Jetson Orin Nano Series Pinmux spreadsheet.
The pin is not configured by the MB1 BCT as an SFIO pin.
Starting with the JetPack 5.0.2 GA release, users will be able to use the Jetson-IO tool with the Jetson GPIO tool to dynamically set the pin without reflashing the board. The Jetson-IO tool will generate the DTBO and reboot the system. When the system boots, the new DTBO will be applied. Refer to https://github.com/NVIDIA/jetson-gpio and Configuring The Jetson Expansion Headers for more information.
EEPROM Modifications¶
EEPROM is an optional component for a customized carrier board. If the carrier board is designed without an EEPROM, the following modifications will be needed on the MB2 BCT file:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb2-bct-misc-p3767-0000.dts
- cvb_eeprom_read_size = <0x100>
+ cvb_eeprom_read_size = <0x0>
Porting the Linux Kernel Device Tree Files¶
This section assumes the P3767 SOM is connected to a P3768 carrier board, and the board has not been modified. Based on the peripherals on your carrier board, you can modify the .dts files by disabling/enabling the controllers and changing the power supplies. This section provides details and suggestions for the porting exercise.
To port the kernel configuration code, or the device tree to your platform, modify one of the distributed configuration files to describe the design of your platform:
The configuration files can be downloaded and are available in the following directories:
<top>/hardware/nvidia/platform/t23x/<top>/hardware/nvidia/soc/t23x
The final DTB file that is used is generated from the tegra234-p3767-0003-p3768-0000-a0.dts source device tree (DT) file:
tegra234-p3767-0003-p3768-0000-a0.dtb
By reading the source DT file, you see the other .dtsi files that are referenced by the include statements, specifically the cvb/tegra234-p3768-0000-a0.dtsi file, and the display node includes the tegra234-dcb-p3767-0000-dp.dtsi file. Refer to Display Configuration and Bring-up for more information about the display panel and node. The cvb/tegra234-p3768-0000-a0.dtsi file represents the carrier board, P3768 in this case, specific hardware design changes, and can serve as a guide for end users to implement dts and dtsi files based on their custom carrier boards.
As a general practice, users can take the existing P3768 and start modifying with the cvb/tegra234-p3768-0000-a0.dtsi file as a starting point. The following table provides a list of the notable DT files that are affected during the customization process.
Types of Changes |
DTSI Filename or Location |
|---|---|
Power supply changes |
|
Audio |
|
ODM data based feature configuration |
|
USB |
|
NVIDIA SoC controller state to enable/disable a controller |
|
Note
Use dtc to generate a .dts from the final .dtb file and check whether your changes have taken effect.
The example command usage is:
dtc -I dtb -O dts tegra234-p3767-0003-p3768-0000-a0.dtb > example.dts
Configuring the PCIe Controller¶
The PCIe host controller is based on the Synopsys Designware PCIe intellectual property, so the host inherits the common properties that are defined in the information file at:
$(KERNEL_TOP)/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
This file covers topics that include configuring maximum link speed, link width, and the advertisement of different ASPM states.
PCIe Controller Features¶
Jetson Orin NX/Nano series has the following PCIe controllers with these specifications:
Speed:
Jetson Orin NX supports up to Gen4 speed
Jetson Orin Nano supports up to Gen3 speed.
Lane width:
C4: up to x4
C7: up to x2 (1 lane multiplexed with C9)
C9: x1
C1: x1
Controllers:
Controller C4 supports dual mode (root port or endpoint)
C1, C7, and C9 support root port only
ASPM: All controllers support ASPM.
Enabling PCIe in a Customer Carrier Board Design¶
Select the appropriate UPHY configuration that suits the carrier board design and update ODMDATA accordingly (refer to Configuring the UPHY Lane for more information).
Enable the appropriate PCIe node from the table below.
Ensure that the controller Pins CLK and RST are configured correctly in MB1 Pinmux and gpio dtsi (refer to Generating the Pinmux dtsi Files for more information).
Add the pipe2uphy phandle entries as a phy property in the PCIe controller DT node.
pipe2uphy DT nodes are defined in SoC DT at $(TOP)/hardware/nvidia/soc/t234/kernel-dts/tegra234-soc/tegra234-soc-pcie.dtsi.
Each pipe2uphy node is a 1:1 map to the UPHY lanes that are defined in Configuring the UPHY Lane.
Here are the PCIe controller DT modes:
PCIe Controller and Mode |
PCIe Controller DT Mode |
|---|---|
PCIe C1 RP |
|
PCIe C4 RP |
|
PCIe C4 EP |
|
PCIe C7 RP |
|
PCIe C9 RP |
Porting Universal Serial Bus¶
Jetson Orin NX/Nano can support up to three enhanced SuperSpeed Universal Serial Bus (USB) ports. In some implementations, not all of these ports can be used because of UPHY lane sharing among PCIE, UFS, and XUSB. If you designed your carrier board, verify the Universal physical layer (UPHY) lane mapping and compatibility between P3767 and your custom 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 one UPHY lane. As UPHY lanes are
shared between PPCIE, UFS, and XUSB, the UPHY lanes must be assigned
based on the custom carrier board’s requirements.
Universal Physical Layer Lane Assignment¶
UPHY is a physical I/O interface layer that can serve multiple types of interfaces, for example, USB and PCIe. A UPHY lane can support multiple interface types.
The Jetson P3767 SOM USB ports have the following UPHY lanes:
Jetson SODIMM Signal Name |
Orin UPHY Block and Lane |
Jetson Orin NX/Nano Function |
|---|---|---|
USBSS0_RX/TX |
UPHY0, Lane 0 |
USB 3.2 (P0) |
DP0_TXD0/1 |
UPHY0, Lane 1 |
USB 3.2 (P1) |
DP0_TXD2/3 |
UPHY0, Lane 2 |
USB 3.2 (P2) |
Before you design your custom board, refer to the NVIDIA Jetson Orin Series SOC Technical Reference Manual (TRM), the NVIDIA Jetson Orin NX Series and Orin Nano Product Design Guide (DG), and then contact NVIDIA.
Required Device Tree Changes¶
This section gives step-by-step guidance for checking schematics and configuring USB ports in the device tree. The examples are based on the P3767 SOM and P3678 carrier board.
For a Host-Only Port¶
This section takes a J6 type A stacked connector as an example of a host-only port. The USB signals (USB2.0 and USB3.2) for the J6 are coming from the Port 0 USBSS lines of the SOM through USB HUB as shown in the following image.
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 pads Subnode¶
nvidia,function: A string containing the name of the function to mux to the pin or group. Must bexusb.
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:
hostperipheralOTG
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 overcurrentVBUSpin the port is using.The value must be positive or zero.
Note
Some Type-C port controllers, such as from Cypress can handle the overcurrent detection and handling. Therefore, you do not need to set this property for USB type C connectors that have Type-C port controllers.
vbus-supply:VBUSregulator for the corresponding UTMI pad.Set to
&battery_regfor a dummy regulator.nvidia,usb3-gen1-only: A number (1/0) that describes whether to limit the port speed to USB3.1 gen1.For the detailed information about xusb_padctl, refer to the documentation in https://nv-tegra.nvidia.com/r/plugins/gitiles/linux-5.10/+/refs/heads/l4t/l4t-r35.1.ga-5.10/Documentation/devicetree/bindings/phy/.
Example: USB Port Enablement for xusb_padctl
Take J6 (Type-A stacked port), for example, and create a pad/port node and property list:
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";
status = "okay";
};
...
usb3-0 {
nvidia,usb2-companion = <1>;
status = "okay";
};
...
};
};
Under the xHCI Node¶
The Jetson Orin xHCI controller complies with xHCI specifications, which supports the USB 2.0 HighSpeed/FullSpeed/LowSpeed and USB 3.2 SuperSpeed protocols.
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
<type>-<port_number>, where<type>is"usb2"or"usb3", and<port_number>is the associated port number.nvidia,xusb-padctl: A pointer to thexusb-padctlnode.
Refer to kernel/kernel-5.10/Documentation/devicetree/bindings/usb/nvidia,tegra-xhci.txt for more information about xHCI.
Example: USB Port Enablement or tegra_xhci
This example contains a J6 example and creates an xHCI node and property list:
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 On-The-Go Port¶
For an example OTG implementation, refer to For an On-The-GO Port. The Orin Nano Developer Kit implementation is similar, but it uses the fusb301 controller instead of the ucsi_ccg controller.
Configuring the UPHY Lane¶
The Jetson Orin NX/Nano SOM supports two UPHY configurations as shown below.
Jetson Orin NX/Nano Module Pin Names |
Orin NX/Nano functions |
Orin UPHY Block and Lane |
Config Option #1 |
Config Option #2 |
|---|---|---|---|---|
PCIE0_RX0/TX0 |
PCIE #0 Lane 0 |
UPHY0, Lane 4 |
PCIE x4 (C4), RP/EP |
PCIE x4 (C4), RP/EP |
PCIE0_RX1/TX1 |
PCIE #0 Lane 1 |
UPHY0, Lane 5 |
PCIE x4 (C4), RP/EP |
PCIE x4 (C4), RP/EP |
PCIE0_RX2/TX2 |
PCIE #0 Lane 2 |
UPHY0, Lane 6 |
PCIE x4 (C4), RP/EP |
PCIE x4 (C4), RP/EP |
PCIE0_RX3/TX3 |
PCIE #0 Lane 3 |
UPHY0, Lane 7 |
PCIE x4 (C4), RP/EP |
PCIE x4 (C4), RP/EP |
PCIE1_RX0/TX0 |
PCIE #1 Lane 0 |
UPHY0, Lane 3 |
PCIE x1 (C1), RP |
PCIE x1 (C1), RP |
CSI4_D[0:2]_RX0/TX0 |
PCIE #2 Lane 0 |
UPHY2, Lane 0 |
PCIE x2 (C7), RP |
PCIE x1 (C7), RP |
CSI4_D[1:3]_RX1/TX1 |
PCIE #2 Lane 1 |
UPHY2, Lane 1 |
PCIE x2 (C7), RP |
PCIE x1 (C9), RP |
USBSS_RX/TX |
USB SS #1 |
UPHY0, Lane 0 |
USB 3.2 [P0] |
USB 3.2 [P0] |
DP0_TXD[1:0]_N/P |
USB SS #2 |
UPHY0, Lane 1 |
USB 3.2 [P1] |
USB 3.2 [P1] |
DP0_TXD[3:2]_N/P |
USB SS #3 |
UPHY0, Lane 2 |
USB 3.2 [P2] |
USB 3.2 [P2] |
UPHY0/1/2 are called HSIO, NVHS, and GBE respectively. The Orin NX/Nano SOM does not use NVHS, and it is powered down.
To select Configuration #1, define the following variable in the flash config file:
ODMDATA="gbe-uphy-config-8,hsstp-lane-map-3,hsio-uphy-config-0";
To select Configuration #2, define the following variable in the flash config file:
ODMDATA="gbe-uphy-config-9,hsstp-lane-map-3,hsio-uphy-config-0";
The ODMDATA string is in the p3767.conf.common file in the BSP. Based on config options, C7 and C9 PCIe device tree nodes also need to be reflected.
Examples
Configuration Option 1 (PCIe Device Tree)
pcie@141e0000 { /* C7x2 node */ status = "okay"; phys = <&p2u_gbe_0>, <&p2u_gbe_1>; phy-names = "p2u-0", "p2u-1"; };
Configuration Option 2 (Device Tree)
pcie@141e0000 { /* C7x1 node */ status = "okay"; phys = <&p2u_gbe_0>; phy-names = "p2u-0"; }; pcie@140c0000 { /* C9x1 */ status = "okay"; phys = <&p2u_gbe_1>; phy-names = "p2u-0"; };
ODM Data for T234¶
The following table provides information about the ODM data for T234.
31:26 |
25:23 |
22:18 |
17 |
16 |
15 |
14 |
13:0 |
|---|---|---|---|---|---|---|---|
HSIO UPHY Config |
NVHS UPHY Config |
GBE UPHY Config |
GBE3 Mode |
GBE2 Mode |
GBE1 Mode |
GBE0 Mode |
Reserved |
Config Number in HSIO UPHY Lane Mapping Options |
Config Number in NVHS UPHY Lane Mapping Options |
Config Number in GBE UPHY Lane Mapping Options |
0:5G, 1:10G |
0:5G, 1:10G |
0:5G, 1:10G |
0:5G, 1:10G |
TBD |
BPMP-FW DTB /uphy/hsio-uphy-config |
BPMP-FW DTB /uphy/nvhs-uphy-config |
BPMP-FW DTB /uphy/gbe-uphy-config |
BPMP-FW DTB /uphy/gbe3-enable-10g |
BPMP-FW DTB /uphy/gbe2-enable-10g |
BPMP-FW DTB /uphy/gbe1-enable-10g |
BPMP-FW DTB /uphy/gbe0-enable-10g |
TBD |
HSIO UPHY Lane Mapping Options¶
Config Number |
PLL0 |
Lane 0 |
Lane 1 |
PLL1 |
Lane 2 |
Lane 3 |
PLL2 |
Lane 4 |
Lane 5 |
Lane 6 |
Lane 7 |
PLL3 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 |
Disabled |
USB3.1 P0 |
USB3.1 P1 |
USB3/PCIE G2 |
USB3.1 P2 |
PCIE x1 C1 |
PCIE G4 |
PCIE x4 C4 |
PCIE x4 C4 |
PCIE x4 C4 |
PCIE x4 C4 |
USB3/PCIE G2 |
GBE UPHY Lane Mapping Options¶
Config Number |
PLL0 |
Lane 0 |
Lane 1 |
Lane 2 |
Lane 3 |
PLL1 |
Lane 4 |
Lane 5 |
Lane 6 |
Lane 7 |
PLL2 |
|---|---|---|---|---|---|---|---|---|---|---|---|
8 |
USB3/PCIE G2 |
PCIE x2 C7 |
PCIE x2 C7 |
PCIE x2 C8 |
PCIE x2 C8 |
PCIE G4 |
PCIE x2 C10 |
PCIE x2 C10 |
PCIE x2 C9 |
PCIE x2 C9 |
USB3/PCIE G2 |
9 |
USB3/PCIE G2 |
PCIE x1 C7 |
PCIE x1 C9 |
PCIE x2 C8 |
PCIE x2 C8 |
PCIE G4 |
PCIE x4 C10 |
PCIE x4 C10 |
PCIE x4 C10 |
PCIE x4 C10 |
PCIE C10 Only |
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.
Here is an example of what a flash config script should look like:
source "${LDK_DIR}/p3767.conf.common";
PINMUX_CONFIG="tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi";
PMC_CONFIG="tegra234-mb1-bct-padvoltage-p3767-dp-a03.dtsi";
BPFDTB_FILE="tegra234-bpmp-3767-0000-a02-3509-a02.dtb";
DTB_FILE="tegra234-p3767-0000-p3768-0000-a0.dtb";
TBCDTB_FILE="${DTB_FILE}";
EMMC_CFG="flash_t234_qspi_sd.xml";
Note
To be reflected in the flashed image, the parameters must be specified after sourcing the <xxx>.conf.common file .
For example, you can flash to NVMe like this:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
-c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
--showlogs --network usb0 <board> internal
For more flashing support and options, refer to Flashing Support.
Note
UEFI picks the kernel image and dtb from the rootfs path that is mentioned in /boot/extlinux/extlinux.conf file. If you mentioned an image and dtb in this file, these items will be given precedence. For example, you might want to scp the file to the Jetson target path in the file. If this information is not mentioned, or the file is not present, the Kernel Image or dtb will be selected from the flashed partition in the storage device.
Setting Optional Environmental Variables¶
The flash.sh script updates the following environment variables based on board EEPROM and other parameters that were passed. To provide specific values to these variables, define them in the board-specific file board.conf 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.
# <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