PCT Profile Flags and Customization#

PCT Profile Makefile#

PCT profile makefile contains variables and their values specific to a given PCT variant.

The two types of variables defined in this Makefile are as follows:

  1. Build Flags for preprocessing various DriveOS configuration files

  2. Macros substituted in Storage Configuration files

Location: For a given PCT variant, the profile makefile can be found at:

<SDK_TOP>/platform-config/hardware/nvidia/platform/<SOC>/automotive/pct/<domain>/<pct>/profile_<pct_variant>.mk

The bind_partitions arguments determine <domain>, <pct>, and <pct_variant>. For example, for the bind_partitions command:

bind_partitions -b <board-name> drive_av.linux -p prod_nsr

The corresponding profile makefile used is:

<SDK_TOP>/platform-config/hardware/nvidia/platform/<SOC>/automotive/pct/drive_av/linux/profile_prod_nsr.mk

This profile makefile contains the variables and their values specific to the prod_nsr PCT variant.

Refer to <SDK_TOP>/foundation-t264/meta/pct/pct_configuration_v2.yaml for the list of supported PCT variants.

Note

Replace <SOC> with the chip variant you are working with, for example, t23x or t264.

Build Flags for Preprocessing DriveOS Configuration Files#

Device-tree files and storage configuration files are preprocessed using the C preprocessor. Three types of build flags are used for preprocessing, with each flag type targeting different components:

  1. CFLAGS: Used for preprocessing:

    • Storage configuration files

    • Server DTS files

    • platform_config_profile.json (this JSON file passes flags from bind_partitions to create_bsp, which impacts the BCT DTS)

    • PCT files

  2. BFLAGS: Used for preprocessing:

    • Storage configuration files

  3. EXTRA_GOS_DTB_CCFLAGS: Used for preprocessing:

    • BPMP DTS files

    • GOS DTS files

Automatic Flag Addition to Build Flags#

In the legacy workflow (now deprecated), when a new profile Makefile variable was added, build files (build.mk / build-flags-<ARCH>*.mk) required modification to convert these variables to preprocessor defines (CFLAGS, BFLAGS, and so on). The new workflow does not require changes to build files, and required preprocessor defines are automatically generated using the following rules:

  • Boolean Flags

    For variables of the form FLAG=y or FLAG=n. Flags of these types are automatically added to CFLAGS, BFLAGS, and EXTRA_GOS_DTB_CCFLAGS as -DVARIABLE_NAME when the value is set to y.

    Example: If ENABLE_LCM=y is set in the profile makefile.

    Legacy Workflow: Following had to be manually added in build flags makefile:

    ifeq ($(ENABLE_LCM),y)
    CFLAGS += -DENABLE_LCM
    BFLAGS += -DENABLE_LCM
    EXTRA_GOS_DTB_CCFLAGS += -DENABLE_LCM
    endif
    

    Current Workflow: -DENABLE_LCM is automatically added as part of the preprocessing step for all files that use CFLAGS/BFLAGS and EXTRA_GOS_DTB_CCFLAGS.

  • CPU Assignment Flags

    These are variables with names that end with CPU_NO and do not contain GUEST as a substring (for example, BPMP_SERVER_CPU_NO, ETHERNET_SERVER_CPU_NO). Values must be non-empty. These variables are automatically added to CFLAGS as -DVARIABLE_NAME=VARIABLE_VALUE.

    Example: If ETHERNET_SERVER_CPU_NO=3 is set in the profile makefile.

    Legacy Workflow: The following had to be manually added in build flags makefile:

    ifneq ($(ETHERNET_SERVER_CPU_NO),)
    CFLAGS += -DETHERNET_SERVER_CPU_NO=$(ETHERNET_SERVER_CPU_NO)
    endif
    

    Current Workflow: -DETHERNET_SERVER_CPU_NO=3 is automatically added to CFLAGS as part of preprocessing step for all files that use CFLAGS.

  • BOARD_SKU Flags

    These are variables with names that start with BOARD_SKU_. Values must be non-empty. These variables are automatically added to BFLAGS as -DVARIABLE_NAME=VARIABLE_VALUE.

    Example: If BOARD_SKU_1=0x01 is set in the profile makefile.

    Legacy Workflow: Following had to be manually added in build flags makefile:

    ifneq ($(BOARD_SKU_1),)
    BFLAGS += -DBOARD_SKU_1=$(BOARD_SKU_1)
    endif
    

    Current Workflow: -DBOARD_SKU_1=0x01 is automatically added to BFLAGS as part of preprocessing step for all files that use BFLAGS.

