Deprecations#

Note

This topic is only applicable for NVIDIA DRIVE AGX™ products.

Weston Packaging and wayland-ivi-extension#

Packaging and Distribution

Backward Compatible

Platform

OS

Deprecation of Internal Weston Packaging and wayland-ivi-extension

No

NSR

Linux

Migration Path

  • Orin to Thor

Migration Release Path

  • 7.0 to 7.2

Migration Rationale

Deprecation of Weston 6.0 internal packaging provides improved alignment with the Wayland ecosystem and access to modern compositor features. Additionally, the change supports upstream Weston versions. Customers are now responsible for installing and maintaining the Weston compositor within their environment. The platform works “as is” with standard upstream builds. As part of this transition, the wayland-ivi-extension is deprecated and removed from our distribution.

Steps to Migrate

Install Upstream Weston: Ensure your target environment has a recent version of Weston installed. Use the package manager of your distribution (such as apt) or build directly from the official Weston GitLab repository.

Wayland-IVI-Extension: The wayland-ivi-extension is no longer bundled or supported. If your application logic relies on the IVI-shell controller for window management or layout control, you must migrate to standard Wayland protocols.

Remote Sensor Fault Check Function#

QNX BSP & IO Virtualization

Backward Compatible

Platform

OS

With 7.2.1.0, TMP451( SOC) remote sensor fault check function ( i.e platform Safety monitor) is deprecated.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Rationale

TMP451( SOC) remote sensor fault check is provided as functionality under two units, and one is a duplicate of the other:

As an API under QNXBSP::NvThermmon unit from the DRIVE OS 6.5 program.

Platform Safety Monitor as an startup application since DRIVEOS 5.2 program.

Deprecating platform safety monitor reduces the need to maintain duplicate functionality. The API provided in unit QNXBSP::NvThermmon is more scalable than platform safety monitor and, unlike platform safety monitor, provides the flexibility to perform the check at startup and shutdown.

Steps to Migrate

Call Thermal_API#CheckCorrelation to perform the correlation check during startup, prior to system entering the Operational state.

1. NvThermmon_Library provides Thermal_API#CheckCorrelation interface to compare the temperature of two user-provided thermal zones and returns an error if the difference in the temperature is greater than the user-provided delta. DRIVE OS users shall call this API once during startup , prior to system entering the Operational state.

2. If the interface returns errors, handle the error based on your system design.

3. To make the check backward compatible with DRIVE OS 6.5, a check occurs between thermal zones: external thermal sensor [TDIODE_TMON], and from SoC internal sensor [Tj-Therm]. The user-provided delta can be set to 25 deg.

4. Meet all preconditions of this API prior to calling the API. Refer to the Thermal_API#CheckCorrelation interface API documentation for details

5. Error codes related to Reported ID PSM_TMON_CORR_FAILURE_RPRTR_ID (0x8100U) are deprecated.

NvThermmon Platform-Suffixed Component Names#

QNX BSP & IO Virtualization

Backward Compatible

Platform

OS

With 7.2.6.0, the platform-suffixed thermal-monitor component names io-nvthermmon_t23x, io-nvthermmon_t23x_errinj, and libnvthermmonapi_t23x.so are removed and replaced by io-nvthermmon, io-nvthermmon_errinj, and libnvthermmonapi.so.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Release Path

  • 7.2.5.0 to 7.2.6.0

Migration Rationale

The thermal-monitor driver is common to all Tegra platforms; the _t23x suffix wrongly implied an Orin (T234)-only component. The renamed components are functionally identical, and the C API is unchanged.

Steps to Migrate

Relink with -lnvthermmonapi and update any configuration referencing the old binary, library, or security-policy identity names. For details, refer to NvThermmon Component Rename: Platform Suffix Removed (io-nvthermmon, libnvthermmonapi.so).

Camera Software#

Camera SW

Backward Compatible

Platform

OS

Leopard OV2311 and Entron AR0820 camera supports were deprecated.

No

NSR

Linux, QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

In release 7.2.1.0, the SIPL libraries and files associated with the Leopard OV2311 and Entron AR0820 cameras are deprecated, as these are not planned for cameras for DOS 7.x.

Steps to Migrate

Remove the codes related to these cameras

NvDisplay - Client Modeset#

NvDisplay

Backward Compatible

Platform

OS

Client modeset feature deprecation.

