AV PCT Configuration

The Profile Makefile is the file having definitions of PCT configuration. Each PCT have own Profile Makefiles.

Standard SDK/PDK Package

Default Profile Makefile(profile.mk) is for Standard Package.

The Profile Makefile is located at:

• Single Linux GOS VM (linux PCT):

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/linux/profile.mk

• Single QNX GOS VM (qnx PCT):

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/qnx/profile.mk

• Dual QNX GOS VMs (dual-qnx PCT):

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/dual-qnx/profile.mk

Safety SDK/PDK Package

Safety build package need an additional option (PCT variant option, -p) while bind to select different Profile Makefile for Safety Package. The Safety package has three types of profile configurations (PCT variant): prod, prod_debug, and prod_debug_extra. Especially prod_debug and prod_debug_extra PCT variant provides debug environment based on prod PCT variant.

These Profile Makefiles are located at:

• Single QNX GOS VM (qnx PCT):

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/qnx/profile_prod.mk
    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/qnx/profile_prod_debug.mk
    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/qnx/profile_prod_debug_extra.mk

• Dual QNX GOS VMs (dual-qnx PCT):

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/dual-qnx/profile_prod.mk
    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/dual-qnx/profile_prod_debug.mk
    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/dual-qnx/profile_prod_debug_extra.mk

Note:

• The prod_debug and prod_debug_extra PCTs are used for testing/debugging purposes. These PCTs use a different file package that must not be used as part of the software stack in a running car.

The following tables list the supported combination of PCT, platform, and SDK/PDK package.

The CPUs column indicates the number of CPUs assigned to the guest VM and to the server VMs, respectively.

Supported Platform and Board Name

Note:

• Board name with suffix -f1 or -ct02 has eight CPU cores. Also, Board name with suffix -f1 are only for NVIDIA Internal Use. Normally, NVIDIA Orin has 12 CPU cores.

Standard SDK/PDK Package

Safety SDK/PDK Package

The example guest_config.h shows the mapping between the guest OS and services as well as their allocations.

Depending on the use cases, storage configuration and peripheral assignment are different.

The following table lists the supported use cases with platforms.

DRAM ECC feature can be enabled for DRIVE AV PCT by modifying Profile Makefiles. Below needs to be added in profile makefiles to enable DRAM ECC.

ENABLE_DRAM_ECC := y

Refer to Profile Makefile to check which profile makefile needs to be modified.

Note:

• DRAM ECC feature is enabled for QNX safety PCTs by default.

FSI can be disabled for DRIVE AV Linux PCTs by modifying Profile Makefiles. Below needs to be added in profile makefiles to disable FSI.

ENABLE_FSI := n

Refer to Profile Makefile to check which profile makefile needs to be modified.

Note:

• FSI is enabled for Drive AV Linux PCTs by default.

Dual Core Lock Step (DCLS) can be enabled for the main CPU complex, referred to as the CCPLEX, by modifying Profile Makefiles. Enabling CCPLX DCLS reduces the effective number of CPU core by half, so it is only supported in Single GOS VM PCT with either 8 or 12 CPU cores. The following flag needs to be changed from n to y in profile makefiles to enable DCLS.

ENABLE_CCPLEX_DCLS := y

Alternatively, you can pass ENABLE_CCPLEX_DCLS=y in the bind_partitions command to override the default setting instead of modifying the flag directly as shown below.

bind_partitions -b p3663-a01 qnx ENABLE_CCPLEX_DCLS=y

Refer to Bind Options for the bind_partitions command.

Note:

• DCLS is disabled for DRIVE AV PCT by default.

Read access to ECID can be provided to Guest VMs by configuring below in guest_config.h for a VM in PCT settings.

can_read_ecid_hash = 1

ECID is considered as a solution for customer to get a unique ID of the platform from customer's application.

Note:

• ECID read access is disabled for Drive AV PCTs for all VMs by default.

The following tables list the supported bind options.

Bind Options for Standard Package

Note:

• Get full <board_name> from Supported Platform and Board Name.

