2. Getting Started


Processor SDK RTOS (PSDK RTOS) for J7200 needs to be downloaded separately.

2.1. Downloading and installing the PSDK QNX

2.1.1. Step 1: Install QNX Packages

  • In order to build for a QNX environment, there are multiple packages from QNX Software Center that must be installed. This includes the QNX SDP and related packages. Please refer to the Software Dependencies section of the Release Notes, for a list of those packages, and ensure they are installed on the host build machine.

  • Processor SDK QNX (PSDK QNX) supports & validated with QNX SDP 7.1 only. While installing the QNX SDP 7.1, the default install location is:

  • The QNX SDP 7.1 can be installed to any directory location, but please update the version and paths accordingly in:

    • ${PSDK_RTOS_PATH}/psdkqa/qnx/qnx_tools_path.mak

export QNX_SDP_VERSION ?= 710
ifeq ($(QNX_SDP_VERSION),700)
  export QNX_BASE ?= <your-sdp700-path>
  export QNX_CROSS_COMPILER_TOOL ?= aarch64-unknown-nto-qnx7.0.0-
 export QNX_BASE ?= <your-sdp710-path>
 export QNX_CROSS_COMPILER_TOOL ?= aarch64-unknown-nto-qnx7.1.0-

2.1.2. Step 2: Download PSDK RTOS and PSDK QNX


In order to download and compile some components from next step, it is required that your PC network proxy is setup properly in case it is not directly connected to internet.

  • The PSDK RTOS release can be downloaded from ti.com. [LINK]. The version of the PSDK RTOS and PSDK QNX release must be the same. The PSDK RTOS package needs to be installed in your build machine. Here after we’ll refer to this installation directory as $PSDK_RTOS_PATH

2.1.3. Step 3: Download & Install the PSDK QNX

  • Download the psdk qnx package (ti-processor-sdk-qnx_j7200_xx_xx_xx.tar.gz) and extract this to the $PSDK_RTOS_PATH.

tar -xvf ti-processor-sdk-qnx_j7200_xx_xx_xx.tar.gz -C $PSDK_RTOS_PATH


The above step would create the directory by name psdkqa. Please note that from now on $PSDK_RTOS_PATH/psdkqa will be referred at PSDK_QNX_PATH

  • Once the PSDK QNX package has been extracted, the ${PSDK_QNX_PATH}/psdk_qnx_setup_qnx710.sh can be run from the $PSDK_QNX_PATH folder to complete installation. Please check following variables is set correctly in the ${PSDK_QNX_PATH}/psdk_qnx_setup_qnx710.sh for the script to function correctly.

QNX_BSP_PATH=${QNX_BASE}/bsp/                                          (The location of the extracted bsp that was downloaded from QNX Software Center)
QNX_BSP_NAME=BSP_ti-j7200-evm_br-710_be-710_SVNxxxxxx_JBNyy.zip        (The QNX BSP zip file)
QNX_BSP_VERSION=710_SVNxxxxxx_JBNyy                                    (The QNX BSP version)
  • The QNX_BASE referenced is the location in which QNX SDP was installed. The script assumes the default location, if QNX SDP was installed elsewhere the path must be updated accordingly.


QNX Software Center would download the BSP archive by default to /home/$USER/qnx710/bsp, however user can modify this path.


Please refer to the Software Dependencies section of the Release Notes supported QNX BSP releases.

  • The BSP archive must be downloaded using QNX Software Center prior to running the psdk_qnx_setup_qnx710.sh script.

  • After modifying the ${PSDK_QNX_PATH}/psdk_qnx_setup_qnx710.sh script, launch it with the following command from the PSDK_QNX_PATH directory path.



Make sure to call the script from ${PSDK_QNX_PATH} as shown above.

  • The psdk_qnx_setup_qnx710.sh creates

    1. A QNX specific copy of the PDK in psdkqa/pdk

    2. A TI modified copy of the QNX BSP in psdkqa/bsp Additional setup

  • For PSDK QNX + PSDK RTOS package, we need to download and install additional dependencies. ‘sudo’ permission is required to run below script and install some components using apt-get. In case you don’t want to install packages with sudo permission pass below argument to this script