No

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

Client modeset is not required for automotive use cases. Display is switching to a different architecture and codebase where the client modeset feature is not supported.

Steps to Migrate

Provide fixed-mode timings in device tree.

NvDisplay - Dynamic IMP#

NvDisplay

Backward Compatible

Platform

OS

Dynamic IMP feature deprecation

No

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

From 7.0.2.0, NvDisplay only supports driver modeset and mode changes are not allowed. NvDisplay will port over to a new codebase where dynamic IMP support is not available. Since mode changes are not required, NvDisplay will not port over unnecessary dynamic IMP changes to the new codebase.

Steps to Migrate

Configure IMP settings statically.

For additional information, refer to the NvDisplay tables in Tools and Utilities Changes and Customer-facing Configuration File Changes.

NvSplash Deprecation#

NvDisplay

Backward Compatible

Platform

OS

nvsplash deprecation

No

NSR

QNX

Migration Path

  • Xavier to Orin

Migration Rationale

From release 6.0, a splash screen application launches during start-up. The splash screen application uses the same binary as the OpenWFD sample application openwfd_nvsci_sample. By default, this application displays a bitmap image (.bmp) for 60 seconds on all connected displays.

Steps to Migrate

Stop using the nvsplash application

NvDisplay

Backward Compatible

Platform

OS

OpenWFD is deprecating Xavier-style display post-flip fence behavior. WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX attribute macro will be removed from the OpenWFD extensions header wfdext.h.

No

NSR

Linux

Migration Path

  • Orin to Thor

Migration Rationale

OpenWFD driver introduced this attribute in DRIVE OS 6.0 to emulate Xavier style display post-flip fences to avoid application changes and to give time for applications to change.

The attribute is being deprecated now because:

Client applications should use the Orin-style post-flip fences to provide a faster and efficient path for tracking flips.

Xavier is not supported on DRIVE OS 6.0 or 7.0 and, therefore, the start of DriveOS 7.0 is the appropriate time to deprecate legacy behavior support.

This simplifies the OpenWFD driver code.

Steps to Migrate

OpenWFD driver introduced this attribute in DRIVE OS 6.0 to provide backward compatibility to DRIVE OS 5.2 applications that used OpenWFD non-blocking flip extension APIs.

In Xavier, the display post-flip fences signal at the beginning of scan out, whereas in Orin the display post-flip fences signal at end of scan out. To avoid application changes and to give time for applications to change, OpenWFD added WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX attribute to enable applications to emulate the Xavier style display post-fence behavior on Orin.

If a client application is using Xavier style post-flip fence behavior, then it should switch to Orin style post-flip fences.

If a client application is using Orin style post-flip fence behavior but using WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX attribute in the code then remove this macro from the code.

If a client application is using Orin style post-flip fence behavior and not using WFD_PIPELINE_POSTFENCE_SCANOUT_BEGIN_NVX attribute in the code, then there is no impact.

OpenWFD updates openwfd_nvsci_sample app to demonstrate how to use Orin-style post-flip fence behavior.

Graphics#

NvDisplay

Backward Compatible

Platform

OS

wfdDeviceSetSafeStateNV API is deprecated.

No

NSR

SR

QNX

Migration Path

  • Orin to Thor

  • Orin to Orin

Migration Rationale

In Drive OS 7.X, clients will directly use GPIO pins or devctl to transition the display to a safe state.

Additionally, since the serializer does not support the safe state, the OpenWFD APIs becomes NoOp if the interface is retained. This applies to all SCL parts in Thor and Orin.

As a result, support for this function is no longer required in the OpenWFD driver.

Steps to Migrate

The clients using wfdDeviceSetSafeStateNV should remove the API because using it will cause compilation errors. Instead, to transition the display to safe state, the clients should program GPIO pins directly. More details on this are provided separately by NvDisplay.

Graphics

Backward Compatible

Platform

OS

X11/Weston/Wayland/XWayland, OpenGLES and Vulkan have been moved to the development profile.

Yes

NSR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

This packaging change improves clarity regarding the intended use of these components. These components, previously included in the QNX Standard and Linux Standard releases, are included with DriveOS solely for use in the development of graphics applications and are not intended for production deployment.

Steps to Migrate

To continue using these components for development, ensure the corresponding packages are installed prior to use.