Bind Options for Safety Package

Bind Options for Power Profile

Bind Options for SoC ID for C2C in GOS-DT

When the <SOC_ID> argument is specified with the -s option, SOC_IDENTIFICATION_VALUE is defined and the <SOC_ID> value will be set for soc_id in GOS-DT property.

#ifdef SOC_IDENTIFICATION_VALUE
	soc_id = <SOC_IDENTIFICATION_VALUE>;
#else
	soc_id = <1>;
#endif

The following diagram gives an example of a three level partition layout and 3 level partition tables.

To enable data updates in eMMC and UFS partitions through Over-The-Air(OTA), the partitions on eMMC are categorized as follows:

• The eMMC A chain: It consists of all eMMC partitions assigned to all virtual machines in the Partition Configuration Table (PCT). All content in this chain can be overwritten by the OTA application.

• The eMMC B chain: This is the recovery chain. The target boots in this chain when the OTA application is about to update other boot chains.

• The QSPI C chain: This is the recovery chain to boot with only QSPI. The target boots in this chain when the OTA application is about to update other boot chains.

• Persistent partitions for all virtual machines: The data partitions that are NOT updated by the OTA application. Data over these partitions remain consistent over multiple OTA cycles.

Inspecting the global_storage.cfg (level-1) you will notice it refers to boot_chain_storage.cfg as a “sub_config” file. This elevates the boot_chain_storage_qspi.cfg to be level-2.

...
[partition]
name=A_qspi_chain
...
sub_cfg_file=boot_chain_storage.cfg

[partition]
name=B_qspi_chain
...
sub_cfg_file=boot_chain_storage.cfg

[partition]
name=C_qspi_chain
...
sub_cfg_file=boot_chain_c_storage.cfg

Similarly, inspecting the boot_chain_storage.cfg (level-2) you will notice it refers to the OS storage config file. This elevates the OS storage config file to be level-3.

[partition]
name=qnx-gos0
...
sub_cfg_file=qnx_gos0_storage.cfg

Since level-3 is derived from Level-2, its content will be duplicated in each of the boot chains (A & B).

General structure of this file is:

• device 1 information

  • partition 1.1 information

  • ....

  • partition 1.n information

• device 2 information

  • partition 2.1 information

  • ....

  • partition 2.n information

• and so on.

Device information highlighted by this application note are:

• linux_name=/dev/block/3270000.spi - name of peripheral device

• size=0x940000 - total size of storage device

Note:

• For Level-2 & Level-3 configurations, the size is not the total size of the device, but it is the allowed size of storage device for that level, as defined in previous level partition information highlighted by this application note are:

  • name=bct - logical name of the partition

  • size=0x80000 - size of the partition

Partitions that utilize the “sub_cfg_file” are container partitions. These partitions share the same space with partitions in “sub_cfg_file”. The size attribute specifies the allowed space the next level can use on the device.

For the QSPI storage, the allowed space for Level-2 & Level-3 is specified by the size

[partition]
name=A_qspi_chain
size=0x940000

[partition]
name=B_qspi_chain
size=0x940000

Since Level-2 & Level-3 also allocate storage on eMMC/UFS, the limit on how much eMMC/UFS storage can be allocated is defined here :

[partition]
name=A_emmc_chain
size=EMMC_BOOTCHAIN_SIZE

[partition]
name=B_emmc_chain
size=EMMC_BOOTCHAIN_SIZE

name=A_ufs_chain
size=UFS_BOOTCHAIN_SIZE

name=A_ufs_chain
size=UFS_BOOTCHAIN_SIZE

The information about of all partitions in Level-1, as been allocated on both QSPI & eMMC/UFS, are stored in a partition table file

[partition]
name=pt
size=0x80000

This partition CANNOT be updated when the DU process is done. This table is common to Chain A & Chain B, so both chains' future updates must preserve the content of Level-1 partitions. If not, DU process will fail.

These follow the same rules as Level-1, that is, General structure of this file is:

• device 1 information

  • partition 1.1 information

  • ....

  • partition 1.n information