Open below file and install the packages installed with sudo apt install separately

  • Run the below to download and install additional dependencies needed to build PSDK QNX + PSDK RTOS



Make sure to call the script from ${PSDK_RTOS_PATH} as shown above. DO NOT “cd” into ${PSDK_RTOS_PATH}/psdkqa and call the script

2.2. PSDK QNX Build Options

The PSDK QNX provides a build environment to generate QNX binaries and libraries required for the J721E EVM to run in an QNX environment. The QNX binaries and libraries must be aligned with the firmware on the other cores of the J721E device. By default the PSDK QNX supports three different variants of firmware images, as described in the following sections. Each of the build options is exclusive and offers different features. The generated PSDK QNX binaries and libraries for each option will only function correctly provided that they are aligned with the firmware running on the remote cores, for that build option. When switching between the supported build options, a full scrub must be done.

2.2.1. PSDK QNX And Ethernet Firmware Images

This build option provides a QNX setup on the A72 along with support of the CPSW5G, and includes support of the required ethernet firmware image running on MCU2_0.

Please refer Build Steps for the detailed build instructions.

2.2.2. PSDK QNX And IPC Echo Test Firmware Images

This build option provides a QNX setup on the A72 with firmware images capable of support and IPC test setup.

Please refer Build Steps for the detailed build instructions.

2.3. Resource Managers

The PSDK QNX package provides A72 resource managers as described in PSDK QNX Components, for:

  • SCI

  • UDMA

  • IPC

  • Shared Memory Allocator

These resource managers must be launched during system initialization. Examples of this can be seen in ${PSDK_QNX_PATH}/qnx/scripts/user.sh. This script file is used during initialization, and is included in the SD card image generated by following:

2.4. PSDK QNX Boot Modes


Refer to PSDK RTOS documentation for detailed information boot modes, and boot flow.

The PSDK QNX addon package supports 3 different boot modes

  • SPL+Uboot(SD Boot)

  • SBL+BootApp(SD Boot) or SBL+CombinedBootImage(SD Boot)

  • SBL+CombinedBootImage(xSPI Boot)

The steps to get each of these boot modes running is covered in:

2.4.1. SPL+Uboot Boot

For the SPL/Uboot option, the following binaries are required, which are available as part of the PSDK Linux package:

  • R5 bootloader (tiboot3.bin),

  • A72 bootloader (tispl.bin),

  • U-boot (u-boot.img)

2.4.2. SBL Boot

For the SBL boot option, we use the SBL bootloader include as part of the PSDK RTOS package. Reference PSDK RTOS J7200 package documentation (LINK) for details.

When using the SBL / BootApp boot flow, be aware that the following set of resources are already configured prior to QNX starting. The settings are mostly done through usage of “Board_init()” calls in SBL or Boot App, which in turn call init functions in the Board library:

PLLs: Refer to the list PLLs that are initialized for both MCU & MAIN domains in the “gBoardPllClkCfgMcu[]” and “gBoardPllClkCfgMain[]” struct arrays, shown in the board_pll.c file here:

Clocks: Refer to the list of Clocks that are initialized for both MCU & MAIN domains in the “gBoardClkModuleMcuID[]” and “gBoardClkModuleMainID[]” arrays, shown in the board_clock.c file here:

Pinmux: on the J7200 EVM, the main boards and daughter boards are detected and basic pinmux setup is done for the primary functionality used with these boards. Any other functionality must be customized (for customer boards, etc.). The pinmux configuration is called using the function “Board_pinmuxConfig” in the file here:

Related MCU & MAIN domain pinmux selections are possible (depending on which daughter boards are connected to the main EVM), where configurations are shown in these files:

There are other files there for different EVM daughter boards, etc.

DDR: LPDDR4 memory is configured through the “Board_DDRInit()” function in file:

Boot media: The Boot App will leave the boot media (either OSPI flash or SD card) as previously used, but with handles closed and left in a state to allow the software on the A72 to take over control:

  • MMCSD boot: SD card has been released and is ready for HLOS to take control

  • OSPI flash: Flash is closed & re-initialized in SPI mode, so that the HLOS can reset the flash as needed and re-initialize with its own OSPI