Users are encouraged to migrate to Vulkan SC and OpenWFD; these components are intended for use in both production and development deployments

NvSci#

NvSci

Backward Compatible

Platform

OS

The following APIs are deprecated. They are supported in 7.0 for backward compatibility but will be completely removed:

NvSciStreamProducerCreate NvSciStreamConsumerCreate

NvSciStreamIpcSrcCreate NvSciStreamIpcDstCreate

Yes

NSR, SR

Linux & QNX

Migration Path

  • Orin to Thor

Migration Rationale

The newer version of these APIs are already available from 6.0, such as NvSciStreamProducerCreate2, NvSciStreamConsumerCreate2, NvSciStreamIpcSrcCreate2, and NvSciStreamIpcDstCreate2, which can provide the same functionality as the deprecated APIs and much more. The customers should to move to these newer versions of APIs before the end of support.

Steps to Migrate

Note

The function signatures of newer API versions are in the API Reference; they were released in 6.0.

  NvSciStreamProducerCreate:

NvSciError NvSciStreamProducerCreate(

NvSciStreamBlock const pool,

NvSciStreamBlock \*const producer

);

NvSciError NvSciStreamProducerCreate2(

NvSciStreamBlock const pool,

bool const crcValidate,

NvSciStreamBlock \*const producer

);

Passing param crcValidate as false in
NvSciStreamProducerCreate2 is equivalent to
NvSciStreamProducerCreate.

NvSciStreamConsumerCreate:

NvSciError NvSciStreamConsumerCreate(

NvSciStreamBlock const queue,

NvSciStreamBlock \*const consumer

);

NvSciError NvSciStreamConsumerCreate2(

NvSciStreamBlock const queue,

bool const crcValidate,

:NvSciStreamBlock \*const consumer

:);

Passing param crcValidate as false in
NvSciStreamConsumerCreate2 is equivalent to
NvSciStreamConsumerCreate.

NvSciStreamIpcSrcCreate:

NvSciError NvSciStreamIpcSrcCreate(

NvSciIpcEndpoint const ipcEndpoint,

NvSciSyncModule const syncModule,

NvSciBufModule const bufModule,

NvSciStreamBlock \*const ipc

);

NvSciError NvSciStreamIpcSrcCreate2(

NvSciIpcEndpoint const ipcEndpoint,

NvSciSyncModule const syncModule,

NvSciBufModule const bufModule,

NvSciStreamBlock const queue,

NvSciStreamBlock \*const ipc

);

Passing the param queue as 0 (invalid) in
NvSciStreamIpcSrcCreate2 is equivalent to
NvSciStreamIpcSrcCreate.

NvSciStreamIpcDstCreate:

NvSciError NvSciStreamIpcDstCreate(

NvSciIpcEndpoint const ipcEndpoint,

NvSciSyncModule const syncModule,

NvSciBufModule const bufModule,

NvSciStreamBlock \*const ipc

);

NvSciError NvSciStreamIpcDstCreate2(

NvSciIpcEndpoint const ipcEndpoint,

NvSciSyncModule const syncModule,

NvSciBufModule const bufModule,

:NvSciStreamBlock const pool,

NvSciStreamBlock \*const ipc

:);

Passing the param pool as 0 (invalid) in NvSciStreamIpcDstCreate2 is equivalent to NvSciStreamIpcDstCreate.

Video Interlace Compositor#

Video Interlace Compositor (VIC) Changes

Backward Compatible

Platform

OS

The following APIs will be removed:

NvMedia2DGetVersion()

NvMediaLdcGetVersion()

VicDiagnosticsGetVersion()

Yes

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

There is no use case for these functions.

Steps to Migrate

Remove these functions from your code.

NvMediaLDC

NvMediaLDC was deprecated in DriveOS 7.0.1 and is removed in DriveOS 7.0.2 and later, including DriveOS 7.2.x SDKs. The old nvmedia_ldc.h, nvmedia_ldc_sci.h, and nvmedia_ldc_util.h headers are not shipped, and libnvmedialdc is not available for linking. Applications that still include these headers or link with -lnvmedialdc fail to compile or link.

Port LDC, TNR, and related NvSciSync/NvSciBuf usage to NvMedia2D. See Multimedia Changes for the NvMediaLDC to NvMedia2D migration table and example code.

DLA