Macro Substitution for Storage Configuration Files#

Storage configuration files can contain macros in the format <VARIABLE_NAME> that are automatically replaced with definitions from profile Makefiles as part of bind_partitions execution. Profile Makefile flags used for macro substitution can be with or without values.

Example 1: Profile Makefile flags with value

If OS_ARGS_CAR_PLATFORM=car_platform=v25 is set in the profile makefile.

Legacy Workflow: For each macro that needs to be replaced in storage configuration files (OS_ARGS_CAR_PLATFORM in this example), the following text replacement command was needed to be inserted into build-storage.mk:

sed -i 's|<OS_ARGS_CAR_PLATFORM>|$(OS_ARGS_CAR_PLATFORM)|g' $cfg; \

Current Workflow: The macro <OS_ARGS_CAR_PLATFORM> in storage configuration files is automatically replaced with car_platform=v25. No sed commands need to be added manually in build-storage.mk.

Example 2: Profile Makefile flags without value

If OS_ARGS_QNX_GOS0_SIFS_2 is empty or not defined in the profile makefile.

Legacy Workflow: Following had to be manually added in build-storage.mk:

sed -i 's|<OS_ARGS_QNX_GOS0_SIFS_2>|$(OS_ARGS_QNX_GOS0_SIFS_2)|g' $cfg; \

Current Workflow: The macro <OS_ARGS_QNX_GOS0_SIFS_2> in storage configuration files is automatically replaced with an empty string.

Exclude List Support#

By default, all variables matching the patterns described above are automatically processed. To prevent specific variables from being processed by the automation, add them to the corresponding exclude list in the profile makefile.

Two exclude lists are available:

  • EXCLUDE_LIST_BUILD_FLAGS – Variables listed here are not automatically added to CFLAGS, BFLAGS, or EXTRA_GOS_DTB_CCFLAGS during preprocessing.

  • EXCLUDE_LIST_STORAGE_MACRO_REPLACEMENT – Variables listed here are not automatically replaced in storage configuration files during bind_partitions.

To use the exclude lists, add them to the profile makefile with +=:

EXCLUDE_LIST_BUILD_FLAGS += MY_CUSTOM_FLAG
EXCLUDE_LIST_STORAGE_MACRO_REPLACEMENT += OS_ARGS_MY_VARIABLE

Important

Summary: Profile Flag Configuration Guidelines

To add a profile flag (e.g., ENABLE_CBA) or define a storage macro (e.g., OS_ARGS_CAR_PLATFORM), only do the following:

# Correct: Define the flag/variable in the profile makefile
ENABLE_CBA := y
OS_ARGS_CAR_PLATFORM := car_platform=v25

Warning

Do not do the following:

# Wrong: Never add profile flags directly to build flags makefiles
ifeq (y,$(PROD_DEBUG_IMG))
ENABLE_CBA := y
EXTRA_GOS_DTB_CCFLAGS += -DENABLE_CBA
endif
# Wrong: Never add sed statements for macro substitution in build-storage.mk
sed -i 's|<OS_ARGS_CAR_PLATFORM>|$(OS_ARGS_CAR_PLATFORM)|g' $cfg; \

Since the build system automatically propagates these flags for preprocessing and substitution (as mentioned under Current Workflow sections above), do not manually add -D definitions for profile flags in any other build files or any sed statements for macro substitution. The build system automatically propagates and applies them where required. Manual modifications outside the profile makefile are unnecessary and strongly discouraged.

Adding a New PCT Profile Makefile#

Each customer configuration is expressed as its own PCT profile makefile. This approach provides isolation between different customer configurations while allowing shared common components.

