.. _HR.JetsonModuleAdaptationAndBringUp.JetsonOrinNxSeries: .. include:: /content/swdocs.rsts .. spelling:: dts extcon fansink Fi Nano padctl proc Realtek subnode Wi xHCI Xorg xUDC xusb Designware usb gpio VBus T234 BCT SOM devkit EEPROM TTP P3767 P3509 MB1 MB2 devboard proc pinmux sdmmc-drv comm a00 nv.sh nvfb.sh dtsi Placeholders sdmmc drv Filesystem filesystem Req padvoltage devmem busybox tegra aon debugfs reflashing cvb dcb dtc Synopsys uphy phandle phy ccg ucsi otg xUCD tx jetson orin nx extlinux scp typec Jetson Orin NX Series !!!!!!!!!!!!!!!!!!!!! This guide describes how to port and bring up custom platforms using the NVIDIA® Jetson™ Orin™ NX module, which is based on the NVIDIA Jetson Linux Driver Package. The examples in this document include code for the Jetson Orin NX module and the Jetson Xavier™ NX carrier board. Refer to `T234 BCT (Boot configuration Table) Deployment Guide `_ for information about customizing the configuration files. Board Configuration @@@@@@@@@@@@@@@@@@@ The Jetson Orin NX P3767 is a System on Module (SOM), and it is pin compatible with the Xavier NX devkit carrier board P3509. This section uses that combination to illustrate how end users can use a custom design carrier board for this module. The SOM has an EEPROM where the board ID and system level details are saved, and the SOM can be used without any software configuration modifications. The SOM that is sold to be incorporated with customer products has a Thermal Transfer Plate (TTP) that is ready to accept a customer-provided thermal solution. Before you use the SOM with a carrier board other than P3509, 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 instead of the P3509. 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-devkit`` - ``devboard`` 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, ```` 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, ```` 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. - ```` is a functional module name, which might be power-tree, pinmux, sdmmc-drv, keys, comm (Wi-Fi/Bluetooth®), camera, and so on. - ```` is the name you selected to represent your platform. For example, p3509 is the name of the Jetson Xavier NX Developer Kit. The NVIDIA names use lower case letters. - ```` 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. - ```` 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.sh`` and ``nvfb.sh`` boot-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 ``/bootloader/t186ref/BCT`` Refer to :ref:`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 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: 1. Go to https://developer.nvidia.com/embedded/downloads. 2. Search for **Orin Series Pinmux** and download the spreadsheet. **Before** you open the spreadsheet, ensure that macros are enabled. 3. 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. 4. 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 ``/bootloader/t186ref/BCT/`` directory and copy the ``gpio.dtsi`` file to the ``/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: 1. Get the pinmux register address. a. In TRM, click **System Components** → **Multi-Purpose I/O Pins and Pin Multiplexing (PinMux)** → **Pinmux Registers**. b. Search for the pin name (for example, SOC_GPIO37). c. Write down the complete pin name. For example, PADCTL_G3_SOC_GPIO37_0 and the Offset (for example, SOC_GPIO37: Offset = 0x80). d. 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. e. On the Memory Architecture page, click **Memory Mapped I/O** → **Address Map**. f. 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. 2. Get the current register value in the device using the devmem tool. a. Install devmem. .. code-block:: none $ sudo apt-get install busybox $ busybox devmem <32-bit address> For example, busybox devmem 0x02430080. 3. 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. a. Set GPIO to Bit 10 = 0. b. For the output, set Bit 4 = 0 ; Bit 6 = 0. c. For Input, set Bit 4 = 1 ; Bit 6 = 1. 4. Use the devmem tool to set the register, for example, busybox devmem 0x02430080 w 0x050. 5. Verify that the register value is set accordingly. **An Example** To update Pin MCLK05: SOC_GPIO33: PQ6: 1. Adjust the pinmux to map the pin to GPIO. 2. Configure the GPIO controller (input, output high, or output low). To configure the pinmux for this pin: 1. The Pinmux register base address is 0x2430000. - The Offset is 0x70. - The Pinmux register address is 0x2430070. 2. Run the following command. ``$ busybox devmem 0x02430070`` The output value is 0x00000054. 3. To set the pin as the output, run the following command. ``$ busybox devmem 0x02430070 w 0x004`` 4. To 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`_. .. code-block:: none $ echo 454 > /sys/class/gpio/export $ cd /sys/class/gpio/PQ.06 $ echo out > direction $ cat value # change value and check 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: .. code-block:: none 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. a. 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: .. list-table:: :widths: auto :header-rows: 1 * - 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 b. Search for the pin details from the Jetson Orin NX pinmux table (refer to `Generating the Pinmux dtsi Files`_). For example SOC_GPIO08 is GPIO3_PB.00. c. Identify the port as B and the Pin_offset as 0. d. Calculate the pin number with the following formula: ``base + port_offset + pin_offset`` e. Verify 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_offset`` of port B = 8 This value comes from the tegra234 GPIO port and the offset mapping above. - pin_offset = 0 - Pin number = 348 + 8 + 0 = 356 - Using Kernel debugfs. a. Search for the GPIO pin in the Jetson Orin NX pinmux table (refer to `Generating the Pinmux dtsi Files`_). For example, SOC_GPIO08, which is GPIO3_PB.00. b. Follow the gpio debugfs look up that use the port and offset. ``cat /sys/kernel/debug/gpio | grep PB.00`` c. The GPIO number is mentioned in the first column as gpio-356. ``root@jetson:/home/ubuntu# cat /sys/kernel/debug/gpio | grep PB.00`` ``gpio-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 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 :ref:`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`` .. code-block:: none - 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 P3509 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 :ref:`downloaded` and are available in the following directories: - ``/hardware/nvidia/platform/t23x/`` - ``/hardware/nvidia/soc/t23x`` The final DTB file that is used is generated from the ``tegra234-p3767-0000-p3509-a02.dts`` source device tree (DT) file: ``tegra234-p3767-0000-p3509-a02.dtb`` By reading the source DT file, you see the other .dtsi files that are referenced by the include statements, specifically the cvb/tegra234-p3509-a02.dtsi file, and the display node includes the tegra234-dcb-p3767-0000-p3509-a02.dtsi file. Refer to :ref:`Display Configuration and Bring-up ` for more information about the display panel and node. The ``cvb/tegra234-p3509-a02.dtsi`` file represents the carrier board, P3509 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, end users can take the existing P3509 and start modifying with the ``cvb/tegra234-p3509-a02.dtsi`` file as a starting point. The following table provides a list of the notable DT files that are affected during the customization process. .. list-table:: :widths: auto :header-rows: 1 * - Types of Changes - DTSI Filename or Location * - Power supply changes - ``tegra234-p3509-a02-fixed-regulator.dtsi`` * - Audio - ``tegra234-p3509-audio.dtsi`` * - ODM data based feature configuration - ``respective overlay dt, for example, pcie: tegra234-p3509-a02-pcie.dtsi`` * - USB - ``tegra234-p3509-a02.dtsi`` * - NVIDIA SoC controller state to enable/disable a controller - ``soc/t23x/kernel-dts/tegra234-soc/`` .. 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: .. code-block:: none dtc -I dtb -O dts tegra234-p3767-0000-p3509-a02.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 series has the following PCIe controllers with these specifications: .. note:: Not all the controllers are available for user access in the Jetson ONX module. - Speed: All controllers support up to Gen4 speed. - Lane width: - C5, C7: up to x8 - C0, C4, C6, C10: up to x4 - C8, C9: up to x2 - C1, C2, C3: x1 - Controllers: Controllers C5, C6, C7 and C10 support dual mode, that is, can be configured as endpoints. - ASPM: All controllers support ASPM. Enabling PCIe in a Customer Carrier Board Design ################################################ 1. Select the appropriate UPHY configuration that suits the carrier board design and update ODMDATA accordingly (refer to Configuring the UPHY Lane for more information). 2. Enable the appropriate PCIe node from the table below. 3. 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). 4. Add the pipe2uphy phandle entries as a phy property in the PCIe controller DT node. .. code-block:: none 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: .. list-table:: :widths: auto :header-rows: 1 * - PCIe Controller and Mode - PCIe Controller DT Mode * - PCIe C0 RP - pcie@14180000 * - PCIe C1 RP - pcie@14100000 * - PCIe C2 RP - pcie@14120000 * - PCIe C3 RP - pcie@14140000 * - PCIe C4 RP - pcie@14160000 * - PCIe C5 RP - pcie@141a0000 * - PCIe C6 RP - pcie@141c0000 * - PCIe C7 RP - pcie@141e0000 * - PCIe C8 RP - pcie@140a0000 * - PCIe C9 RP - pcie@140c0000 * - PCIe C10 RP - pcie@140e0000 * - PCIe C5 EP - pcie_ep@141a0000 * - PCIe C6 EP - pcie_ep@141c0000 * - PCIe C7 EP - pcie_ep@141e0000 * - PCIe C10 EP - pcie_ep@140e0000 Porting Universal Serial Bus @@@@@@@@@@@@@@@@@@@@@@@@@@@@ Jetson Orin can support up to four 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. The Jetson P3767 SOM can support three USB ports. 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. .. figure:: JetsonXavierNxSeries/UsbSuperspeedPortPinout.svg :alt: USB SuperSpeed port pinout 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: .. list-table:: :widths: auto :header-rows: 1 * - Jetson SODIMM Signal Name - Orin UPHY Block and Lane - Jetson Orin NX 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 NX Series SOC Technical Reference Manual (TRM) `_, the NVIDIA Jetson Orin NX Series 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 P3509 Xavier NX 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. .. image:: JetsonOrinNxSeries/HostOnlyPort.png :width: 400 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 pads Subnode %%%%%%%%%%%%%%%% - ``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: - ``host`` - ``peripheral`` - ``OTG`` - ``nvidia,usb2-companion``: USB2 port (0, 1, or 2) to which the port is mapped. A port for USB3 must have this property. - ``nvidia,oc-pin``: The overcurrent ``VBUS`` pin the port is using. The value must be positive or zero. .. note:: 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``: ``VBUS`` regulator for the corresponding UTMI pad. Set to ``&battery_reg`` for 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: .. code-block:: none 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 in ``phy-names``. - ``phy-names``: Must include an entry for each PHY used by the controller. Names must be in the form ``-``, where ```` is ``"usb2"`` or ``"usb3"``, and ```` is the associated port number. - ``nvidia,xusb-padctl``: A pointer to the ``xusb-padctl`` node. 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: .. code-block:: none 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 $$$$$$$$$$$$$$$$$$$$$ The Xavier NX P3509 carrier board does not have an On-the-Go (OTG) port. For an example OTG implementation, please see the Section :ref:`For an On-The-GO Port ` of the Jetson AGX Orin Adaptation Guide. Configuring the UPHY Lane ######################### The Jetson Orin NX SOM supports two UPHY configurations as shown below. .. list-table:: :widths: auto :header-rows: 1 * - Jetson Orin NX Module Pin Names - Orin NX 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 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)** .. code-block:: none pcie@141e0000 { /* C7x2 node */ status = "okay"; phys = <&p2u_gbe_0>, <&p2u_gbe_1>; phy-names = "p2u-0", "p2u-1"; }; **Configuration Option 2 (Device Tree)** .. code-block:: none 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. .. list-table:: :widths: auto :header-rows: 1 * - 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 ############################## .. list-table:: :widths: auto :header-rows: 1 * - 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 ############################# .. list-table:: :widths: auto :header-rows: 1 * - 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 ``.conf`` file during the flashing process. 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. .. code-block:: none # 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. # ::: # NFSROOT ---------------- NFSROOT i.e. :/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:: The parameters must be added under the reference to the ``.conf.common`` file to be reflected in the flashed image. Here is an example of environment variable settings: .. code-block:: none source "${LDK_DIR}/p3767.conf.common"; PINMUX_CONFIG="tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"; PMC_CONFIG="tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"; BPFDTB_FILE=tegra234-bpmp-3767-0000-a02-3509-a02.dtb; DTB_FILE=tegra234-p3767-0000-p3509-a02.dtb; TBCDTB_FILE=tegra234-p3767-0000-p3509-a02.dtb; EMMC_CFG=flash_t234_qspi_sd.xml; OVERLAY_DTB_FILE="tegra234-p3767-0000-p3509-a02-hdr40.dtbo"; Run the following command:: $ 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 p3509-a02+p3767-0000 internal For more flashing support and options, refer to :ref:`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 mentioned 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.