DriveOS 7.0 will continue to support the NVIDIA Deep Learning Accelerator (DLA) cores on Orin. These DLA cores were removed from Thor to optimize GPU scheduling and increase flexibility.

For Safety, the compute stack ASIL level will be raised to achieve the decomposition for use cases that were dependent on decomposition across GPU and DLA for diversity, to avoid single point of failure scenarios. For Thor, additional ASIL decomposition diagrams and increased systematic ASIL will support these ASIL decomposition use cases.

Networking - DEVCTL and ETHER#

Networking

Backward Compatible

Platform

OS
The following are deprecated for the networking element:

  • DEVCTL_NVETHMGR_GET_AVB_PERF

  • DEVCTL_NVETHMGR_VERIFY_TS

  • DEVCTL_NVETHMGR_GET_STATUS

  • ETHER_GET_AVB_ALGORITHM

No

NSR

LINUX

Migration Path

  • Thor to Thor

Release Path

  • 7.2.3.0 to 7.2.4.0

Migration Rationale

Legacy IOCTLs are removed. Only use supported IOCTLs

Steps to Migrate

  • Use ETHER_GET_AVB_PERF instead of DEVCTL_NVETHMGR_GET_AVB_PERF. Note that the enum value is the same for both.

  • Use ETHER_VERIFY_TS instead of DEVCTL_NVETHMGR_VERIFY_TS. Note that the enum value is the same for both.

  • Use ETHER_GET_STATUS instead of DEVCTL_NVETHMGR_GET_STATUS. Note that the enum value is the same for both.

  • ETHER_GET_AVB_ALGORITHM is deprecated due to lack of hardware support in Thor.

Networking - io-pkt, dhclient, nicinfo, ping6, ptpd-avb#

Networking

Backward Compatible

Platform

OS
The following are deprecated for the networking element:

  • Networking stack io-pkt

  • dhclient

  • nicinfo

  • ping6

  • ptpd-avb

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

A new networking stack, called io-sock, is used with the new Muon Kernel of SDP8.0, which is available with DOS7.2

Steps to Migrate

  • DOS7.2 proivdes the new Networking stack called io-sock.

  • The io-sock stack also provides dhcpcd daemon instead of dhclient.

  • The netstats utility is used to get the MAC/DMA stats.

  • The ping -6 option is used instead of ping6.

  • ptpd2 is used instead of ptpd-avb.

Networking - ETHER_IOCTL_NVSOCKET_STATS#

Networking

Backward Compatible

Platform

OS

The ETHER_IOCTL_NVSOCKET_STATS is removed from nvethernet_export.h in release 7.2.4.0.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 7.0 to 7.2

Migration Rationale

NvSocket statistics retrieval through the NvEthernet driver is removed. NvSocket statistics are now available through the NvSocket API directly.

Steps to Migrate

Applications using ETHER_IOCTL_NVSOCKET_STATS (0x1016U) must stop using this IOCTL immediately.

Networking - ETHER_IOCTL_DP_STATS and ETHER_FILTER_CACHE_DUMP#

Networking

Backward Compatible

Platform

OS

The IOCTL commands ETHER_IOCTL_DP_STATS (0x1018U) and ETHER_FILTER_CACHE_DUMP (0x1016U), along with their associated structures ether_dp_stats_t and struct ether_filter_dump, are removed from the public header nvethernet_export.h and moved to internal driver headers in release 7.2.4.0. The corresponding command handling has been removed from the customer sample application nvethernet_sample and moved to the internal test tool ether_devtest. All related code is now guarded under the ETHER_DP_DEBUG build flag, which is disabled by default.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 7.2.3.0 to 7.2.4.0

Migration Rationale

These IOCTLs are used exclusively for internal data path performance profiling and debugging. They are not enabled in production builds and should not be exposed through the public export header.

Steps to Migrate

No action required. The dp_stats and dump_filter_cache commands were internal debug features not intended for customer use. Customers using the sample application as a reference can safely remove any usage of ETHER_IOCTL_DP_STATS, ETHER_FILTER_CACHE_DUMP, ether_dp_stats_t, and struct ether_filter_dump from their applications.

NvSocket - NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS#

NvSocket

Backward Compatible

Platform

OS

Removal of NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS pulse code from nvsocket_export.h in release 7.2.4.0.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

The NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS pulse code is removed from the NvSocket pulse state enumeration in release 7.2.4.0. This was an internal pulse used by NvSocket for cleanup. NvSocket now uses an alternative approach to automatically cleanup clients.