• device 2 information

  • partition 2.1 information

  • ....

  • partition 2.m information

Each level can specify partitions on QSPI and eMMC/UFS storage devices. The “device” record size is the max allowed storage space for that level, not the full size. Both levels will affect the content of Chain A and Chain B.

The storage device passthrough access is disabled by default for Drive AV QNX prod and prod_debug PCT Variants. For internal testing, the passthrough access is selectively enabled for following:

Note:

• DRIVE OS user is recommended to enable storage passthrough access (if required) for only one virtual storage partition of a physical storage device.

  See the Virtual Partitions section for details regarding how to enable passthrough access using a 32-bit virtual_storage_ivc_ch value for a virtual partition.

Configuration Files

The default storage layout QSPI and eMMC/UFS are as shown in their respective tables below (Refer to Storage Layout). Users can customize the storage layout for mass storage partitions on the target by modifying the configuration files. After the configuration files are updated, the target must be flashed again.

For Single Linux GOS VM PCT:

• Storage configuration files

        <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/linux/

• GOS0 DTB for virtual storage nodes

        <top>/<NV_SDK_NAME_LINUX>/kernel/source/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/linux/storage/tegra234-common-storage-linux-gos.dtsi

For Single QNX GOS VM PCT:

• Storage configuration files

        <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/qnx/

• GOS0 DTB for virtual storage nodes

        <top>/<NV_SDK_NAME_QNX>/bsp/device-tree/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/qnx/storage/tegra234-common-driveav-storage-gos0.dtsi

For Dual QNX GOS VMs PCT:

• Storage configuration files:

        <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/dual-qnx

• GOS0 DTB for virtual storage nodes

        <top>/<NV_SDK_NAME_QNX>/bsp/device-tree/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/qnx/storage/tegra234-common-driveav-storage-gos0.dtsi

• GOS1 DTB for virtual storage nodes

        <top>/<NV_SDK_NAME_QNX>/bsp/device-tree/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/qnx/storage/tegra234-common-driveav-storage-gos1.dtsi

First-Level Partition Table(L1PT) Layout

The global_storage.cfg file defines the total size of storage devices, boot chain container partitions and persistent partitions of guest VMs.

The first-level configuration has the following layout for the ECO QSPI+eMMC use case:

The first-level configuration has the following layout for the ECO QSPI+UFS use case:

The first-level configuration has the following layout for the NDAS use case:

Note:

• For mandatory partition, only size of partition is customizable. For nonmandatory partition, all partition-attributes is customizable or it can be removed/split.

Second Level Partition Table(L2PT) Layout

• QSPI Chain-A/B Layout

QSPI partitions include bct files, bootloaders, and firmware binaries.

The storage layout for QSPI is as follows:

Note:

• Chain B (same as Chain A) partitions are not included in the above table.

• QSPI Chain-C Layout

• emmc-part eMMC and UFS partitions

The eMMC/UFS device connected to NVIDIA Orin is partitioned logically to enable each VM to have its own root file system or to store user data. Each VM is assigned a dedicated user partition on eMMC/UFS and might have secondary user partitions for storing additional data. The eMMC/UFS device on board is shared between the VMs.

The eMMC/UFS Storage Chain A/B for QNX PCT ECO use case:

Where:

• /dev/vblk_* denotes the enumeration for a given partition from guest OS or service VM. The partitions must be formatted before use.

• IFS: Early boot partition with minimal file system that contains the kernel.

• EFS: QNX root file system, additional file system demonstration bits, sample applications, and data.

• All partitions present in boot_chain_storage.cfg are part of the OTA update.

• All sub-configuration files that are in the boot_chain_storage.cfg are also part of the OTA update.

The eMMC/UFS Storage Chain A/B for Linux PCT ECO use case:

The eMMC/UFS Storage Chain A/B for QNX (qnx/dual-qnx) PCT NDAS use case:

Note:

• (*) is a partition only for dual-qnx PCT, and (#) is a partition only for HIGH storage configuration.

The eMMC/UFS Storage Chain A/B for Linux PCT NDAS use case:

Note:

• (#) is a partition only for HIGH storage configuration.

Note:

• For mandatory partition, only size of partition is customizable. For non-mandatory partition, all partition-attributes is customizable or it can be removed/split.

GUID based partition table support is added for GOS at L3 level. With this feature, the partitions in L3 under GPT can be independently updated including the partition table.

To add a GPT partition at third level(L3), a container partition needs to be added at second level(L2). Level 2 container partition holds the GPT primary and backup partition layout along with the actual partition contents.

The diagram below shows the organization of L2 container partition for GPT.

In the example above, the “custom” partition is the container partition. In order for the flashing tools to create GPT partition layout the first partition must be of type “GP1” and the last partition must be of type “GPT”. Flashing tools would create GPT primary and back up partitions when such an arrangement exists.

Multiple GPT partitions can be added for the same guest. The GPT primary and secondary are generated by using the container partition name as prefix.

Example Changes for Both Linux and QNX GOS VM

Configuration files are in the following folder:

    <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/<PCT>

    NOTE:
        <PCT> is qnx or dual-qnx or linux.

The following example snippet shows changes required to add custom partition in L2:

    boot_chain_storage.cfg

    [device]
    type=sdmmc
    instance=3
    linux_name=/dev/block/3460000.sdhci
    size=EMMC_BOOTCHAIN_SIZE

    ...

    [partition]
    name=custom
    allocation_policy=sequential
    size=0x680000
    partition_attribute=0x1000000<GID_GUEST0_VM+1>
    sub_cfg_file=custom_storage_emmc.cfg
    virtual_storage_ivc_ch=0x8<GID_VSC_SERVER>964631

Note:

• IVC Channel(0x31=49) and Mempool(0x46=70) used in virtual_storage_ivc_ch are subject to availability.

Note:

• For information about partition_attribute, see Mass Storage Partition Configuration > Customizing the Configuration File > Setting Attributes > Partition Attributes Table in the NVIDIA DRIVE OS 6.0 Linux SDK Developer Guide or see Storage > Mass Storage Partition Configuration > Customizing the Configuration File > Setting Attributes > Partition Attributes Table in the NVIDIA DRIVE OS 6.0 QNX SDK Developer Guide.

The next step is to add IVC and mempool entry in the platform_config.h file for custom partition.

IVC entry in .ivc:

#if defined (ENABLE_VSC_EMMC_VIRT)
              [49] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .nframes = 16, .frame_size = 128 },
#endif

Mempool entry in .mempools:

#ifdef ENABLE_VSC_EMMC_VIRT
              [70] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .size = (SZ_1MB * 8), .align = (SZ_1MB * 2) },
#endif

Note:

• In case ENABLE_HVRTOS_VSC_* is enabled in profile makefile, Adding Ivc/Mempool array in platform_config.h is not needed.

More custom partitions can be added with the same guest ID in the partition_attribute. The container partition name is used to differentiate between multiple GPT partition tables for the same guest.

For the example above the GPT is defined within the sub config file "custom_storage_emmc.cfg".

The following shows an example of how to define GPT L3 partitions.

    custom_storage_emmc.cfg

    [meta]
    version=2

    [device]
    type=sdmmc
    instance=3
    linux_name=/dev/block/3460000.sdhci
    size=0x680000

    [partition]
    name=sample-gp1
    type=GP1
    allocation_policy=sequential
    filesystem_type=basic
    size=0x40000
    partition_attribute=0

    [partition]
    name=samplep1
    allocation_policy=sequential
    filesystem_type=basic
    size=0x200000
    partition_attribute=1

    [partition]
    name=samplep2
    allocation_policy=sequential
    filesystem_type=basic
    size=0x200000
    partition_attribute=1

    [partition]
    name=samplep3
    allocation_policy=sequential
    filesystem_type=basic
    size=0x200000
    partition_attribute=1

    [partition]
    name=sample-gpt
    type=GPT
    allocation_policy=sequential
    filesystem_type=basic
    size=0x40000