To add a new customer profile named <customer-profile>, follow these steps:

  • Add profile_<pct_variant>.mk at: <SDK_TOP>/platform-config/hardware/nvidia/platform/<ARCH>/automotive/pct/<domain>/<pct>/profile_<customer-profile>.mk

  • Register the profile in <SDK_TOP>/foundation-t264/meta/pct/pct_configuration_v2.yaml.

    The profile must be added in two sections: board_configs and Domains.

    # Section 1: board_configs
    board_configs:
      p3960-10-sw03:
        drive_av:
          linux:
            pct_variant: {dev_nsr, prod_nsr, <customer-profile>}
    
    # Section 2: Domains
    Domains:
      drive_av:
        linux:
          pct_variant: {dev_nsr, prod_nsr, <customer-profile>}
    
  • Invoke with bind_partitions:

    bind_partitions -b <board-name> <domain>.<pct> -p <customer-profile>
    

PCT Profile Makefile Content Format#

A typical PCT profile makefile follows this format:

Example profile makefile - profile_<customer_profile>.mk:

include common_profile.mk
include common_profile_cpu_assign.mk

# -- Flag addition logic --

# Boolean flags for enabling features
ENABLE_LCM := y
ENABLE_CBA := y

# CPU assignment flags
ETHERNET_SERVER_CPU_NO := 3
BPMP_SERVER_CPU_NO := 0

# Storage configuration macros
OS_ARGS_CAR_PLATFORM := car_platform=v25
OS_ARGS_EXTRA_PARAMS := console=ttyTCU0,115200

# Exclude lists (optional)
EXCLUDE_LIST_BUILD_FLAGS += MY_CUSTOM_FLAG
EXCLUDE_LIST_STORAGE_MACRO_REPLACEMENT += OS_ARGS_MY_VARIABLE

# -- End of Flag addition logic --

include $(BUILD_MK_PATH)/server-partitions.mk
include $(BUILD_MK_PATH)/storage-config.mk

Note

When a new profile is created, <SDK_TOP>/foundation-t264/meta/pct/pct_configuration_v2.yaml must be updated.

PCT Profile Creation Guidelines#

Customers typically need to add new PCT flags or modify flags that are set by default in DriveOS PCT profile Makefiles. The recommended method to do that is to create a new PCT profile Makefile by following these guidelines:

Allowed Practices:

  • Copy the closest existing reference profile: Start with an existing profile that most closely matches your requirements. Copy it to create a new profile, and then modify the copied file as needed. The copied file will already include the NVIDIA internal common profile makefiles (such as common_profile.mk and common_profile_cpu_assign.mk), which provide common macros for VMs, CPUs, and other shared configurations.

    Reference profile: Reference profile can be found in the directory: <SDK_TOP>/platform-config/hardware/nvidia/platform/<ARCH>/automotive/pct/<domain>/<pct>/profile_<reference_profile>.mk

    # Copy existing profile as starting point
    cp profile_<reference_profile>.mk profile_<customer_profile>.mk
    # Then modify the new file as needed
    
  • Define customer-specific flags: Add flags specific to your customer configuration.

    # Customer-specific feature enables
    ENABLE_CUSTOMER_FEATURE_X := y
    
  • Toggle variables as needed: Modify variables defined in the profile makefile or variables coming from included files (such as common_profile.mk or common_profile_cpu_assign.mk) in your copied customer profile makefile.

    # Toggle variables from reference profile or included files
    SOME_EXISTING_FLAG := n
    
  • Use exclude lists to skip automation for specific variables: If certain variables should not be automatically processed by the build system, add them to the appropriate exclude list. See Exclude List Support for details.

    EXCLUDE_LIST_BUILD_FLAGS += MY_CUSTOM_FLAG
    EXCLUDE_LIST_STORAGE_MACRO_REPLACEMENT += OS_ARGS_MY_VARIABLE
    

Note

In the future, for variables that are defined in the reference profile makefile or coming from included files, only a subset of these variables will be designated as customer-configurable. A list of allowed customer-configurable variables will be published and enforced.

Prohibited Practices:

  • Do not inherit or override from other customer profile makefiles: When creating a profile, only use the files from the directory as a reference and modify it as needed: <SDK_TOP>/platform-config/hardware/nvidia/platform/<ARCH>/automotive/pct/<domain>/<pct>/profile_<reference_profile>.mk as your starting point.

  • Do NOT use previously cloned or modified profile files from other locations as a base. Always clone directly from the above directory to ensure a clean and isolated configuration.

