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 additional option (PCT varient 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 provide 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 names with suffix -ct02 have 8 CPU cores. Normally, Orin have 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 figure out 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 figure out which profile makefile needs to be modified.

Note:

FSI is enabled for Drive AV Linux PCTs 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 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

• etc.

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 and 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, i.e. 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 & 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.

Configuration Files

The default storage layout QSPI and eMMC/UFS are as shown in their respective tables below (Refer 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

Virtual Partitions

Partitions tare allocated to the QNX/Linux Virtual Machine(VM) and are physically managed by Virtual Storage Controller(VSC) server VM. These partitions are defined to be virtual partitions.

This is being discussed in PDK manual, Storage Server / Virtualized Storage in NVIDIA DRIVE OS 6.0 Linux PDK Developer Guide or NVIDIA DRIVE OS 6.0 QNX Development Guide.

These partitions are accessible to the VM(s) via inter VM communications channels called Inter-VM-Channel(IVC) which is a bi-directional short command oriented interface, and memory-pool which is a shared memory buffer. These are only accessible by the QNX/Linux VM and the VSC.

There are two files to modify:

• <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/platform_ivc_config.h

  • Allocate unused IVC number and define a new constant named:

#if defined(PLATFORM_<BOARD NAME>)
#define GOS0_VSC_Q_<#>   	 <#>
#endif

• IVC number can be added up to 255.

• At the end of same file, allocate an unused memory pool id, and define a new constant

#if defined(PLATFORM_<BOARD NAME>)
#define GOS0_VSC_M_<##>   	 <##>
#endif

• <top>/<NV_SDK_NAME_FOUNDATION>/platform-config/hardware/nvidia/platform/t23x/automotive/pct/drive_av/platform_config.h

  • Within the block of defining <VM><VM>Q<#> , locate the pre-processor associated with the storage device type you are adding a partition to. Example:

#if defined (ENABLE_VSC_EMMC_VIRT)
#if defined (ENABLE_VSC_UFS_VIRT)
#ifdef ENABLE_VSC_QSPI0_VIRT

Optional : 
#ifdef ENABLE_VSC_QSPI1_VIRT
#ifdef ENABLE_VSC_SDMMC1_VIRT

• Add the following line to that block

#if defined(PLATFORM_<BOARD NAME>)
 /* <partition name>  */
 [GOS0_VSC_Q_<#>] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .nframes = 16, .frame_size = SZ_128 },
#endif

• Within the block of defining <VM><VM>M<#> , locate the pre-processor associated with the storage device type you are adding a partition to. Example:

#f defined (ENABLE_VSC_EMMC_VIRT)
#if defined (ENABLE_VSC_UFS_VIRT)
#ifdef ENABLE_VSC_QSPI0_VIRT

Optional : 
#ifdef ENABLE_VSC_QSPI1_VIRT
#ifdef ENABLE_VSC_SDMMC1_VIRT

• Add the following line to that block

#if defined(PLATFORM_<BOARD NAME>)
 /* <partition name>  */
 [GOS0_VSC_M_<##>] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .nframes = 16, .frame_size = SZ_128 },
#endif

The new IVC number added in previous step as <#>, and the new mempool number added in the previous step as <##>, need to be added in two configurations files:

• In the storage configuration file where the new partition was added the following new attributes need to be added.

  • The last four string(Two HEX values) in virtual_storage_ivc_ch are the hexadecimal representation of the memory pool and IVC channel (<mempool><IVC>).

partition_attribute=<GID_GUEST0_VM+1>
virtual_storage_ivc_ch=0x8<GID_VSC_SERVER>00<HEX##><HEX#>

• The 32-bit virtual_storage_ivc_ch value can be broken down as follows:

The presence of the partitions to be used by the QNX VM is defined in its device tree via the following file:

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

  • Each partition has a node describing it. example:

tegra_virt_storage0 {                                       <<== required name, number is incrementing
    	 compatible = "nvidia,tegra-hv-storage";            <<== required field, as is
    	 status = "okay";                                   <<== required field, as is
    	 instance = <0>;                                    <<== instance id 0..n for each device type. This will determine node name in QNX File System
    	 ivc = <&tegra_hv #>;                               <<== ivc number used <#> in decimal
    	 mempool = <##>;                                    <<== mempool number used <##> in decimal
    	 device-type = "vblk_mnand";                        <<== one of "vblk_mnand", "vblk_sifs", "vblk_ufs"
    	 partition-name = "usr-fs";                         <<== partition name as defined earlier in storage configuration files.
    	 read-only;                                         <<== optional token for read-only partition. omit if read/write
};

Constraints

1. QNX OS expects the partition layout in a specific order. Refer to the chapter Mass Storage Partitions Configuration in NVIDIA DRIVE OS 6.0 Linux PDK Developer Guide or NVIDIA DRIVE OS 6.0 QNX Development Guide.

2. Partition sizes should be 256K aligned.

3. IVC queue number should be smaller than 256.

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:

2nd Level Partition Table(L2PT) Layout

• l2pt_qspi 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.

• l2pt_qspi_c QSPI Chain-C Layout

• emmc-part eMMC and UFS partitions

The eMMC/UFS device connected to 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:

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

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 3rd level(L3), a container partition needs to be added at 2nd 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>

Where:

• <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>805131

Note:

IVC Channel(0x31=49) and Mempool(0x51=81) used in virtual_storage_ivc_ch are subject to availability. Refer to platform_config.h and platform_ivc_config.h for available IVC/Mempool Ids.

Note:

partition_attribute is described in "Mass Storage Partition Configuration / Customizing the Configuration File / Setting Attributes / Partition Attributes Table" of NVIDIA DRIVE OS 6.0 Linux SDK Developer Guide.

or

"Storage / Mass Storage Partition Configuration / Customizing the Configuration File / Setting Attributes / Partition Attributes Table" of 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:

	       [49] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .nframes = 1, .frame_size = 128 },

Mempool entry:

	       [81] = { .peers = {GID_GUEST0_VM, GID_VSC_SERVER}, .size = (SZ_1MB * 8), .align = (SZ_1MB * 2) },

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_storage32 {
        compatible = "nvidia,tegra-hv-storage";
        status = "okay";
        instance = <10>;
        ivc = <&tegra_hv 49>;
        mempool = <81>;
        device-type = "vblk_mnand";
        partition-name = "custom";
    };

    NOTE: Ensure tegra_virt_storage32 is unique in the above mentioned dtsi file.
        Pick a different instance of tegra_virt_storage, if tegra_virt_storage32 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 */

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_storage32 {
        compatible = "nvidia,tegra-hv-storage";
        status = "okay";
        instance = <40>;
        ivc = <&tegra_hv 49>;
        mempool = <81>;
    };

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

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 2MB. 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_mnanda0, then the individual partitions are /dev/vblk_mnanda0.ms.0, /dev/vblk_mnanda0.ms.1, and /dev/vblk_mnanda0.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

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