Installing NVIDIA DriveOS for NVIDIA Developer Users#
To install NVIDIA DriveOS™ 7.2, you can pull and run DriveOS Linux Early Access Docker images from the NVIDIA GPU Cloud Access (NGC) container registry, then bind and flash the target system.
Binding prepares the boot, kernel, and filesystem images for your specific DRIVE AGX board variant and partition layout.
Flashing writes those images to the target over USB while the SoCs are in recovery mode, replacing the on-device software with NVIDIA DriveOS.
Together, these steps install DriveOS onto the DRIVE AGX Thor Developer Kit from your host PC.
For the end-to-end flashing flow for NVIDIA Developer users, follow the Flashing Checklist in order for a first-time flash, or jump directly to any step.
Flashing Checklist#
Complete these steps in order:
Pre-flight checks:
Confirm Requirements for Development Environments and complete Configuring NVIDIA GPU Cloud (NGC) Access for NVIDIA Developer Users.
Start the Docker container:
Mount
/drive_flashingand device nodes; refer to Preparing to Bind and Flash the Target System.Recovery mode:
Understand how the target enters recovery mode before you flash; refer to Putting the Target in Recovery Mode.
Bind partitions:
Prepare flash images inside the container; refer to Binding and Flashing the Target Manually (bind step).
Flash the target:
Run
bootburn.py; refer to Binding and Flashing the Target Manually (flash step).Post-flash verification:
Accept the EULA, create a user account, and verify versions; refer to Finalizing the Installation.
(Optional) Additional packages:
Download and install CUDA, TensorRT, DriveWorks, and other SDK packages; refer to Optional: Downloading and Installing Additional NVIDIA DriveOS Packages from NGC.
Optionally, you can pull and run the container image ahead of time to confirm NGC access; refer to Pulling and Running the NVIDIA DriveOS Docker Container Image via NGC.
Images Available for NVIDIA DriveOS 7.2 Early Access#
Image Name |
Intent |
|---|---|
|
Build and Flash NVIDIA DriveOS 7.2 Linux Early Access SDK |
Pulling and Running the NVIDIA DriveOS Docker Container Image via NGC#
After configuring registry access to NGC, you can pull and run the NVIDIA DriveOS Docker container image on your host system. This is useful for confirming access and pre-pulling the image.
Tip
Prior to installation, you can choose to remove previously installed NVIDIA DriveOS Docker images and containers to increase space capacity.
Pull and run the NVIDIA DriveOS Docker container image by running the following command on your host system:
Note
The $ command prompt in example commands indicates running the command as a standard (non-root) user.
$ sudo docker run -it --privileged --net=host -v /dev/:/dev/ \
-v ${WORKSPACE}:/home/nvidia/ \
nvcr.io/drive/driveos-sdk/
drive-agx-linux-nsr-aarch64-sdk-build-x86-earlyaccess:<version>-<build>
Where:
${WORKSPACE}is the native host directory you want to share inside the container.<version>-<build>is the image version and build tag that you copied during Configuring NVIDIA GPU Cloud (NGC) Access for NVIDIA Developer Users.
Preparing to Bind and Flash the Target System#
To prepare to bind and flash NVIDIA DriveOS to the target system from the Docker container, perform the following steps:
Connect the DRIVE AGX to the host system.
Note
Refer to the NVIDIA DRIVE AGX Thor Developer Kit Hardware Quick Start Guide.
Ensure that the DRIVE AGX is connected to the host system and that no other processes, such as TCUMuxer or Minicom, are holding a lock on
/dev/ttyACM*before starting the Docker container:To check if a process is holding the lock, run the following command:
$ lsof -w /dev/ttyACM*
To kill a process that is locking a specific port, run the following command:
$ kill -9 <pid>
Where
<pid>is the corresponding Process ID (PID).
Verify that the host can detect the target USB devices before flashing.
On the host system outside of the Docker container, run the following commands:
$ lsusb | grep -i 'Tegra On-Platform Operator' $ lsusb | grep -i 'NVIDIA Corp. APX'
The
Tegra On-Platform Operatordevice indicates that the Tegra serial endpoint is visible to the host. TheNVIDIA Corp. APXdevice indicates that the target is in recovery mode and visible to flashing tools.If
NVIDIA Corp. APXis not listed when the target is expected to be in recovery mode, do not continue withbootburn.py. Check the USB connection, confirm that the correct debug USB Type-C port is connected, and put the target into recovery mode before retrying.Start the NVIDIA DriveOS Docker container by running the relevant following command:
$ sudo docker run -it --privileged --net=host -v /drive_flashing:/drive_flashing \ -v /dev/:/dev/ -v ${WORKSPACE}:/home/nvidia/ \ nvcr.io/drive/driveos-sdk/drive-agx-linux-nsr-aarch64-sdk-build-x86-earlyaccess:<version>-<build>
Putting the Target in Recovery Mode#
Flashing requires the DRIVE AGX SoCs to be in recovery mode, where the host transfers boot images to the target over USB.
Automatic (recommended):
When you run
bootburn.pywith the-x /dev/ttyACM2option in Binding and Flashing the Target Manually, bootburn communicates with the safety MCU (sMCU) over the specified serial port to put the SoCs in recovery mode automatically. No manual steps are required for a typical first-time flash.Manual (if automatic recovery fails):
Connect to the sMCU console from the host with the following command:
minicom -D /dev/ttyACM2
Run the following commands:
tegrarecovery x1 on
tegrareset x1
Note
For details on recovery mode, USB interactions during flashing, and troubleshooting USB errors, refer to Device Recovery Mode in the Getting Started chapter of the NVIDIA DriveOS Linux SDK Developer Guide.
Binding and Flashing the Target#
After following Preparing to Bind and Flash the Target System, you can bind and flash the target manually.
Binding and Flashing the Target Manually#
You can bind and flash the target manually by performing the following steps:
To bind the target, perform the following steps inside the container:
Note
The
#command prompt in example commands indicates running the command as the root user.Change to the following directory:
# cd $NV_WORKSPACE/drive-foundation
Run the relevant following bind command, based on your board variant:
Important
For assistance determining your board variant, refer to DRIVE Platform Supported Boards.
For SKU 10 boards, run the following command:
# ./make/bind_partitions \ -b <board_variant> drive_av.linux \ -p dev_nsr \ ENABLE_THOR_U=y
Where:
-bis set to the appropriate board variant from DRIVE Platform Supported Boards.ENABLE_THOR_U=yis set.
For SKU 10/12 boards, run the following command:
# ./make/bind_partitions \ -b <board_variant> drive_av.linux \ -p dev_nsr
Where
-bis set to the appropriate board variant from DRIVE Platform Supported Boards.
Note
If the bind command fails due to the following error:
update-binfmts: exiting due to previous errors
You must manually run the following
aptsteps on the host system outside of the container to ensure the QEMU package is properly installed:$ sudo apt-get remove --purge qemu-user-static $ sudo apt-get install qemu-user-static
To flash the images, perform the following steps inside the container:
Note
When flashing a new release or when you want to do a factory reset of a board, add the bootburn
--init_persistent_partitionsoption during flashing to update the user metadata structures. This allows new data to be saved across subsequent board flashings.To remove persistent data and do a full factory reset, add the
filename=/dev/nulloption to the partition configuration, and then bind and reflash.Change to the following directory:
# cd $NV_WORKSPACE/drive-foundation/tools/flashtools/bootburn/
Run the relevant following flash command, based on your board variant:
For SKU 10 boards, run the following command:
# ./bootburn.py \ -b <board_variant> \ --board_config /drive/drive-foundation/platform-config/hardware/nvidia/platform/t264/automotive/automotive-platform-configs/p3960/<p3960-1n>/<p3960-1n-sw0x>/board_configs/<p3960-1n-sw0x>_thor_u.json \ -x /dev/ttyACM2
Where:
-bis set to the appropriate board variant from DRIVE Platform Supported Boards.--board_configspecifies the file path to specific SKU 10 configs, where<p3960-1n>and<p3960-1n-sw0x>are updated based on the appropriate board variant from DRIVE Platform Supported Boards. For example, for the p3960-10-sw03 board variant:/drive/drive-foundation/platform-config/hardware/nvidia/platform/t264/automotive/automotive-platform-configs/p3960/p3960-10/p3960-10-sw03/board_configs/p3960-10-sw03_thor_u.json
-xspecifies the MCU serial port used to put the SoCs in recovery mode automatically; refer to Putting the Target in Recovery Mode.
For SKU 10/12 boards, run the following command:
# ./bootburn.py \ -b <board_variant> \ -x /dev/ttyACM2
Where:
-bis set to the appropriate board variant from DRIVE Platform Supported Boards.-xspecifies the MCU serial port used to put the SoCs in recovery mode automatically; refer to Putting the Target in Recovery Mode.
Optional: Downloading and Installing Additional NVIDIA DriveOS Packages from NGC#
The base NVIDIA DriveOS Docker image includes the core SDK. Additional packages extend your environment with CUDA, TensorRT, DriveWorks samples, and other tools. Install only the packages relevant to your workflow.
For an overview of why these packages exist and which packages to install for common development goals (CUDA, TensorRT, DriveWorks, PVA, and profiling), refer to Working with Additional NVIDIA DriveOS Packages in the Getting Started chapter of the NVIDIA DriveOS Linux SDK Developer Guide.
Host, Cross-Compilation, and Target Placement#
Additional packages are labeled by where they must be installed:
Host — Install on the x86 host or inside the Docker container (for example,
driveos-cuda-repo-ubuntu2404-*-local_*_amd64.deb,NsightSystems-linux-drive-*-nda-*.deb).Cross — Install in the container for cross-compiling applications for the target (for example,
driveos-cuda-thor-nsr-repo-cross-aarch64-*,nv-tensorrt-repo-*-cross-*).Target — Install on the flashed DRIVE AGX board (for example,
driveos-cuda-thor-nsr-tegra-repo-*,nv-tensorrt-repo-*-target-*,cudnn-local-tegra-repo-*,NsightSystems-cli-linux-drive-*-arm64-*,driveworks-*-linux-nsr-aarch64-*.tar.gz).
The following additional NVIDIA DriveOS packages are hosted on NGC and can be downloaded to the /drive_flashing directory inside the container:
Additional Packages |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To download and install additional packages:
Start the container as described in Preparing to Bind and Flash the Target System, which mounts
/drive_flashinginto the container.Download packages from NGC by selecting the correct NVIDIA DriveOS version from the dropdown menu at https://registry.ngc.nvidia.com/orgs/drive/teams/driveos-sdk/resources/driveos_sdk_thor/files.
Tip
For more details, refer to “Downloading Resources via WGET/cURL” in the NGC Catalog User Guide.
Install packages inside the container by using the DRIVEInstaller utility:
Change to the DRIVEInstaller directory:
# cd /drive/driveinstaller
Run DRIVEInstaller with the
installinstall type and specify the package path:# ./driveinstaller --installtype install \ --pkgpath /drive_flashing/<filename>
For example:
# ./driveinstaller --installtype install \ --pkgpath /drive_flashing/driveos-cuda-repo-ubuntu2404-12-8-local_12.8.0-1_amd64.deb
Use DRIVEInstaller from inside the container for host and cross packages. For target-side packages and samples, follow the host/target deployment steps in the NVIDIA DriveOS Linux SDK Developer Guide (for example, Host/Target Setup and Configuration, and the DriveWorks Docker Container getting-started topic).
Next Steps#
After successfully completing Binding and Flashing the Target, continue to Finalizing the Installation.