# Wrong approach - Don't do this
include profile_other_customer.mk
ENABLE_SOME_FLAG := n  # Overriding value from other profile

Benefits of Profile Isolation:

  • Clean separation: Each customer has their own isolated configuration.

  • No conflicts: Changes to one customer profile don’t affect others.

  • Easy maintenance: Customer-specific changes stay in customer-specific files.

  • Reduced merge conflicts: Multiple developers can work on different profiles simultaneously.

  • Leverages patterns: Profile flags automatically get added to compilation variables as documented in previous sections.

Migrating from a Legacy Workflow#

This section is about moving from a legacy workflow to the current workflow supported from release 7.2.2.0.

Since preprocessor flag generation and storage configuration macro substitution are now handled automatically by the build system (see Build Flags for Preprocessing DriveOS Configuration Files and Macro Substitution for Storage Configuration Files), any manual additions in the build flags makefile (such as CFLAGS/BFLAGS/EXTRA_GOS_DTB_CCFLAGS) or sed replacements in build-storage.mk can be removed. Follow the migration steps below to clean up these files.

Migrating Build Flags Makefile#

Step 1: Identify previous build file (build.mk / build-flags-<ARCH>*.mk) changes#

Review the build flags makefile for manual flag additions that match the patterns that customer would have added for previous releases in files of type build_flags_<ARCH>.mk.

Example of manual additions that are no longer needed:

# Manual additions that are no longer needed
ifeq ($(ENABLE_LCM),y)
CFLAGS += -DENABLE_LCM
BFLAGS += -DENABLE_LCM
EXTRA_GOS_DTB_CCFLAGS += -DENABLE_LCM
endif

Step 2: Remove changes in build files that support PCT profile Makefile flags#

In your build flags makefiles (such as build.mk / build-flags-<ARCH>*.mk), remove flags added for previous DriveOS versions. Refer to the previous sections for relevant patterns.

  • “Build Flags for Preprocessing various DRIVEOS configuration files”

  • “Step 1: Identify Manual Flag Additions” (see example patterns)

Note

If any of the removed variables should not be automatically added to build flags, add them to EXCLUDE_LIST_BUILD_FLAGS in your profile makefile. See Exclude List Support for details.

Step 3: Create a new customer profile makefile#

Create a new customer profile makefile by copying an existing reference profile and modifying it as needed. Refer to PCT Profile Creation Guidelines for instructions on creating a new profile makefile.

Step 4: Validate#

After removing manual flag additions, test the build to ensure the following:

  • Flags are added correctly to CFLAGS, BFLAGS, and EXTRA_GOS_DTB_CCFLAGS

  • All expected preprocessor definitions are present in the build output

Migrating build-storage.mk#

Step 1: Find Sed Replacements#

Review the build-storage.mk file for manual sed commands that perform variable replacements.

Example of manual sed replacements that are no longer needed:

# Manual sed replacements that are no longer needed
sed -i 's|<OS_ARGS_CAR_PLATFORM>|$(OS_ARGS_CAR_PLATFORM)|g' $cfg; \

Step 2: Remove changes in build-storage.mk that support PCT profile Makefile flags#

Remove manual sed replacement commands from build-storage.mk for standard <VARIABLE>$(VARIABLE) replacements since they will be handled automatically by the automation.

What to remove: Any sed command that follows the pattern:

sed -i 's|<VARIABLE_NAME>|$(VARIABLE_NAME)|g' $cfg; \

For detailed information on macro substitution, refer to Macro Substitution for Storage Configuration Files.

Note

If any of the removed variables should not be automatically replaced in storage configuration files, add them to EXCLUDE_LIST_STORAGE_MACRO_REPLACEMENT in your profile makefile. See Exclude List Support for details.

Step 3: Create a new customer PCT profile Makefile#

Create a new customer profile makefile by copying an existing reference profile (or use a customer profile makefile if already created for Migrating Build Flags Makefile) and modify it as needed. Refer to PCT Profile Creation Guidelines for instructions on creating a new profile makefile.

Step 4: Validate#

After removing manual sed commands, test the build to ensure that:

  • Macro replacements in storage configuration files are working correctly

  • All macros (<VARIABLE_NAME>) are being replaced with their expected values

  • No macros remains unreplaced in the generated configuration files