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-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.


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:


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, p3678 is the name of the carrier board from the Jetson Orin Nano 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 and 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.


For the sample Ubuntu root filesystem provided by NVIDIA, this customization is applied using the Linux_for_Tegra/ 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 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:

  1. Go to .

  2. Search for pinmux and download the spreadsheet for Orin NX and Nano Series.

    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:


    The names of the generated files depend on the input you provided during Generate DT File.

    • pinmux.dtsi

    • gpio.dtsi

    • padvoltage.dtsi


    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:

To dynamically change the pinmux:

  1. Get the pinmux register address.

    1. In TRM, click System Components Multi-Purpose I/O Pins and Pin Multiplexing (PinMux) Pinmux Registers .

    2. Search for the pin name (for example, SOC_GPIO37).

    3. Write down the complete pin name.

      For example, PADCTL_G3_SOC_GPIO37_0 and the Offset (for example, SOC_GPIO37: Offset = 0x80).

    4. Go to the Jetson Orin Technical Reference Manual at , and in Table 1-15: Pad Control Grouping , find the G3 pad control block = PADCTL_A0 entry.

    5. On the Memory Architecture page, click Memory Mapped I/O Address Map .

    6. 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.

    1. Install devmem.

      $ 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.

    1. Set GPIO to Bit 10 = 0.

    2. For the output, set Bit 4 = 0 ; Bit 6 = 0.

    3. 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 .

$ 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

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.

    1. 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:


      Number of Pins

      Port Offset






























































































    2. 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.

    3. Identify the port as B and the Pin_offset as 0.

    4. Calculate the pin number with the following formula:

      base + port_offset + pin_offset

    5. 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.

    1. 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.

    2. Follow the gpio debugfs look up that use the port and offset.

      cat /sys/kernel/debug/gpio | grep PB.00

    3. 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


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 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:


- 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:

  • /hardware/nvidia/platform/t23x/

  • /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:


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




ODM data based feature configuration




NVIDIA SoC controller state to enable/disable a controller



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:


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

  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.

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 @ 14100000


pcie @ 14160000


pcie_ep @ 14160000


pcie @ 141e0000


pcie @ 140c0000

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.

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.

USB SerDes Lane Assignment

The SerDes lanes for USB SuperSpeed are part of the UPHY block. 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


UPHY0, Lane 0

USB 3.2 (P0)


UPHY0, Lane 1

USB 3.2 (P1)


UPHY0, Lane 2

USB 3.2 (P2)

Refer to UPHY Lane Configuration for a list of the supported PCIe configurations.

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 - , 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.


    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.

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 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:

tegra_xhci: xhci@3610000 {
    phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-1}>,
    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.

UPHY Lane Configuration

The Jetson Orin NX/Nano SOM supports the following UPHY configurations:

UPHY0 (HSIO) Configuration Options






USB 3.2 (P0)

USB 3.2 (P0)

USB 3.2 (P0)


USB 3.2 (P1)

USB 3.2 (P1)

USB 3.2 (P1)


USB 3.2 (P2)

USB 3.2 (P2)



PCIe x1 (C1), RP

PCIe x1 (C1), RP (Gen2)

PCIe x1 (C1), RP


PCIe x4 (C4), RP

PCIe x4 (C4), EP

PCIe x4 (C4), EP




When selecting hsio-uphy-config-40, PCIe C1 RP will be restricted to Gen2 speeds.

UPHY2 (GBE) Configuration Options





PCIe x2 (C7), RP

PCIe x1 (C7), RP


PCIe x1 (C9), RP

UPHY0/1/2 are called HSIO, NVHS, and GBE respectively. The Orin NX/Nano SOM does not use NVHS, and it is powered down.

The UPHY configuration is specified using the ODMDATA variable in the flash configuration file. The out-of-box configuration as defined in p3767.conf.common looks like this:


The GBE configuration and HSIO configuration are independent. For example, to use PCIe C7 and C9 as independent 1-lane controllers, select the gbe-uphy-config-9 configuration by adding a line like the following to your flash configuration file:


Do not edit this variable directly in the p3767.conf.common file. You should instead append that variable in your flash configuration file to override the default. To use PCIE C4 as an endpoint, use configuration hsio-uphy-config-40 or hsio-uphy-config-41 above. Refer to PCIE Endpoint Mode for more information.

ODM Data for T234

The following table provides information about the ODM data for T234.












GBE3 Mode

GBE2 Mode

GBE1 Mode

GBE0 Mode


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


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


HSIO UPHY Lane Mapping Options

Config Number


Lane 0

Lane 1


Lane 2

Lane 3


Lane 4

Lane 5

Lane 6

Lane 7




USB3.1 P0

USB3.1 P1


USB3.1 P2

PCIE x1 C1


PCIE x4 C4

PCIE x4 C4

PCIE x4 C4

PCIE x4 C4


GBE UPHY Lane Mapping Options

Config Number


Lane 0

Lane 1

Lane 2

Lane 3


Lane 4

Lane 5

Lane 6

Lane 7




PCIE x2 C7

PCIE x2 C7

PCIE x2 C8

PCIE x2 C8


PCIE x2 C10

PCIE x2 C10

PCIE x2 C9

PCIE x2 C9




PCIE x1 C7

PCIE x1 C9

PCIE x2 C8

PCIE x2 C8


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.

Here is an example of a flash configuration script:

source "${LDK_DIR}/p3767.conf.common";



To be reflected in the flashed image, the parameters must be specified after sourcing the .conf.common file .

For example, you can flash to NVMe like this:

$ sudo ./tools/kernel_flash/ --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0  internal

For more flashing support and options, refer to Flashing Support .


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 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.
#                          :::
# 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