Tools and Utilities Changes#

This section covers target changes such as DevTools and Flashing. The basic tools and utilities changes are documented in the following sections.

  • SDK and PDK merge is described in the “Product Changes” section.

  • Docker distribution via Artifactory is captured in the “Packaging and Distribution” section

  • Tar archive packages are signed by NVIDIA, and public key is included in container

  • NSR/SR product naming changes are documented in the “Product Changes” section.

QNX BSP and IO Virtualization#

Target Changes

Backward Compatible

Platform

OS

NvLog server moved to the HVRTOS process in 7.2.2.0. With the new architecture, the steps to retrieve logs from storage changed.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

The rearchitecture for NvLog server moved to the HVRTOS process to support new features and improve security handling

Steps to Migrate

Refer to the NVIDIA DriveOS SDK documentation

NvDisplay#

Target Changes

Backward Compatible

Platform

OS

New tool to calculate static IMP settings - LAPTSA IMP (laptsa-imp)

No

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

In 7.0.1.0, NvDisplay supported dynamic IMP and users did not have to feed IMP values explicitly to the driver.

From 7.0.2.0, NvDisplay will switch to static IMP and users are required to calculate the static-imp values, according to their use case, using the LAPTSA IMP tool and populate “static-imp-data” Device Tree Node.

(For additional information, see changes to NvDisplay Tool changes to use LAPTSA IMP tool)

Steps to Migrate

  1. Use laptsa-imp host side tool to generate static IMP DT fragment.

  2. Add this fragment to the NvDisplay DCE device tree.

HDE - GCC Toolchain#

Target Changes

Backward Compatible

Platform

OS

GCC toolchain upgrade from 9.3 to 13.2.

Yes

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

Host system Ubuntu 24.04 has 13.2 as the default toolchain version.

Steps to Migrate

Toolchains are installed in host container under $NW_WORKSPACE/toolchain. The following are available:

aarch64–glibc–bleeding-edge-2024.02-1

armv5-eabi–glibc–bleeding-edge-2024.02-1

armv7-eabihf–glibc–bleeding-edge-2024.02-1

HDE - Toolchain 13.2#

Target Changes

Backward Compatible

Platform

OS

Toolchain 13.2 migration upgrade from C++ to version 17

Yes

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

For alignment with QNX 8, which is also moving to C++17.

Steps to Migrate

Note that embedded Linux component built in GVS migrated to C++17 and samples are updated from to C++ to version 17 as well.

Flashing Tools Changes#

Target Changes

Backward Compatible

Platform

OS

  1. Fuse blob generation

  2. Command line chipID update.

  3. Public key hash change from 1 key to 16keys max, the OEM can choose.

Yes

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

Updated to support Thor.

Steps to Migrate

  1. Overview: Same command with applicable chip Id (Orin or Thor)

  2. No change in fuse burn steps for Orin. For Thor, select up to 16 keys.

Flashing Tools Changes - Customer Data#

Target Changes

Backward Compatible

Platform

OS

Customer data format in BCT

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

In 7.2.x.x moving data to the signed section of the customer data for greater security.

Steps to Migrate

Customer data must be ported from 6.x signed_customer_data and unsigned_customer_data JSON files must be ported to the updated format JSON files in 7.0

HDE Changes#

Target Changes

Backward Compatible

Platform

OS

Starting with 7.0.2.1 in DriveOS 7.x, SDK and PDK merged as SDK and we are publishing SDK Docker only. Any additional restricted artifacts are provided via NVIDIA NVONLINE. DriveOS packages used in Dockers are now built as a tar bundle archive instead of a Debian package. Compute stack remains to Debian packages.

No. Debians are deprecated. Distribution mechanism of Dockers changed from NGC to Artifactory.

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

For the advantages of using Artifactory over NGC:

  • No requirement to sign up for a separate NGC account.

  • Publishers no longer must create and manage NGC orgs and publish content separately.

  • Customers use the API key directly from partners.nvidia.com

  • Simplified customer workflow

Steps to Migrate

Refer to the NVIDIA DriveOS 7.0 Installation Guide.

New Tools for Storage Configuration#

Target Changes

Backward Compatible

Platform

OS

New tools to configure Storage Configuration for DRIVEOS 7.x

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

Until 7.0.1.0, the storage configuration for DriveOS was CFG format-based.

7.0.2.0 adds a new workflow for storage configuration in the “CUE” file format. CUE files are eventually converted to CFG files using a set of tools. The new workflow is documented in the NVIDIA DriveOS Developer Guide SDK and is disabled by default for now.

Steps to Migrate

  1. Enable the new CUE workflow by setting the profile makefile flag: ENABLE_CUE_SUPPORT_STORAGE_CONFIG = y

  2. Migrate existing storage configuration modifications from CFG format to the new CUE file format.

  3. Refer to the SDK Developer Guide chapter “NVIDIA DRIVE AV Storage Configuration via CUE” for detailed implementation instructions.

New Tools for the QNX Startup Sequence#

Target Changes

Backward Compatible

Platform

OS

New tools to configure Startup Sequence for DRIVEOS 7.x QNX

No

NSR

QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

Until 7.0.1.0, the startup sequence for DriveOS was hard coded in a start_seq single DT property which was hard to update and modify by customers.

From 7.0.2.0, a new workflow for startup sequence in “CUE” file format is added. These CUE files consists of atomic process dependency. The startup sequencer tool consumes these files and generates the final startup sequence, which the startup sequence manager then uses. The new workflow is documented in the NVIDIA DriveOS Developer Guide and is disabled by default for now.

Steps to Migrate

  1. Invoke the startup sequence new workflow through bind cmdline option “–qnx_startup_seq_gen” to generate the startup sequence.

  2. Create new process_information CUE input files required for the new workflow.

  3. Refer to the SDK Developer Guide chapter “NVIDIA DRIVE AV Startup Sequence Configuration via CUE” for detailed implementation instructions.