5. PSDK QNX Components¶
5.1. QNX BSP release¶
The QNX BSP package must be downloaded from QNX Software Center.
Note
Refer Release Notes software dependencies section for more information.
For the purposes of creating a consolidated build process and in turn allowing for support of scripts to create SD content, the BSP needs to be extracted to the folder within the PSDK QNX build environment as show below.
For QNX SDP 800:
# Unzip the BSP
mkdir -p ${PSDK_RTOS_PATH}/psdkqa/qnx/bsp
cd ${PSDK_RTOS_PATH}/psdkqa/qnx/bsp
unzip ${QNX_BASE}/bsp/BSP_ti-j721e-am752x-evm_br-hw-rel_be-800_<version>.zip
5.1.1. TI Modifications to the BSP¶
Memory Carveout
Memory sections with pre-defined physical addresses must be set aside in the QNX BSP IFS build file so that the memory is not given to other programs and can be used solely by the remote cores.
Specify a section to be set aside by modifying the startup line to use the “-r” option. To reserve 0x60000000 bytes, starting at physical address 0xA0000000, on J7 QNX BSP, the build file the arguments would be (highlighted below):
[+keeplinked] startup-j721s2-evm -v -r0xA0000000,0x60000000,1 -r0x880000000,0x10000000,1
Note
- For vision apps remote cores, the memory carveout is at address 0xA0000000 and of size 0x60000000.
The initial remote core carevout 0x60000000 is in the lower 4GB memory range starting at address 0xA0000000.
The remaining remote core carevout 0x10000000 is in the higher 4GB memory range starting at address 0x880000000.
R5 Display support
For R5 Display support, the Startup need to be provided with -d option to specify not to configure the DSS and eDP.
[+keeplinked] startup-j721e-evm -v -r0xA0000000,0x60000000,1 -r0x880000000,0x10000000,1 -d
Reference TI build file
The reference TI build file is provide in the qnx/scripts/bsp/<BSP_REVISION> directory.
# Copy in TI specific build scripts and settings to allow building of a QNX-IFS which supports
# vision_apps demos
cp ${PSDK_RTOS_PATH}/psdkqa/qnx/scripts/bsp/<BSP_REVISION>/j721e-evm-ti.build ${PSDK_RTOS_PATH}/psdkqa/qnx/bsp/images/
Note
Other build file deltas between QNX and TI PSDK QNX environment may be present. TI modifies build scripts for ease of use on TI EVM and running of demonstration software.
5.2. QNX Screen release¶
The QNX Screen package must be downloaded from QNX Software Center.
The QNX Screen package must be installed and running for GPU support.
The QNX Screen package can optionally control the DSS (Display) from the A72, the PSDK QNX package default is R5 control of the DSS.
Note
Refer Release Notes software dependencies section for more information.
5.3. QNX 7.1 Dependency Packages¶
The QNX 7.1 dependency packages must be downloaded from QNX Software Center.
Note
Refer Release Notes software dependencies section for more information.
5.4. SCI Client Resource Manager¶
The SCI Client Resource Manager (tisci-mgr) provides support for multiple users to make use of the sciclient library from PSDK RTOS without interfering with each other requests. It provides a mechanism to serialize the transactions to the DMSC.
Note
The tisci-mgr logs the SYSFW information to the slogger.
Note
Refer PSDK RTOS Components for more information about each individual component.
5.5. IPC Resource Manager¶
5.5.1. Overview¶
The IPC resource manager (tiipc-mgr) provides a processor-agnostic API which can be used for communication between processors in a multi-processor environment.
The IPC resource manager provides a user library (tiipc-usr) that exposes the IPC LLD API to QNX applications for communication through the IPC resource manager. The IPC LLD API is described in detail in the PDK documentation.
Note
The size of the input buffer passed to the RPMessage_recv() API MUST be 528 (IPC_RPMESSAGE_MSG_BUFFER_SIZE) bytes.
5.5.2. Example Application¶
An IPC example application (ipc_test) is provided to test the IPC communication with remote cores running the IPC echo test remote core firmware images.. To use this application, the appropriate remote core firmware images need to be built and placed on the target filesystem. The following remote core firmware images are needed:
Firmware Name |
Core(s) |
|---|---|
ipc_qnx_echo_testb_freertos |
use for mcu1_0 |
ipc_qnx_echo_test_freertos |
use for mcu2_0, mcu2_1, mcu3_0,mcu3_1, C66x_1, C66x_2 & C7x_1 |
For remote core firmware build instructions, please refer to the IPC LLD PDK documentation.
Note
The below step to copy the remote core firmware to the rootfs partition of target filesystem is applicable only to the SPL-UBOOT bootflow. For the SBL-BootApp bootflow, the ipc echo test image need to be bundled into the Appimage. Please refer to the MCUSW documentation for details.
Once the remote core firmware is built, copy the images to the target filesystem in the rootfs partition. Existing firmware binaries should be backed up as required. The ex02* firmware binaries should be renamed to the firmware name expected by the bootloader. For example:
cp ipc_qnx_echo_test_freertos_c7x_1_release.xe71 ${ROOTFS}/lib/firmware/j7-c71_0-fw
cp ipc_qnx_echo_test_freertos_c66xdsp_1_release.xe66 ${ROOTFS}/lib/firmware/j7-c66_1-fw
cp ipc_qnx_echo_test_freertos_c66xdsp_2_release.xe66 ${ROOTFS}/lib/firmware/j7-c66_0-fw
cp ipc_qnx_echo_test_freertos_mcu3_1_release.xer5f ${ROOTFS}/lib/firmware/j7-main-r5f1_1-fw
cp ipc_qnx_echo_test_freertos_mcu3_0_release.xer5f ${ROOTFS}/lib/firmware/j7-main-r5f1_0-fw
cp ipc_qnx_echo_test_freertos_mcu2_1_release.xer5f ${ROOTFS}/lib/firmware/j7-main-r5f0_1-fw
cp ipc_qnx_echo_test_freertos_mcu2_0_release.xer5f ${ROOTFS}/lib/firmware/j7-main-r5f0_0-fw
Note
As seen above, the mcu1_0 firmware image is not copied to the target filesystem in the rootfs partition. Instead it need to be built into the tispl.bin as part of the SPL-UBOOT boot binaries.
For testing ipc with mcu1_0 image, the PSDK Linux package is required to be installed. The default SPL-UBOOT binaries include the ipc test mcu1_0 image that work with Linux only. Hence for QNX, we need to rebuild the SPL-UBOOT to include the “ipc_qnx_echo_testb_freertos_mcu1_0_release” image.
Below are the steps to do this:
Build “ipc_qnx_echo_testb_freertos_mcu1_0_release” image.
cd ${PSDK_RTOS_PATH}/pdk_jacinto_{version}/packages/ti/build
make -s ipc_qnx_echo_testb_freertos BOARD=j721e_evm CORE=mcu1_0 -j2
Copy the generate mcu1_0 firmware image to the PSDK Linux path mentioned below and rebuild UBOOT.
cp ${PSDK_RTOS_PATH}/pdk_jacinto_{version}/packages/ti/binary/ipc_qnx_echo_testb_freertos/bin/j721e_evm/ipc_qnx_echo_testb_freertos_mcu1_0_release_strip.xer5f ${PSDK_LINUX_PATH}/board-support/prebuilt-images/ti-dm/j721e/ipc_echo_testb_mcu1_0_release_strip.xer5f
cd ${PSDK_LINUX_PATH}
make u-boot_clean
make u-boot
Copy the newly generated UBOOT file to the SD card boot partition
cd ${PSDK_LINUX_PATH}/board-support/u-boot_build/r5/tiboot3.bin ${BOOTFS}
cd ${PSDK_LINUX_PATH}/board-support/u-boot_build/a72/tispl.bin ${BOOTFS}
cd ${PSDK_LINUX_PATH}/board-support/u-boot_build/a72/u-boot.img ${BOOTFS}
After copying the firmware and booting the target, the ipc_test can be run from the command line (example output given below):
J7EVM@QNX:/# /sd/tibin/ipc_test
IPC_echo_test (core : mpu1_0) .....
responderFxn will stay active. Please use ctrl-c to exit the test when finished.
SendTask9: mpu1_0 <--> C7X_1, Ping- 10, pong - 10 completed
SendTask1: mpu1_0 <--> mcu1_0, Ping- 10, pong - 10 completed
SendTask7: mpu1_0 <--> C66X_1, Ping- 10, pong - 10 completed
SendTask8: mpu1_0 <--> C66X_2, Ping- 10, pong - 10 completed
SendTask6: mpu1_0 <--> mcu3_1, Ping- 10, pong - 10 completed
SendTask5: mpu1_0 <--> mcu3_0, Ping- 10, pong - 10 completed
SendTask3: mpu1_0 <--> mcu2_0, Ping- 10, pong - 10 completed
SendTask4: mpu1_0 <--> mcu2_1, Ping- 10, pong - 10 completed
Make sure that the tiipc-mgr is running before executing the ipc_test. Note that the test app will not exit. Press “ctrl+c” to exit
Note
Run “ipc-test -s” to avoid waiting for the user to exit the test using “ctrl+c”.
Note
If SPL-UBOOT boot flow is used, the ipc_test will not be able to communicate with mcu1_1. All other core will work. Note that mcu1_1 is not loaded with any firmware image.
Note
If SBL / BootApp boot flow is used, the ipc_test will not be able to communicate with mcu1_0, & mcu1_1. All other core will work.
Note
Refer PSDK RTOS Components for more information about each individual component.
5.6. UDMA Resource Manager¶
The UDMA resource manager (tiudma-mgr) provides support for multiple users to make use of the UDMA functionality without interfering with each other requests.
Note
Refer PSDK RTOS Components for more information about each individual component.
5.8. CPSW2G DEVNP driver (Deprecated)¶
Note
The DEVNP driver is specific to QNX SDP 7.1 based releases only. This driver is deprecated and no longer provided in the SDK by default. If using SDP 7.1 and support for the DEVNP driver is required for your application, please contact your Texas Instruments representative for further assistance. For more information refer to the developer note CPSW Ethernet driver support - io-sock vs io-pkt.
5.9. CPSW9G DEVNP driver (Deprecated)¶
Note
The DEVNP driver is specific to QNX SDP 7.1 based releases only. This driver is deprecated and no longer provided in the SDK by default. If using SDP 7.1 and support for the DEVNP driver is required for your application, please contact your Texas Instruments representative for further assistance. For more information refer to the developer note CPSW Ethernet driver support - io-sock vs io-pkt.
5.10. K3conf QNX utility¶
K3CONF is a QNX port of a standalone application designed to provide a quick’n easy way to dynamically diagnose Texas Instruments’ K3 architecture based processors. K3CONF is intended to provide similar experience to that of OMAPCONF that runs on legacy TI platforms.
Note
WARNING: This is work in progress! Please don’t expect things to be complete in any dimension. Use at your own risk. And keep the reset button in reach.
To get more details on how to use k3conf utility, run below:
k3conf --help
5.11. TIHWMON utility¶
The TIHWMON utility is used to monitor/reports various aspects of the TI SoC. Launch the TIHWMON using the following command-line.
ti-hwmon
The current implementation monitors the following information:
5.11.1. DIEID¶
A 4 word identifier for the TI J7 SOCs. To get this value execute the following command on your serial console
cat /dev/tihwmon/dieid
5.11.2. VTM Juntion temperatures¶
The VTM junction temperatures are reported based on the various thermal zone available on the SoC. Please refer to the TRM for more details regarding the VTM module. To list the thermal zones available, use
ls /dev/tihwmon/vtm/
To get the temperature in centi-Celsius (hundredths of degrees C Eg: 25.05 Deg C = 2505 centi-Celsius) for a thermal zone, use the following command
cat /dev/tihwmon/vtm/thermal_zoneX
where X is an index to a zone from 0 to the max num of zone supported - 1 .
5.11.3. Helper script for ti-hwmon¶
A helper script is provided in the ti_fs/scripts/ folder to start and monitor the thermal zone values and export it into a csv format.
Use get_thermal_data.sh -h for usage details. For eg:
get_thermal_data.sh -run_time=60 --polling_rate=100 --csv_output=/tmp/thermal_data.csv
5.12. VXE384MP2 Video Encoder¶
5.12.1. Overview¶
The VXE384MP2 core PowerVR® VPU (video processor unit) from Imagination Technologies is a HD Codec that supports the H.264/AVC video format. It provides high performance encode capability for 8-bit YUV video up to 1080p @60fps.
Encoder:
Capable of encoding H.264/AVC Baseline/Main/High Profiles.
Capable of encoding 1x 1080p60 video stream or 2x 1080p30 video streams.
Codec Constraints:
Encoder Minimum picture resolution: 128x48
Encoder Maximum picture resolution: 2048x2048
Note: the VXE384MP2 can handle the higher resolution, shown above, but frame-rate performance will be limited
Multiple concurrent encode streams:
Number of concurrent streams is dependent on the resolutions and frame rates required
5.12.2. Usage¶
An OMX IL Component for the IMG video encoder and a File-based OMX encoder test application is provided.
For more details, run the use command for: omxil_video_enc
$ use omxil_video_enc
This is a test application for OpenMAX IL video encode.
It takes input frames from a .yuv file and encodes them to a H.264 bitstream file.
Syntax:
omxil_video_enc <options>
Options:
-h: help
-v: increase verbosity, max 7
-n: stdin not used (no command-line inputs taken)
-i: input file
-o: output file
-c: config file for encoder parameters
-d: disable display
-f input format for raw input (.yuv/.rgba/etc.)
e.g.: nv12,1920x1080@30
nv12 is the input color format
1920x1080 is resolution(width x height)
30 is frame rate.
Supported input format: nv12.
Examples:
# Basic built-in help:
omxil_video_enc -h
# AVC file-to-file encode:
omxil_video_enc -v -i /ti_fs/codec_test/nv12/8bit_BQTerrace_720x128_9frame_nv12.yuv -o /ti_fs/codec_test/output/8bit_BQTerrace_720x128.264 -d -f nv12,720x128@30
# AVC file-to-file encode, with config file specified to override default bitrate, etc. :
cp ti_fs/codec_test/nv12/mix_1920x1080_8b_10frm_nv12.yuv /tmp/
omxil_video_enc -v -i /tmp/mix_1920x1080_8b_10frm_nv12.yuv -c /ti_fs/codec_test/encoder_parameters.conf -o /tmp/mix_1920x1080.264 -d -f nv12,1920x1080@30
5.13. D5520MP2 Video Decoder¶
5.13.1. Overview¶
The D5520MP2 dual-core PowerVR® VPU (video processor unit) from Imagination Technologies is a 4K Codec that supports both HEVC and H.264/AVC video formats. It provides high performance decode capability for 8-bit or 10-bit YUV video up to 4K @60fps.
NOTE: In the current release, only 8-bit YUV(NV12) video is supported.
Decoder:
Capable of decoding H.265/HEVC Main and Main Still Picture Profiles @ L5.1 High tier.
Capable of decoding H.264/AVC Baseline/Main/High Profiles @ L5.2.
Capable of decoding 1x 4K @60fps video stream or 2x 4K @30fps video streams.
Maximum Resolutions Supported:
AVC Decoder Maximum resolution: 4096x4096
HEVC Decoder Maximum resolution: 8192x8192
Note: the D5520MP2 can handle the high resolutions, above, but frame-rate performance will be limited
Codec Constraints:
Decoder Minimum resolution: 64x64
Multiple concurrent decode streams:
Number of concurrent streams is dependent on the resolutions and frame rates required
5.13.2. Usage¶
An OMX IL Component for the IMG video decoder and a File-based OMX decoder test application is provided.
For more details, run the use command for: omxil_video_dec
$ use omxil_video_dec
This is a test application for OpenMAX IL video decode.
It takes H.264/HEVC frames from a file, decodes and displays them,
or decodes and saves the decoded frames in another file.
Syntax:
omxil_video_dec <options>
Options:
-i: input file
-o: output file, save output to file
-v: increase verbosity, max 7
Examples:
# AVC file-to-file decode:
omxil_video_dec -v -i /ti_fs/codec_test/bitstream/example.264 -o /ti_fs/codec_test/output/example_nv12.yuv
# HEVC file-to-file decode:
omxil_video_dec -v -i /ti_fs/codec_test/bitstream/example.265 -o /ti_fs/codec_test/output/example_hevc_nv12.yuv