Customer-facing Configuration File Changes#
This section covers target changes to customer-facing files such as PCT, DT, .JSON, BR-BCT, and startup.
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.