Example Changes for QNX GOS VM

Add device tree entry to let QNX enumerate each of the partitions inside the container as virtual block devices, as in the following example:

    <top>/<NV_SDK_NAME_QNX>/bsp/device-tree/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/qnx/storage/tegra234-common-driveav-storage-gos0.dtsi

    tegra_virt_storage50 {
        compatible = "nvidia,tegra-hv-storage";
        status = "okay";
        instance = <12>;
        ivc = <&tegra_hv 49>;
        mempool = <70>;
        icache = <10485760>;        
        device-type = "vblk_mnand";
        partition-name = "custom";
    };

    NOTE: Ensure tegra_virt_storage50 is unique in the above mentioned dtsi file.
        Pick a different instance of tegra_virt_storage, if tegra_virt_storage50 is already in use.

Add the nvsciipc table entry in the

        <top>/<NV_SDK_NAME_QNX>/bsp/device-tree/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/qnx/tegra234-nvsciipc-gos0.dtsi

        "INTER_VM",      "nvhvblk_49",          "49",  "0",    /* nvhvblk_guest */

Add created nvhvblk node(nvhvblk_49 in this example) in the list after nvhvblk_orin_gos: in

        <top>/<NV_SDK_NAME_QNX>/nvidia-bsp/aarch64le/sbin/nvsciipc_secpolicy.cfg

        nvhvblk_orin_gos:nvhvblk_49,<already existing nvhvblk_* list>

Rebuild-QNX-IFS/Bind/Bootburn steps are needed after upper changes.

Example Changes for Linux GOS VM

Add device tree entry to let Linux enumerate each of the partitions inside the container as virtual block devices, as in the following example:

    <top>/<NV_SDK_NAME_LINUX>/kernel/source/hardware/nvidia/platform/t23x/automotive/kernel-dts/common/linux/storage/tegra234-common-storage-linux-gos.dtsi

    tegra_virt_storage50 {
        compatible = "nvidia,tegra-hv-storage";
        status = "okay";
        instance = <40>;
        ivc = <&tegra_hv 49>;
        mempool = <70>;
    };

    NOTE: Ensure tegra_virt_storage50 is unique in the above mentioned dtsi file.
        Pick a different instance of tegra_virt_storage, if tegra_virt_storage50 is already in use.

Bind/Bootburn steps are needed after upper changes.

Caution and Verification

The size of the device at L3 matches the size of the extended custom partition at L2:

The custom container has three partitions each of 2 MB. Note that the filename is not specified above. If file is not specified, flash tools will not create any images for these partitions but the space is allocated and will be formatted if specified. If an image is required, update the partition within the custom cfg file accordingly to add the filename field and point it to the file you want to flash.

Once booted with upper changes, the GPT partitions are enumerated as virtual block devices in each Guest OS(QNX or Linux).

For QNX, for example, if the container block device is enumerated as /dev/vblk_mnandc0, then the individual partitions are /dev/vblk_mnandc0.ms.0, /dev/vblk_mnandc0.ms.1, and /dev/vblk_mnandc0.ms.2.

For Linux, if the container block device is enumerated as /dev/vblkdev40, then the individual partitions are /dev/vblkdev40p1, /dev/vblkdev40p2, and /dev/vblkdev40p3.

QNX FS Images

The GPT partitions added above do not have a file image associated, so create_bsp_images does not generate images for these partitions. Follow the steps below to create a qnx6 dummy fs image with some contents.

1.Create an empty folder mkdir custom_fs.

2.Create some text files using touch, and add some content to the custom_fs folder.

3.Create the qnx_rootfs_build file with the contents and save as qnx_rootfs_build:

	[num_sectors=4096]
	[-followlink]
	[perms=0755 dperms=0755 uid=0 gid=0] /=./custom_fs
	[type=link]/tmp=/dev/shmem

4.Make sure that QNX_TARGET and QNX_HOST paths are set correctly.

	$QNX_HOST/usr/bin/mkxfs -t qnx6fsimg qnx_rootfs_build custom_qnxfs.img

=====================================