Flashing Basics

Note: You do not need to use sudo for the following commands:
  • bootburn.py
  • create_bsp_images.py
  • flash_bsp_images.py

However, if you choose to use sudo for one, use it consistently the others. Do not switch between sudo/non-sudo usage.

This topic provides guidance on flashing preprocessed binaries.

Flashing AURIX from NVIDIA Orin

You can use the nv_aurix_check_fw script to check the AURIX firmware version on boot.

  • The script is located at

    • For QNX:
    • For Linux:
  • If the AURIX firmware is the latest version, a corresponding message is displayed at the console.
  • If the AURIX Main firmware version requires updating, the AURIX update command runs automatically and updates the firmware to the latest version.

    The correct hex file for flashing is chosen from the root filesystem at /lib/firmware.

  • After the Main AURIX firmware is updated, the version of the Update firmware is checked and the Update firmware is flashed if a newer version is found.

To check the firmware version again from the SoC:

  • Run the command:

    • For QNX:
      /bin/ksh /proc/boot/nv_aurix_check_fw.sh
    • For Linux:
      sudo /bin/bash /etc/systemd/scripts/nv_aurix_check_fw.sh

To update the AURIX firmware:

  1. Ensure that both the Main (NV-IFW or AFW) AURIX firmware and the UPDATE(NV) firmware files are in the root filesystem.
  2. Ensure that the files follow the naming convention as follows:



    • The path to the AFW firmware and UPDATE firmware is:
      • /lib/firmware/*<platform>-AFW-Aurix-*
      • /lib/firmware/*<platform>-NV-Aurix-UPDATE* 
    • NV indicates NVIDIA internal firmware.
    • AFW indicates AUTOSAR firmware from the vendor Vector.
    • <platform> is the board number, such as P3663.
    • <FW_Type> is IFW / UPDATE / AFW.
    • <Board> StepB.
    • <major> contains one numeric digit.
    • <minor> contains two numeric digits.
    • <revision> contains two numeric digits.
    • <snapshot> contains two numeric digits.
    • Items in brackets [ ] are optional.
    • Version numbers with 1.x.x indicate internal firmware; 5.x.x is the AFW from vendor Vector.
  3. Update the firmware by running the command:

    • For QNX:
      </bin/ksh/ /proc/boot/nv_aurix_check_fw.sh -auto_update
    • For Linux:
      <sudo /bin/bash /etc/systemd/scripts/nv_aurix_check_fw.sh -auto_update

    Where the path to the AFW and UPDATE firmware is as follows:

    • /lib/firmware/*<platform>-AFW-Aurix-*
    • /lib/firmware/*<platform>-NV-Aurix-*

    Updating the firmware includes:

    • Comparing the firmware version between the flashed version and the one on the root filesystem.
    • Updating the firmware if a higher firmware version is in the root filesystem.
    • Resetting the platform.
  4. When the platform boots again, repeat the command to reset it a second time.

    After two resets, the AURIX MAIN firmware is updated.

  5. Rerun the command to update the UPDATE firmware.


    The AURIX flashing program/erase cycle is 1000. To avoid wear on the AURIX flash components, flash the firmware only when necessary.

    The flashing of AURIX MAIN and UPDATE firmware requires a maximum of two SoC resets, and three invocations of the nv_aurix_update application.

  6. Board supports only the Vector AFW (Versions 5.x.x) and NV internal firmware (version 1.x.x). When the Vector AFW hex file is not packaged in the /lib/firmware folder, the update script automatically chooses NV internal FW as an alternative.

Bind Steps for NVIDIA Orin System on a Chip (SOC)

For information about how to bind an NVIDIA Orin system on a chip, see See the "AV PCT Configuration" topic in the NVIDIA DRIVE OS Linux PDK Developer Guide.

Flash Steps for NVIDIA Orin System on Chip (SoC)

Use the bootburn utility to flash platform boards with the boot loader, kernel, and file system. The bootburn utility is provided as part of the Foundation package.


Bootburn is a Python script that:

  • Boots the device in the recovery-mode with RAMDisk
  • Signs or generates the images on the host
  • Transfers the images to target using ADB
  • Flashes the boards

Bootburn automatically resizes the rootfs image on the target to optimize the available storage on the partition dedicated to it, either on eMMC or NOR.

Bootburn supports a host NFS share as the mount point for the target rootfs. This feature provides a convenient way for developers to copy files between the target and host for rapid development. In this case, the uncompressed target rootfs directory on the host is leveraged directly by the target.

Bootburn relies on the Foundation services to provide the flashing and boot loader functionality. You configure it with the CFG file rather than with bootburn command-line parameters; the bootburn utility supports limited command-line options.

Bootburn Command Usage

Run the bootburn.py script from a shell on your host Linux system by executing the command:

./bootburn.py <options>

Bootburn Options




<p3710-10-a01 | p3710-10-a03 | p3710-10-a04 | p3710-10-s05 | p3710-12-a01 | p3710-12-a03 | p3710-12-a04 | p3710-12-s05 | p3663-a01 | p3663-01-a02 | p3663-02-a02 | p3898-a01>

(lowercase b)

Provides the board name and revision. Possible board names include:

  • p3710-10-a01
  • p3710-10-a03
  • p3710-10-a04
  • p3710-10-s05
  • p3710-12-a01
  • p3710-12-a03
  • p3710-12-a04
  • p3710-12-s05
  • p3663-a01
  • p3663-01-a02
  • p3663-02-a02
  • p3898-a01

Not all boards are supported in Safety and Standard. For more information, see the API Reference.

--board_config <board_name>.json

Can be used with bootburn.py, create_bsp_images.py, and flash_bsp_images.py board_name must include absolute path.

-d <partition_name> <dtb_file>

(lowercase d)

Specifies the DTB file to flash and the target partition. The default file is defined in BoardSetFilePathsAndDefaultValues.

bpmp-fw-dtb and kernel-dtb may be specified simultaneously.

Note: This option is not intended to specify kernel-dtb in Hypervisor.


Takes as parameter the full file path and name. Secure boot encryption key. Can be used with bootburn.py and create_bsp_images.py. Additionally, edit drive-foundation/tools/flashtools/flash/tegrasign_v3_oemkey.yaml or drive-foundation-safety/tools/flashtools/flash/tegrasign_v3_oemkey.yaml
Find "SBK".
"AES" : {
"SBK" :
"Manifest" : "10860000",
"Offset" : "0d01",
#"Plain" : "63979cd900154cfaedc539cd17572387296058fe988013c055be99bfd8db41f9",
"Plain" : "753aafbeab213322ef0f8cecc805d1b086e252953dfb3cac215a778f68cb5a72",
#"Plain" : "0000000000000000000000000000000000000000000000000000000000000000",

(#) is a comment in yaml files. Add the key that is needed:

"Plain" : "<key>"

Where <key> is the hexidecimal value of the key. There are some standard SBK (Secure Boot Keys), so you may be able to uncomment the key. Make sure that all SBK entries are commented out (#) except for the one in use.

-f (lowercase)

Failure analysis (FA) mode support.


Specifies the firmware to flash to the dGPU.


(lowercase h)

Provides guidance on the actions and options of bootburn.

-i (lowercase i)

File path to platform configuration file. If not provided for hypervisor configurations, then the tool expects the platform configuration file to be present in the hypervisor output directory.

-k <configuration file>

(lowercase k)

Specifies the configuration file for flashing.

-m (lowercase)

Flashing Modular Diagnostic Software (MODS). This option enables mods-specific overrides.


(lowercase o)

Skips flashing of recovery partitions. Used by minicom.

WARNING: If you are using minicom with -o option, minicom does not initialize the port and therefore does NOT check or acquire the lock files for the communication port. If minicom is running in the background and you run bootburn with the -x option, bootburn acquires the lock BEFORE accessing the communication port. So, when bootburn attempts to communicate with AURIX it fails.

-p <key_file_path>

(lowercase p)

Signs the boot loader, secure OS (TOS), kernel and BCT binary, then flashes the device. <key_file_path> must be the full pathname of the key_file.

--hsm <key_string>

Can be used with bootburn.py and create_bsp_images.py. Tells Bootburn what keys will be used in HSM mode. Key String is Key + Encrypt Keys. Key is rsa. Encrypt Keys are sbk. Example:

--hsm rsa


(lowercase q)

Flashes QNX images.


(lowercase s)

Skips flashing the file system.

Use the -s flag only when the target file system is already flashed.

-t <output_directory>

(lowercase t)

Specifies the output directory where images to be flashed onto the target are to be stored. The default directory is named _temp_dump, and is present in the flashing directory.


Specifies the communication port for AURIX to put the SoC in recovery mode automatically.

With this -x option, bootburn performs target validation for the user provided board name on the command line, with the -b option, before flashing the board.

Bootburn generates a unique ID from the target Inforom data. The allowed target ID list for the user provided board is generated from BOM data file included in the package. Bootburn aborts flashing if the target unique ID is not found in the list of generated unique IDs for the provided board name. This feature is supported on P3710, P3663, and P3898 boards with Inforom system object version 3 or above.


On boards with inforom, the bct sku info is updated with the information in the inforom.

If the -x option is used during the AURIX setup, at the end during the AURIX reset of the flashing procedure there may be output messages of the form: "Killed sudo cat $l_Aurix > $p_FlashFiles/$l_AurixLogFile". These messages are not errors and can be safely ignored.


If minicom is used with the -o option, minicom does not initialize the port and therefore does NOT check or acquire the lock files for the communication port.

  • If minicom is running in the background and you run bootburn with the -x option, bootburn acquires the lock BEFORE accessing the communication port. So when bootburn attempts to communicate with AURIX it fails.
  • If you quit minicom forcefully it may not fully stop the process and it will be lingering in the background.
  • When bootburn attempts to connect in this state it will acquire the port but the output will still be directed to the minicom running in the background.
  • Avoid using the -o option when using minicom.

-B <boot_device>

(uppercase B)

Specifies the boot device, which must be either qspi or emmc. qspi is the default.


(uppercase C)

Specifies use of debug binaries for the boot loader.


(uppercase D)

Directs bootburn debug output to stdout along with the tool's regular output. If -D is not specified, debug output goes to a temporary file.


(uppercase E)

Enables DRAM ECC.

-I <bus_id> <device_id>

(uppercase I)

Flashes a specific device when multiple devices are in recovery.

To get the bus and device ID of each device in recovery, enter the lsusb command on the host. For example, if lsusb gives the following output:

Bus 003 Device 105: ID 0955:7018 NVidia Corp.

Bus 003 Device 104: ID 0955:7018 NVidia Corp.

Then flash the second device with the –I option as in this example:

-I 003 104


(uppercase L)

Enables low-power modes. This option requires that the spe-fw and WB0 firmware packages be included in the bootburn configuration because low-power modes require them.


(uppercase M)

Specifies development version firmware.


(uppercase R)

Specifies RCM boot support, where the device boots without being flashed. When the target is in recovery mode, this option causes the flashing script to download all binaries, other than BCT, from the host. The target then reads the BCT from storage and other binaries from RAM. It boots the kernel directly on RAM.

This option is much faster than when flashing also occurs. It is especially useful during debugging.

Use the -R flag to initiate RCMBOOT with any of the commands mentioned in this table.


(uppercase T)

Enables tracing. Tracing logs are stored under the bootburn directory as log_trace*.txt.


Execute bootburn scripts in safety mode. Only a limited set of options is available for use in safety mode. For more information, see the Safety Use Cases for Bootburn Scripts chapter in the NVIDIA DRIVE OS 6.0 Safety Developer Guide for more information.


Pass in the UFS provision configuration file.


(uppercase V)

Specifies read-back verification, where the binary images are read back (after writing) from the target's storage and compared with the original binary images. The two sets of images are compared to detect discrepancies.


Specified customer data such as skuinfo and others to be updated during flashing

See flashing_customer_data.docx for information on how to use it.

Passing Additional Parameters

To pass additional kernel parameters, modify the os_args parameter of the kernel-dtb partitions in:


Flashing with Docker

The NVIDIA DRIVE® OS Docker build image contains a python script called flash.py to flash the target.


flash.py [-h] [--disable-full] [--pct-variant PCT] [--tegra TEGRA] [--clean] 
[--recovery-timeout [TIMEOUT]] [--bind-opt BIND_OPT] [--opt-arg OPT_ARG] AURIX_PORT BOARD
The following table shows required and optional arguments:
Argument Description
BOARD Specifies the target board base name.
AURIX_PORT Specifies AURIX Port for the desired board.


Use the following flash.py options to override the default parameters:

Option Description
--tegra TEGRA Specify the NVIDIA Tegra® chip to flash. The default is Tegra A.
-h, --help Shows usage/help output and exits.
--disable-full Flash single bootchain. Otherwise, will flash both bootchains.
--pct-variant PCT Specify the PCT variant to flash.
--clean Perform clean flash to re-initialize persistent partitions.
--recovery-timeout [TIMEOUT] Specify the time required for the device to be available after it is set to recovery.
--bind-opt BIND_OPT, -b BIND_OPT Specify arguments to pass through to bind partitions utility.
--opt-arg OPT_ARG, -o OPT_ARG Specify argument to pass through to bootburn flashing utility.


  • Flash the default configuration for p3710 the Docker image on board connected to /dev/ttyACM1:
    # ./flash.py /dev/ttyACM1 p3710
  • If a PCT is required to be specified (for QNX, QNX Safety, Prod Linux, and so on), pass the PCT variant as an argument:

    # ./flash.py --pct-variant prod /dev/ttyACM1 p3710
  • Additional Make arguments can also be passed through for the binding phase. For instance, to set R/W permissions on Root FS for the NDAS use case.

    # ./flash.py --bind-opt '-u ndas' --bind-opt 'OS_ARGS_MOUNT_PER=rw' /dev/ttyACM0 p3710 
    # ./flash.py -b '-u ndas' -b 'OS_ARGS_ROOT_MOUNT_PER=rw' /dev/ttyACM0 p3710
  • Additional arguments can be passed through for the flashing phase. For instance to disable UART on target for rcm-boot and cold-boot:

    # ./flash.py --opt-arg '--disable_uart' /dev/ttyACM0 p3710 
    # ./flash.py -o '--disable_uart' /dev/ttyACM0 p3710

Flashing AURIX

AURIX is intended for debugging and sanity checking purposes.

Note: In this section, <top> refers to the root directory of the guest VM.

Flashing AURIX from Windows Host with Infineon Memtool

Step 1: Target Setup

On P3710

P3710 uses TOPO MCU to provide Aurix UART console access; you should connect microUSB to your windows host machine as shown in the following figures.

You should see a list of /dev/ttyACM*. Usually Aurix is the 2nd in the list of /dev/ttyACM*, which is /dev/ttyACM1 if starting from /dev/ttyACM0. You should find the Aurix console first before flashing.

On P3663

P3663 does not have TOPO MCU for Aurix UART console; instead, the Aurix UART signal (VCC/TX/RX/GND) is routed to the jumper below.

You should connect the Aurix UART console jumper to

  • USB-UART cable
  • Windows host

In Windows host, you should see /dev/ttyUSB* for Aurix console.

On P3898

P3898 does not have TOPO MCU for Aurix UART console; instead, the Aurix UART signals (VCC/RX/TX/GND) are routed to the jumper J1_34 as shown below.

You should connect the Aurix UART console jumper to:
  • USB-UART cable
  • Windows host
Note: The Rx and Tx pins indicated below are respectively input and output from AURIX, so connect the USB-UART cable pins accordingly. For example, connect USB-UART Tx to Rx on board.

On the Windows host, you see /dev/ttyUSB* for AURIX console.

Step 2: Host Setup

Use a Windows machine for this upgrade.

  1. Download and install the latest memtool from Infineon.
  2. For P3663 and P3710, use the UART cfg file below:
    Description=TriBoard with TC39x B-Step (BSL/ASC)
    Architecture=TriCore Aurix
    Vendor=Starter Kits (Bootstrap Loader)
    If you use miniwiggler to upgrade (a JTAG debugger), you should use the miniwiggler one.
    Note: This is the same configuration file as the Xavier platform step B AURIX. For UART, the TriBoard_TC39xB_ASC_BSL.cfg configuration file is located in the delivery folder.
  3. For P3898, the Miniwiggler configuration file to be used for flashing through UART is located in the delivery folder and is named TriBoard_TC36x.cfg.


  1. Find the jumper below and insert JP 1-2 (short pin 1 and pin 2).
  2. Power cycle the P3710 system.

    This can put Aurix into recovery mode. In this mode, Aurix console does not show any message.

    Note: Close any tool that opening Aurix console before proceeding to the next step.

Step 3: Put Aurix into Recovery Mode

First put Aurix into recovery mode.


  1. P3663 does not have TOPO, so you need to insert pin 1 and pin 2 for the jumper.
  2. Power cycle P3663.


  1. Short J1_57 pins 1 and 2 to set HWCFG3 = 0 for UART boot. Please refer the figure below for location of the jumper and pins to be shorted. As shown in the figures below, access to these pins vary across P3898 board revisions.
  2. Power cycle P3898.

    P3898 (A00)

    P3898 (B00)

Step 4: Connect Memtool to Aurix

To start the memtool,

  1. Choose Target > Change and select the folder where you have saved the configuration file in step 2.
  2. Select Triboard with TC39x (BSL/ASC) and click OK. For P3898, select Triboard with TC36x (BSL/ASC).
  3. Choose Target > Setup and select Remember device name (e.g. COM1).
  4. In Access Device, choose the COM port as identified in step 1.
  5. Add “set DTR” to the RTS/DTR Connect settings as shown below.

    If you have tried to connect but failed. Restart memtool and P3710, and ensure you have this setting.

Step 5: Start Flashing

  1. Click Open File and select the file.
  2. Click Select All.
  3. Click Add Sel. >> to add all the file content to the flash area.
  4. Click Program all to start the flashing.

    The flash should start and finish.

    Note: Do not use the Erase button in the memtool.

Note: For P3898 with TC36x AURIX variant, the PFLASH size is shown as 4 MByte.

Flashing AFW from Orin Using Force Update

AFW can also be flashed using the update script from the NVIDIA Orin console.

Prerequisites: The following firmware versions on MCU are required:
  • Internal firmware (IFW) version 1.46.4 or the latest
  • Update firmware (UFW) version 1.46.4 or the latest
  • For P3898, IFW and UFW version 1.60.2 or later


  • For Linux:
    sudo /bin/bash /etc/systemd/scripts/nv_aurix_check_fw.sh -force_update AFW_Firmware_to_be_Programmed
  • For QNX:
    /bin/ksh /proc/boot/nv_aurix_check_fw.sh -force_update AFW_Firmware_to_be_Programmed
sudo /bin/bash /etc/systemd/scripts/nv_aurix_check_fw.sh -force_update DRIVE-V6.0.0-P3710-AFW-Aurix-StepB-5.00.01.hex
Run this command twice:
  1. On first execution of this command, control switches from IFW to UFW leading to NVIDIA Orin reset during switching.
  2. After NVIDIA Orin starts up completely, repeat this command, which starts AFW flashing.