DRIVE Update Changes#

BRBCT Marker-based Boot Chain Selection#

Target Changes

Backward Compatible

Platform

OS

The BRBCT marker-based boot chain selection is removed in Thor

No

NSR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

Due to changes to Thor BootROM, we only have sequential boot chain selection or GPIO-based boot chain selection now.

Steps to Migrate

Migrate to GPIO-based boot chain selection. This has been the default option for Orin

DRIVE Update Router Parent Path#

Target Changes

Backward Compatible

Platform

OS

The DRIVE Update router parent path will change from “/gos-a/ to “/”

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

In DRIVE Update 7.0, Update VM was removed, resulting in only having “/gos-a” for Guest OS Tegra A. The DRIVE Update Router, however, will look for upper level “/”. This may create issues for the router.

To reduce this potential risk, in DRIVE Update 7.0, for all units in Guest OS Tegra A, the router parent path will change from “/gos-a” to “/”.

Steps to Migrate

Refer to the NVIDIA DriveOS 7.0 Installation Guide.

dupkg Templates#

Target Changes

Backward Compatible

Platform

OS

Changes to the following dupkg templates:

  • dupkg_dudelta_pull_template

  • dupkg_dudiff_template

Yes

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

Implemented a better solution for the delta update in 6.5.2.0, which changes the delta generation flow.

Steps to Migrate

The new delta solution template generates all necessary packages/scripts to complete a delta update to a new version. There is no need to manually handle special partitions.

The previous delta generation dupkg command line is:

python3 dupkg.py gen –template dupkg_dudelta_pull_template –in VALIDATE_OPTION=True TEGRA_A_SRC_OLD=<old bsp> TEGRA_A_SRC_NEW=<new bsp> –out outdir

The new delta generation dupkg command line is:

python3 dupkg.py gen –in BSDIFF_PATH=./ TEGRA_A_SRC_OLD=<old bsp> TEGRA_A_SRC_NEW=<new bsp> VALIDATE_OPTION=True –template dupkg_dudiff_template –out outdir.

The Drive Update Workflow with DUCC#

Target Changes

Backward Compatible

Platform

OS

The Drive Update workflow with DUCC is deprecated in 7.0

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

A new API is being introduced to provide better control over the update sequence

Steps to Migrate

There is no functionality and no need to migrate. Drive OS 6.0 existing DUCC interface are supported through the Drive OS 7.x release. Customers do not need to change if they still use the current DUCC interface.

In Drive OS 7.x, NVIDIA Drive® Update will provide the Update Server API (based on HVRTOS) to customers, who should use the Update Server API directly instead of the DUCC interface if it improves software performance.

The new API will be provided in the SDK once it is ready and available.

CMD_GET_PT_LOG#

Target Changes

Backward Compatible

Platform

OS

CMD_GET_PT_LOG is removed

No

NSR

Linux

Migration Path

  • Thor to Thor

  • Orin to Orin

Migration Release Path

Between 7.x releases

Migration Rationale

CMD_GET_PT_LOG is for debug only and it is removed from interface file in release 7.0.4.0.

Steps to Migrate

CMD_GET_PT_LOG feature is supported by CMD_GET_PARTS_INFO together. Modify code using CMD_GET_PT_LOG to use CMD_GET_PARTS_INFO. Refer to du_cli.c source code for additional information.

DRIVE Update Server (DUS) Client API#

Warning

The DUS Client API is mutually exclusive with the Guest OS DRIVE Update plug-ins. With the default build flag ENABLE_GUEST_OS_DU_APP=y, the Guest OS dutii unit already owns the nvdriveupdate_ivc_1 IVC channel (predefined UID 2433), and a customer application calling duscInit() will fail immediately with DUSCLIENT_ERROR_OPEN_ENDPOINT_FAILED / DUSCLIENT_ERROR_INITIALIZE_FAILED. The error code alone is not self-explanatory; this mutual-exclusion relationship must be resolved before customer applications can call duscInit() successfully.

Target Changes

Backward Compatible

Platform

OS

New public header dus-client/dus_client.h is added. It declares the DUS (DRIVE Update Server) client API. Maturity is marked Experimental:

  • The DUSCLIENT_ERROR uint32_t return-code type and the DUSCLIENT_NO_ERROR / DUSCLIENT_ERROR_* family, covering argument-invalid, not-initialized, NvSciIpc lifecycle errors (CREATE_LOOPEVENT_FAILED, INITIALIZE_FAILED, OPEN_ENDPOINT_FAILED, GET_EVENT_NOTIFIER_FAILED, GET_ENDPOINT_INFO_FAILED, RESET_ENDPOINT_FAILED, GET_EVENT_FAILED, WAIT_EVENT_FAILED, READ_IVC_QUEUE_FAILED / WRITE_IVC_QUEUE_FAILED, CLOSE_ENDPOINT_FAILED), mempool errors (RESERVE_FAILED, MMAP_FAILED, TOO_SMALL, HEADER_INVALID, UNRESERVE_FAILED), payload-header errors, and IVC command errors.

  • The C functions duscInit, duscDeinit, and duscExecute(cmd, targetBootchain, pPayload, payloadLen, pBuf, pBufLen).

Yes

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Provides a client interface to the DRIVE Update Server (DUS) running in HVRTOS, which replaces the legacy DUCC interface from 7.x onward.

Enabling the DUS Client Interface disables all DRIVE Update plug-ins in the Guest OS at compile time and allows direct communication with the DRIVE Update Server in HVRTOS. As a result, security mechanisms previously enforced by the Guest OS DRIVE Update stack (update-package authenticate and validate, vehicle status and action such as runlevel and reboot, and so on) shall be executed by the customer.

Per ARR DOS_UREQ_3113: The user of DriveOS shall ensure that the DRIVE Update Server (DUS) Client Interface is used in accordance with the guidelines provided in dus_common_data.h and dus_client.h , and that all security mechanisms are correctly implemented and executed.

Refer to the “Update Mechanism” and “DUS Client HOWTO” sections of the “DRIVE Update V3” chapter for correct usage on both Linux and QNX. The API is currently Experimental and may change between releases.

Steps to Migrate

  1. QNX-safety processes that need to talk to the DRIVE Update server over IVC + mempool should include dus-client/dus_client.h and wrap their command exchange between duscInit and duscDeinit:

    #include "dus-client/dus_client.h"

if (duscInit() != DUSCLIENT_NO_ERROR) {
    return -1;
}

uint8_t  payload[64] = { /* ... command-specific payload ... */ };
uint8_t  resp[256];
uint32_t respLen = sizeof(resp);

DUSCLIENT_ERROR rc = duscExecute(
    /* cmd             */ MY_DUS_CMD_ID,
    /* targetBootchain */ 0U,
    /* pPayload        */ payload,
    /* payloadLen      */ (uint32_t)sizeof(payload),
    /* pBuf            */ resp,
    /* pBufLen         */ &respLen);

if (rc != DUSCLIENT_NO_ERROR) {
    (void)duscDeinit();
    return -1;
}

(void)duscDeinit();

  2. Replace the predefined UID 2433 on the nvdriveupdate_ivc_1 IVC channel (currently used by the Guest OS dutii unit) with the customer application’s own UID. This is required for any customer application built against dus_client; otherwise the IVC channel ownership conflict raised in the warning above prevents duscInit() from succeeding.

  3. Treat the surface as experimental: pin to a specific DriveOS release while integrating, and re-validate against each new SDK drop until the API is promoted to production.