Steps to Migrate

No action required. This pulse code was for internal NvSocket usage only.

NvSocket - nvsocket_server_cfg_t#

NvSocket

Backward Compatible

Platform

OS

Internalization of nvsocket_server_cfg_t structure (removed from public API in nvsocket_export.h) in release 7.2.4.0.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

The nvsocket_server_cfg_t structure was used internally by NvSocket and has been moved out of the public header. This change simplifies the public API.

Steps to Migrate

No action required. This structure was for internal NvSocket usage only.

Audio Deprecations#

  • AVB-related audio files that shipped in 6.x are no longer distributed in 7.2 SDK images or target filesystems. For migration details, refer to AVB Audio Sample Applications.

  • The nvmixerctrl tool and libnvmixerctrl library are deprecated.

Target Changes

Backward Compatible

Platform

OS

The nvmixerctrl tool and libnvmixerctrl library are deprecated and removed from DriveOS 7.2.

No

NSR

QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

The nvmixerctrl tool and libnvmixerctrl library are general-purpose audio mixer control utilities that have been deprecated in DriveOS 7.2. The ALSA amixer tool provides equivalent functionality and is the standard tool for audio mixer control in DriveOS 7.2.

Steps to Migrate

For the ``audio/nvmixer_ctrl`` sample:

The audio/nvmixer_ctrl sample that links against libnvmixerctrl will fail to build in DriveOS 7.2.4.0 and later versions. To migrate:

  1. Remove the dependency on libnvmixerctrl from the sample’s Makefile (remove -lnvmixerctrl from linker flags).

  2. Replace nvmixerctrl API calls with equivalent amixer command-line invocations or use the ALSA library API directly.

  3. For QNX, use amixer commands to configure audio controls. For example:

    amixer -c 0 cset name="I2S2 Mux" "ADMAIF1"

  4. Refer to the audio documentation for ALSA amixer usage examples and available controls. The control names and configurations may differ from the previous nvmixerctrl implementation.

For applications using ``nvmixerctrl``:

Replace all nvmixerctrl tool invocations with equivalent amixer commands. The amixer tool provides similar functionality for setting and getting audio mixer control values.

AVB Audio Sample Applications#

Target Changes

Backward Compatible

Platform

OS

AVB-related audio sample applications and files that shipped in DriveOS 6.x and 7.0, including nvavb/test_utils/crf, nvavb/test_utils/aaf, and nvavb/test_utils/audio, are not distributed in DriveOS 7.2 SDK images or target filesystems.

No

NSR

Linux

Migration Path

  • Orin to Thor

  • Orin to Orin

  • Thor to Thor

Migration Release Path

  • 6.x to 7.2

  • 7.0 to 7.2

Migration Rationale

AVB audio use cases are not planned for DriveOS 7.x. The removed sample applications depend on ALSA development headers and libasound from the SDK sysroot, which are not distributed with the DriveOS 7.2 Linux NSR SDK.

Steps to Migrate

Do not migrate or build the removed AVB audio sample applications on DriveOS 7.2. Use only the AVB samples and daemons distributed in the DriveOS 7.2 SDK.

If a custom application still depends on ALSA APIs such as alsa/asoundlib.h or links with -lasound, provide the required ALSA development headers and libraries in the application build sysroot and update the application makefile include and library paths accordingly.

Security Services - NVVSE IVC Configuration DT Format#

Security Services

Backward Compatible

Platform

OS

The packed integer-array form of the NVVSE ivccfg device-tree property is deprecated. NVVSE IVC channels are now described by named per-channel nodes under nvvse-ivccfgdb and referenced by phandle (ivccfg on QNX, nvidia,ivccfg on Linux) in support of the pluggable (engine abstraction) architecture.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 7.0 to 7.2

Migration Rationale

The index-based tuple layout was position-dependent and could not be extended without changing the fixed tuple width. The phandle-referenced per-node format is self-describing and allows per-channel attributes to evolve independently per SoC.

Steps to Migrate

Regenerate any NVVSE IVC device-tree configuration in the per-node format. See HPSE Drivers - NVVSE Changes for the complete migration steps and examples, and “DT Configuration for VSE Driver” in the NVIDIA DriveOS SDK Developer Guide for the property reference.