DriveOS Configuration - Overview and Planned Changes#
Note
Configurations for Dimensity CX-1 platforms is a joint collaboration between NVIDIA partners and customers.
DriveOS employs a data-driven methodology, where the software is distinct from the configuration data that dictates its functionality on different platforms or use cases.
This section provides the following information:
An overview of DriveOS configuration data
Limitations with the current approach
Planned improvements to address these limitations
A roadmap for customer-impacting changes
Note
This chapter covers most DriveOS configuration data that customers may need to modify for their specific platforms or use cases. However, some configuration planes (such as camera sensor configuration) are not covered. As a long-term strategy, DriveOS will continue reviewing additional configuration areas for potential improvements.
Overview#
DriveOS configuration data is organized into units called “configuration planes,” with each configuring specific logical functions within DriveOS. In source form, configuration planes typically consist of hierarchically (example: chip->SoC->platform-common->platform) arranged files using a particular file/data format. During the DriveOS build process, the files corresponding to each configuration plane are compiled into a single binary unit.
The following table lists the major configuration planes in DriveOS, organized roughly in boot sequence order:
Configuration Plane |
Description |
Format |
Example |
|---|---|---|---|
BCT (Boot Configuration Table) |
Consumed early during boot phase by different bootloaders. Contains settings such as Golden Register, Pinmux, PMIC, GPIO, padctl, and memory configuration. |
Open Firmware Device Tree |
|
BPMP FW |
Consumed by BPMP firmware during early boot phase. Contains settings related to peripheral clocks and power domains. |
Open Firmware Device Tree |
|
PCT (Platform Configuration Table) |
Consumed by the DriveOS hypervisor to configure the virtualization system. Includes VM creation, memory pools, inter-VM communication (IVCs), and peripheral assignment for VMs. |
C language header files (.h) |
|
Guest VM and Foundation Server |
DriveOS consists of one or more Guest VMs and multiple Foundation Servers, each configured independently as a separate configuration plane. |
Open Firmware Device Tree |
|
Guest VM Startup, File Information and Security |
Defines the operational configuration for Guest VMs, including:
|
YAML, Open Firmware Device Tree, and txt |
|
Storage |
Configures persistent storage for the system, including storage devices, attributes, partition tables, partition sizes, access permissions, and partition images. |
INI format |
|
PCT Profile Makefiles |
Controls conditional compilation and token substitution for PCT, Guest VM, Foundation Server, and Storage configuration planes. Multiple profiles exist for different DriveOS and customer use cases. |
Makefiles (.mk) |
|
Current Limitations#
The current DriveOS configuration approach presents several challenges that impact both NVIDIA internal development and customer workflows. These limitations span across the areas of configuration ownership, file organization, format consistency, and maintenance processes.
Unclear Configuration Ownership#
Configuration parameter ownership between NVIDIA internal (core) and customer-modifiable (and thus owned) parameters is not well-defined, resulting in backward compatibility problems. DriveOS needs to evolve (implying changes), but customers need backward-compatible parameters to easily migrate across releases.
File Organization and Accessibility#
Configuration files (within a configuration plane as well as across multiple configuration planes) are spread across different directories and paths, with no single unified view per platform
Inconsistent organization: some configuration planes have platform-specific folders, others do not
Deep device tree file hierarchies make it difficult to locate parameters needing modification. For example, a leaf device tree file may include multiple SoC, platform, clock, and IO-specific device tree files
File organization lacks clear indication of customer ownership and customizability. Which files customers can modify is not obvious from the file structure; this information is scattered across different parts of DriveOS documentation. Typically customers end up needing to modify files that DriveOS modifies heavily across releases
Inconsistent Configuration Formats#
Different configuration formats (device trees, CFG files, YAML, C headers) result in inconsistent workflows and tooling support across configuration planes
- Current configuration file formats are not developer/automation-friendly:
Storage configuration uses custom INI format
PCT uses C headers
Limited off-the-shelf tooling support
Difficult to develop GUI tools for configuration management
Multiple file formats increase time and complexity for platform adaptations
High Migration and Maintenance Effort#
- The ability of customers to extend DriveOS configuration and maintain it in a migration-friendly way is limited. Customers must manually patch and rebase DriveOS configuration with every release, resulting in high migration effort:
Customers need to edit DriveOS-provided files for customization instead of creating their own “overlay” files that can tweak specific parameters
Parameters are often not atomic, requiring customers to copy/rewrite parameters containing large amounts of configuration data. Example: Startup sequence and launch arguments are maintained as a single device-tree node
Difficult to identify configuration file changes between releases.
Manual effort is required to rebase configuration files due to upstream changes from NVIDIA.
Complex Makefiles sometimes require manual updates during platform porting.
Limited Validation and Error Detection#
Limited validation capabilities make it easy to introduce configuration bugs
No inherent verification mechanism or plausibility checks to detect incorrect configurations during file setup
Very few validation checks are currently implemented, resulting in low confidence in BSP configurations
Inter-dependencies among configuration files are statically coded without automation, often resulting in inconsistent configuration across different DriveOS components and hard-to-debug runtime errors. Example: Power gating a hardware IP in the BPMP FW device tree but not marking it as unassigned in PCT and guest device trees leads to runtime crashes
Lack of Automation#
Many derivable configuration settings require manual specification instead of being auto-generated. Example: IVC and mempool numbers must be manually synchronized between PCT and device tree files
Inter-dependencies among configuration files are statically coded without automation support, leading to manual maintenance burden
Planned Improvements#
Common Approach for All Configuration Planes#
File Organization and Separation
- Each configuration plane will have separate customer-specific and DriveOS core files
These files compile together to fully define the configuration plane
All customer-configurable parameters are explicitly defined (or set) in customer files
Customer-configurable parameters are treated as public interfaces with backward compatibility guarantees
DriveOS protects these parameters against undocumented changes
Changes to public parameters are announced through migration guide updates
- DriveOS reference platforms follow the same pattern as customer platforms
All customer configurable parameters are explicitly set in (reference) platform-specific files
This provides clear visibility into which configuration parameters are owned by customers
- For customer platform development:
Customers should clone a reference platform and customize the cloned files
Avoid modifying DriveOS reference platform files directly
Board cloning tool available from DriveOS 7.2.3.0 to automate this process
File Format Standardization
- Migrate configuration data formats to support:
Clear DriveOS core vs. customer separation
Automation and validation capabilities
Better user experience through consistent tooling
- Target formats: CUE and device-tree as primary standards
PCT: C header files → device-tree
Storage: INI → CUE
Startup configuration: device-tree and others → CUE
File system configuration: YAML → CUE
Platform-related configuration files consolidated under platform directories for better visibility
Automation and Tooling
- Auto-generate error-prone and manually intensive configuration data:
Guest VM startup sequences
Process dependencies for security configuration
Memory pools and IVCs for storage configuration
- Enhanced use-case-based tooling:
High-level use cases that affect multiple configuration planes
Simplified configuration through single, cohesive interfaces
Long-term Goal
Customers should only need to modify customer-specific files without touching DriveOS internal files (including build files or makefiles).
Note
Some improvements may take multiple iterations to achieve the long-term goal, but this section should reflect the overall strategy DriveOS is adopting.
Configuration Plane Specific Changes and Roadmap#
This section summarizes configuration plane-specific changes and provides a release roadmap for customer-impacting updates.
Note
Unless specifically noted, each row applies to all combinations of Linux/QNX and SR/NSR variants.
Configuration Planes |
Legacy file format |
Proposed file format |
Release |
Changes to the configuration plane |
Reference documentation |
Customer impact roadmap |
|---|---|---|---|---|---|---|
BCT, Guest VM, Foundation Servers, BPMP |
device-tree |
<no change> |
7.2.3.0 |
Customer vs. DriveOS core separation for BCT, Guest VM and Foundation Servers for Thor. DriveOS provides:
The customer is responsible for:
Support for Orin SOC will be added in future releases. |
DriveOS dev-guide chapter “Directory Structure for Platform Configuration Files” |
Customers need to rebase all their overlays based on new layout for BCT, Guest VM and Foundation Server DTs for Thor SOC. Adapt the new workflow of copying reference platform config for their customer platforms. |
7.2.4.0 |
Customer vs. DriveOS core separation for BPMP for Thor SOC. |
DriveOS dev-guide chapter “Directory Structure for Platform Configuration Files” |
Customers need to rebase all their overlays based on new layout for BPMP DTs for Thor SOC. |
|||
TBD |
Customer vs. DriveOS core separation for Orin SOC. |
DriveOS developer guide chapter “Directory Structure for Platform Configuration Files” |
Customers need to rebase all overlays based on new layout for Orin SOC. |
|||
QNX Guest VM Startup, File Information and Security |
YAML, Open Firmware Device Tree and txt |
CUE |
7.2.3.0 |
Tool not yet available |
DriveOS dev-guide chapter TBD |
Planned for future release |
YAML, Open Firmware Device Tree and txt |
CUE |
7.2.4.0 |
Tool available for early access. The framework is not yet fully integrated into the production build pipeline. |
DriveOS dev-guide chapter DriveOS “QNX Startup & Security Configuration” |
Planned for future release |
|
7.2.5.0 |
Customer vs. DriveOS core separation for Thor_QNX_SR and Thor_QNX_NSR. DriveOS provides:
The customer is responsible for adding and maintaining support for customer platform:
Default workflow uses CUE format |
DriveOS dev-guide chapter “DriveOS QNX Startup & Security Configuration” |
Customers have to migrate their startup and security related customizations to create CUE configuration file for customer owned process and files with process args, ioaluncher args, library and file dependencies and security config Provide customization of Customer Configurable part of DOS process and files for in CUE. |
|||
TBD |
Extend Tooling support for Orin PCTs |
DriveOS dev-guide chapter “DriveOS QNX Startup & Security Configuration” |
Migrate relevant customer configurations to CUE format for Orin PCTs. |
|||
PCT |
C language header files |
CUE |
7.2.3.0/ 7.2.4.0 |
No Planned Changes |
DriveOS dev-guide chapter TBD |
Planned for future release |
7.2.5.0 |
Add support for CUE input based tooling for CPU assignment, DDR Allocation, Ethernet Interfaces in GOS VM and GPIO Reassignment for Thor PCTs. Benefits:
New DT sources for Process Specification and HV BSP will be added. |
DriveOS dev-guide chapter <TBD> |
Customers need to rebase their modification and changes to CUE format for above CPU, DDR, Ethernet and GPIO usecases. Customers also need to adapt to new DT sources for Process Specification and HV BSP for their PCT modifications. |
|||
7.2.6.0 |
PCT format moves to Device Tree format for Thor SOC. This will be a significant re-design; configuration knobs will not have 1:1 equivalency with earlier format. |
DriveOS dev-guide chapter <TBD> |
The customer needs to migrate PCT customizations from C header format to device-tree format |
|||
TBD |
Add more usecases for CUE based tooling support for PCT modifications. Migrate PCT format for Orin SOC to Device Tree format and support CUE based tooling for PCT modifications. |
DriveOS dev-guide chapter <TBD> |
The customer needs to rebase their modifications to CUE format for new usecases supported for PCT modifications. |
|||
Storage |
INI |
CUE |
7.2.3.0 |
Customer vs DriveOS core separation for Thor PCTs DriveOS provides:
The customer is responsible for adding and maintaining support for customer platform:
|
DriveOS developer guide chapter “”NVIDIA DRIVE AV Storage Configuration via CUE”” |
Default workflow uses CUE format. INI usage will be deprecated |
TBD |
Extend Storage tooling support for Orin PCTs. |
DriveOS dev-guide chapter “”NVIDIA DRIVE AV Storage Configuration via CUE”” |
Default workflow uses CUE format. INI usage will be deprecated |
|||
PCT Profile Makefiles |
Makefiles (.mk) |
<no change> |
7.2.3.0 |
Improved separation and workflow The customer is responsible for:
|
DriveOS developer guide chapter “”PCT Profile Flags and Customization”” |
Tooling improvements continued from 7.2.2.0 to help customers avoid modifying DriveOS internal Makefiles. Customer’s current patches to modify DriveOS internal build files (if any) will still work. However customers are strongly recommended to migrate their modification to new workflow for ease of usage, maintainance and migration. |
Tool: Board Cloner |
<not applicable> |
<not applicable> |
7.2.3.0 |
Automated tool to help customers:
|
DriveOS dev-guide chapter “”Custom Board Cloner Tool - Adding Support for a New Hardware Platform in DriveOS”” |
Initial release of Board Cloner tool. Customers can start using tool to reducing their manual effort for new platform bringup. |
Tool: Configuration Validation |
<not applicable> |
<not applicable> |
7.2.3.0 / 7.2.4.0 / 7.2.5.0 |
Tool not yet available |
DriveOS dev-guide chapter TBD |
Planned for future release |
7.2.6.0 |
Enhanced validation framework to:
|
DriveOS dev-guide chapter TBD |
Initial release |
Configuration File Changes#
OESP PCT Synchronization#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
OESP PCT is new for Thor in 7.0.3 and later releases. Its configuration requires synchronization with regular PCT (guest configuration) |
Yes |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
OESP TCM is under size restriction. The regular PCT cannot fit into OESP TCM so OESP PCT is used to provide necessary configurations to OESP
Steps to Migrate
OESP PCT (oesp_platform_config.h) needs synchronization with regular PCT (guest_config.h)
When updating tos_keystore_conf, ethernet_cfg, or ethernet_mcfg in guest_config.h, need to update tos_keystore_conf or ethernet_en_vm in oesp_platform_config.h accordingly
Thor Ephemeral PKCS11 Asymmetric Key Limits#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
In 7.0.3, the number of ephemeral (PKCS11 session) asymmetric keys supported on Thor across all sessions of a single application per token will change due to memory constraints of Thor. The default Token, CCPLEX2, retains support for the same numbers as has been the case since 6.0.6.0, i.e. 8 RSA public, 8 EC public and 8 EC private. Non-default CCPLEX tokens shall each support: 4 RSA public, 4 EC public and 4 EC private. In a future 7.2.x release, there will be a smaller allocation of keys by default. This will be configurable per token so that if a particular token needs more keys, then another token can be adjusted lower. |
Yes, for the default token. No otherwise |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
The change is due to Thor memory constraints
Steps to Migrate
N/A
Thor KDS Hardware and AES Symmetric Key Allocations#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Thor will use KDS hardware in the 7.0.3.0 release, which allows for faster key loading and more efficient use of keyslots. To support this hardware there is a change in the number of AES symmetric keys that can be supported, for Thor only: The TSEC token will now support 500 AES symmetric keys. The TSECRADAR token will now support 20 AES symmetric keys. In total, across all CCPLEX tokens, 500 AES symmetric keys. Public and private keys do not use KDS; those allocations are unchanged. Each application that uses a token receives an allocation of ephemeral AES symmetric keys. Tokens will be configured as follows: CCPLEX_SAFETY_2: 8 applications, 64 keys each CCPLEX_DYNAMIC_2: 8 applications, 64 keys each All other CCPLEX tokens: 8 applications, 16 keys each In a future release, each of those 8 applications will receive a smaller allocation of keys by default. This will be configurable per token. If a particular token needs more keys, then another token can be adjusted lower. |
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
In Thor, there is a limit imposed by the KDS hardware that dictates the number of keys to support
Steps to Migrate
N/A
NvDisplay Device Tree: static-imp-data#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Device Tree: New config: “static-imp-data” changes |
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 the “static-imp-data” Device Tree Node. (For additional information, see changes to NvDisplay Tool changes to use LAPTSA IMP tool)
Steps to Migrate
Use laptsa-imp host-side tool to generate static IMP DT fragment. Add this fragment to the NvDisplay DCE device tree.
NvDisplay Device Tree: display-timings#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Device Tree: Changes to specify display-timings. |
No |
NSR |
Linux |
Migration Path
Orin to Thor
Migration Rationale
In 6.x/7.0.1.0, users specified connector configuration and mode timings using “display-timings” device tree entry. (Refer to 6.x DriveOS SDK section for NvDisplay/Display Serializer.)
From 7.0.2.0 “display-timings” entry are deprecated and will be replaced with multiple entries as described below. For actual changes to structure, please refer to NvDisplay section in DRIVE OS SDK guide.
Steps to Migrate
display-modes/mode
display-modes specifies a list of modes along with a unique
identifier (timing-id). The rest of the schema of the timings is
similar to 6.x. The timing-id is then used to look up the full
specification of the mode.
heads/head
Specifies the list of heads and timing-id (unique id as per display-modes/mode) for each head - head timings are programmed by the server.
dpys/dpy
A dpy specifies the logical display used by the display driver. A dpy is associated with a connector-id and a hw-head-id. The connector-id is the same as the dcbIndex. This dpy has a timing-id that is an identifier to a unique timing configuration as per “display-modes/mode”.
Steps to Migrate
6.x/7.0.1.0 Config:
{
display@13800000 {
display-timings {
display-connector-0 {
dcb-index = <0>;
stream-0 {
timings-phandle = <&mode_ss_1080p>;
superframe-info {
pipe_x_view: view-0 {
x = <0>;
y = <0>;
width = <1920>;
height = <1080>;
hfront-porch = <24>;
hback-porch = <40>;
hsync-len = <16>;
vfront-porch = <3>;
vback-porch = <18>;
vsync-len = <10>;
};
pipe_y_view: view-1 {
x = <1920>;
y = <0>;
width = <1920>;
height = <1080>;
hfront-porch = <24>;
hback-porch = <40>;
hsync-len = <16>;
vfront-porch = <3>;
vback-porch = <18>;
vsync-len = <10>;
};
};
};
stream-1 {
timings-phandle = <&mode_ss_1080p>;
superframe-info {
pipe_z_view: view-0 {
x = <0>;
y = <0>;
width = <1920>;
height = <1080>;
hfront-porch = <24>;
hback-porch = <40>;
hsync-len = <16>;
vfront-porch = <3>;
vback-porch = <18>;
vsync-len = <10>;
};
pipe_u_view: view-1 {
x = <1920>;
y = <0>;
width = <1920>;
height = <1080>;
hfront-porch = <24>;
hback-porch = <40>;
hsync-len = <16>;
vfront-porch = <3>;
vback-porch = <18>;
vsync-len = <10>;
};
};
};
};
};
mode_ss_1080p: 3840-1080-60Hz {
clock-frequency-khz = <266640>;
hactive = <3840>;
vactive = <1080>;
hfront-porch = <48>;
hback-porch = <80>;
hsync-len = <32>;
vfront-porch = <3>;
vback-porch = <18>;
vsync-len = <10>;
rrx1k = <60000>;
};
mode0: 1920-1080-60Hz {
clock-frequency-khz = <148500>;
hactive = <1920>;
vactive = <1080>;
hfront-porch = <88>;
hback-porch = <148>;
hsync-len = <44>;
vfront-porch = <4>;
vback-porch = <36>;
vsync-len = <5>;
rrx1k = <60000>;
};
mode1: 1280-720-60Hz {
clock-frequency-khz = <74250>;
hactive = <1280>;
vactive = <720>;
hfront-porch = <110>;
hback-porch = <220>;
hsync-len = <40>;
vfront-porch = <5>;
vback-porch = <20>;
vsync-len = <5>;
rrx1k = <60000>;
};
};
};
7.0.2.0 Config:
/ {
display@8808c00000 {
display-modes {
mode-0 {
timing-id = <0>;
clock-frequency-khz = <148500>;
hactive = <1920>;
vactive = <1080>;
hfront-porch = <88>;
hback-porch = <148>;
hsync-len = <44>;
vfront-porch = <4>;
vback-porch = <36>;
vsync-len = <5>;
rrx1k = <60000>;
pps-data = [
11 00 00 89 30 80 04 38
07 80 04 38 03 c0 03 c0
02 00 03 58 00 20 73 3e
00 0d 00 0f 00 1d 00 0e
18 00 10 f0 03 0c 20 00
06 0b 0b 33 0e 1c 2a 38
46 54 62 69 70 77 79 7b
7d 7e 01 02 01 00 09 40
09 be 19 fc 19 fa 19 f8
1a 38 1a 78 22 b6 2a b6
2a f6 2a f4 43 34 63 74
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ];
};
};
};
};
/ {
display@8808c00000 {
dpys {
dpy-0 {
hw-head-id = <0>;
timing-id = <0>;
connector-id = <0>;
};
dpy-1 {
hw-head-id = <1>;
timing-id = <0>;
connector-id = <1>;
};
dpy-2 {
hw-head-id = <2>;
timing-id = <0>;
connector-id = <2>;
};
};
heads {
head-0 {
hw-head-id = <0>;
timing-id = <0>;
};
head-1 {
hw-head-id = <1>;
timing-id = <0>;
};
head-2 {
hw-head-id = <2>;
timing-id = <0>;
};
};
};
};
NVIPC Per-Endpoint Streaming Mode Buffer Limit#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Changes to the per endpoint streaming mode buffer limit. Added a per endpoint streaming mode buffer limit, which affects per endpoint overall buffer size usage. Example: Before the migration (in 6.0) the following command works without errors (-b <buffer-size-in-MB>)
After the migration, the same command would fail due to the per endpoint buffer limit of 67MB implemented in 7.0. |
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
To align with security ARR configuration of NVIPC Buffer Limits.
Steps to Migrate
Adjust commands to align with the buffer limits.
NVIPC DTB Configuration and nvsciipc.cfg#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Use the DTB configuration file instead of a plain text config file (nvsciipc.cfg). If the same channel configuration is defined in both nvsciipc.cfg and DTB, NVIPC uses DTB as the priority. The NvSciIpc plain text config file will be deprecated in a future release. |
No |
NSR, SR |
Linux |
Migration Path
Orin to Thor
Migration Rationale
To provide unified NvSciIpc configuration regardless of OS type, stronger security, and consistent maintenance across updates and platform changes.
Steps to Migrate
Convert the plain text configuration to nvsciipc DTB
Steps to Migrate
Refer to the NVIDIA DriveOS Linux SDK Developer Guide (DTB location and configuration format) and the following example:
Steps to Migrate Example Per the Previous Table
6.x/7.0.x.0 Config:
# <Backend_name> <Endpoint-name1> <Endpoint-name2> <backend-specific-info> <uids>
INTER_PROCESS ipc_test_0 ipc_test_1 64 1536 2000 2001
INTER_PROCESS ipc_test_a_0 ipc_test_a_1 64 1536 2000 2001
INTER_PROCESS ipc_test_b_0 ipc_test_b_1 64 1536 2000 2001
INTER_PROCESS ipc_test_c_0 ipc_test_c_1 64 1536 2000 2001
INTER_THREAD itc_test_0 itc_test_1 64 1536 2000 2000
INTER_VM loopback_tx 256 2000
INTER_VM loopback_rx 257 2000
7.2.2.0 Config:
/ {
chosen {
nvsciipc_user {
/* NvSciIpc configuration format : string array
*
* INTER_THREAD/PROCESS backend case:
* "BACKEND_TYPE","ENDPOINT1_NAME","ENDPOINT2_NAME", "BACKEND_INFO1","BACKEND_INFO2","UID1","UID2",
*
* INTER_VM/CHIP backend case:
* "BACKEND_TYPE","ENDPOINT_NAME","BACKEND_INFO1", "BACKEND_INFO2","UID",
*
* BACKEND_TYPE : INTER_THREAD, INTER_PROCESS, INTER_VM, INTER_CHIP
* For INTER_THREAD and INTER_PROCESS, two endpoints name should be different.
* you can use different suffix with basename for them.
*/
compatible = "nvsciipc,channel-db-user";
nvsciipc,channel-db-user =
"INTER_PROCESS", "ipc_test_0", "ipc_test_1", "64", "1536", "2000", "2001",
"INTER_PROCESS", "ipc_test_a_0", "ipc_test_a_1", "64", "1536", "2000", "2001",
"INTER_PROCESS", "ipc_test_b_0", "ipc_test_b_1", "64", "1536", "2000", "2001",
"INTER_PROCESS", "ipc_test_c_0", "ipc_test_c_1", "64", "1536", "2000", "2001",
"INTER_THREAD", "itc_test_0", "itc_test_1", "64", "1536", "2000", "2000",
"INTER_VM", "loopback_tx", "256", "2000",
"INTER_VM", "loopback_rx", "257", "2000",
status = "okay";
};
};
};
PCD Generic Device Tree, Storage Configuration, and Board Configuration Files#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
|
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
Generic DT: To align with upstream Linux expectation
Storage Config and Board Config Update: Enhancements for ease of configuration for customer and tooling support.
Steps to Migrate
Configuration update steps with reference examples will be provided in the upcoming revisions of the migration guide and release documentation.
TCF Boot Flow Changes#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Of the many changes related to Boot Flow in 7.0, a few are noted below: MCE component is no longer available. MB1 boots the boot core. TSEC is loaded in MB2. iGPU firmware is loaded in MB1. NVDEC FW is not loaded by MB1. New Security enclaves: OESP and SB. MB1 loads them. New AUXP, which MB2 loads. MB1BCT and MB2 BCT flags changed. |
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
Changes are required due to Orin to Thor hardware platform changes and boot flow architecture updates
Steps to Migrate
In-depth details will be provided in the upcoming revisions of the migration guide and developer guide documentation.
Security Services Keyslot Enforcement (Multipart Operations)#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
No longer need to limit keyslots if the operation is not multipart. Enforcement of keyslots is no longer on a per token basis. |
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
Hardware changes in Thor increases flexibility in using keyslots. The change also improves performance and latency of key load operations.
Steps to Migrate
PCT requires updating to replace the old configuration (which limits the number of keyslots an app can use) to the new configuration.
Applications should update which SE Engine needs to be used for crypto operations.
Linux BSP Mandatory Device Tree Properties#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
Convert optional DT properties to mandatory. |
No |
NSR |
Linux and QNX |
Migration Path
Orin to Thor
Migration Rationale
To ensure correct configuration, the following properties are now mandatory
Steps to Migrate
Define the following mandatory DT properties:
nvpps-event-mode-init: specifies the initial operating mode of
the NvPPS driver.
Define the following DT properties when TSC to PTP synchronization is required, such as when the ptp_tsc_sync_dis property is not defined:
reg: specifies the start address and registers count details of
TSC module.
ptp_tsc_lock_threshold: specifies the threshold value used to
determine if the TSC PTP sync/Lock is lost. By default, the
previous value was 20.
ptp_tsc_sync_trig_interval: specifies the interval at which align
should be triggered. The previous default value was 3.
nvidia,pps_op_ctrl: Ethernet DT node property. Specifies the
frequency of the PPS signal rxd by the TSC module. The previous
default values were 8 and 4 in Thor and Orin, respectively
For additional information regarding the properities and supported values, refer to the device tree binding document.
Steps to Migrate Example Per the Previous Table
7.0.4.0 Config:
/ {
nvpps {
compatible = "nvidia,tegra234-nvpps";
reg = <0x0 0xc6a0000 0x0 0x1000>;
primary-emac = <&mgbe2>;
sec-emac = <&eqos0>;
ts-capture-interval = <1000>;
nvpps-event-mode-init = <2>; /* 1: GPIO mode, 2: TIMER mode */
ptp_tsc_lock_threshold = <20000>; //20us
ptp_tsc_sync_trig_interval = <3>;
status = "disabled";
};
/* MGBE - C, Connected to OAK 5G */
mgbe2: ethernet@6A10000 {
nvidia,ptp_m2m_role = <1>;
nvidia,if-name = "mgbe2_0";
/* Setting to MAX PPS value(4Hz) supported for Orin */
nvidia,pps_op_ctrl = <4>;
nvidia,ptp-tsc-trig = <500>;
};
};
PCD Configuration Files Layout#
Target Changes |
Backward Compatible |
Platform |
OS |
|---|---|---|---|
DRIVEOS 7.x Configuration files layout will change in the SDK. The reorganization aligns with stakeholder requirements for confiuguration to be as follows:
|
No |
NSR, SR |
Linux and QNX |
Migration Path
Orin to Thor
Thor to Thor
Migration Rationale
Configuration layout needs to align with stakeholder requirements and for easier management of configurations.
The new layout also provides ease of configuration and better integration with tooling solutions.
Steps to Migrate
Update your configuration files to the new layout.
The new workflow is to create a copy of the NVIDIA Reference Configuration and modify it as needed. Create a manifest file and pass it to the bind step for your configuration to get picked up by the build system. Detailed steps will be documented in the NVIDIA Drive0S 7.X SDK Developer Guide.