.. _qnx_sdk_components_|dev_platform|:

************************************
PSDK QNX Components
************************************

QNX BSP release
================
The QNX BSP package must be downloaded from QNX Software Center.

.. NOTE::

   Refer :ref:`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 |qnx_sdp_version|:

.. code:: bash

   # Unzip the BSP
   mkdir -p ${PSDK_RTOS_PATH}/psdkqa/qnx/bsp
   cd ${PSDK_RTOS_PATH}/psdkqa/qnx/bsp

.. ifconfig:: QNX_SDP_VERSION in ('800')

  .. code:: bash

   unzip ${QNX_BASE}/bsp/BSP_ti-j721e-am752x-evm_br-hw-rel_be-800_<version>.zip

.. ifconfig:: QNX_SDP_VERSION in ('710')

  .. code:: bash

   unzip ${QNX_BASE}/bsp/BSP_ti-j721e-am752x-evm_br-mainline_be-710_<version>.zip


TI Modifications to the BSP
----------------------------

.. rubric:: Memory Carveout
   :name: 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):

.. code:: bash

   [+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.

.. rubric:: R5 Display support
   :name: 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.

.. code:: bash

    [+keeplinked] startup-j721e-evm -v -r0xA0000000,0x60000000,1 -r0x880000000,0x10000000,1 -d

.. rubric:: Reference TI build file
   :name: Reference TI build file

The reference TI build file is provide in the qnx/scripts/bsp/<BSP_REVISION> directory.

.. code:: bash

   # 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.

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 :ref:`release_notes` software dependencies section for more information.

QNX 7.1 Dependency Packages
================================

The QNX 7.1 dependency packages must be downloaded from QNX Software Center.

.. NOTE::

   Refer :ref:`release_notes` software dependencies section for more information.

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 :ref:`psdk_rtos_components_|dev_platform|` for more information about each individual component.


IPC Resource Manager
===========================

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.

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:

.. code:: bash

   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:

1. Build "ipc_qnx_echo_testb_freertos_mcu1_0_release" image.

.. code:: bash

   cd ${PSDK_RTOS_PATH}/pdk_jacinto_{version}/packages/ti/build
   make -s ipc_qnx_echo_testb_freertos BOARD=j721e_evm CORE=mcu1_0 -j2

2. Copy the generate mcu1_0 firmware image to the PSDK Linux path mentioned below and rebuild UBOOT.

.. code:: bash

   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

3. Copy the newly generated UBOOT file to the SD card boot partition

.. code:: bash

   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):

.. code:: bash

   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 :ref:`psdk_rtos_components_|dev_platform|` for more information about each individual component.


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 :ref:`psdk_rtos_components_|dev_platform|` for more information about each individual component.


Shared Memory Allocator
===========================

The Shared Memory Allocator resource manager (shmemallocator) provides support for multiple users to
allocate memory from the shared memory region. This shared memory region is carved out of the QNX memory as part
of the QNX Startup parameters.




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 :ref:`devnp_710_developer_note`.


.. ifconfig:: QNX_SDP_VERSION in ('710')

  **Overview**

  The CPSW2G DEVNP network driver can be viewed as the “glue” between the underlying cpsw2g low-level
  driver, and the software infrastructure of io-pkt, the protocol stack above it. The “bottom half” of the
  driver is coded specifically to interact with the PDK's cpsw & udma low-level drivers, and the “top half” of
  the driver is coded specifically for io-pkt.

  .. NOTE::

      Refer :ref:`psdk_rtos_components_|dev_platform|` for more information about each individual component.

  .. NOTE::

      The cpsw2g driver's CPTS interrupt thread must always be higher priority compared to the RX and TX threads of the driver.
      By default, the network stack thread is at priority 21. Hence the RX and TX thread are created at this priority level.
      The CPTS interrupt thread is created at priority 22. These priority values can be changed by providing them as command-line
      parameters. See driver *use* command.

  **Running**

  Boot the board with the SD card.
  At the QNX prompt, run below, to mount the SD card and then launch the executable:

  .. code:: bash

     tisci-mgr
     tiudma-mgr
     io-pkt-v6-hc -d cpsw2g
     dhclient -nw am0

  The cpsw2g driver configures all the driver created threads to have the runmask as 0x0 by default. This is to make sure
  all the threads run on core 0 of the A72. This can be configured with the *run_mask_cpu=* command-line option.
  See the *use* command or :ref:"Usage of devnp-cpsw2g.so" for further details.

  For debug traces, run the below command before starting the DEVNP driver and start the driver with
  increased verbose parameter (ex: verbose=0x3ff) this will show all the drivers slog messages.

  .. code:: bash

     slog2info -c
     slog2info -w &

  **Additonal steps**

  - Run "if_up -p am0" to check if the interface is ready
  - Run "ifconfig am0 up" to bring UP the link.
  - Run "dhclient -nw am0" for DHCP server provide the IP address
  - Run "ifconfig -v" to check the assigned IP address and status
  - Run "tcpdump -e" to look at the tcp traffic

  **Usage of devnp-cpsw2g.so**

  We can run the below command to get the usage of the DEVNP driver:

  .. code:: bash

     $ use devnp-cpsw2g.so

     devnp-cpsw2g.so mcu domain cpsw2g ethernet driver based on enet low level driver

     Syntax:
       io-pkt-v6-hc -d cpsw2g [option[,option ...]] ...

     Options (to override autodetected defaults):
       verbose=num             Set verbosity level (default: 0).
       mac-to-mac=1            Set for mac-to-mac mode (default: 0)
       speed=100|1000          Media data rate for port 0 in Mb/s. (default: 1000)
       p0mac=XXXXXXXXXXXX      Custom MAC address to use on port 0.
       ptp=0|1                 1 to enable PTP support (default: 0)
       promiscuous=0|1         1 to enable promiscuous mode (default: 0)
       typed_mem=name          Set the typed memory
       udma_chnum=val          Set the preferred udma channel to use (default: dynamic allocation)
       tx_freeq_threshold=val  Set the tx free Q threshold value (default: 120), must be less than no of TX descriptors.
       tx_descriptor_cnt=val   Set the tx descriptors count value (default: 128, Max: 256)
       rx_descriptor_cnt=val   Set the rx descriptors count value (default: 128, Max: 256)
       run_mask_cpu=val        Set the run mask - cpu core where threads are scheduled (default:0) (0 - core0, 1 - core1, 2 - both core)
       poll_phy_ms=val         Set the frequency in ms, to poll the phy status, and poll for management of resources (default: 2000)
       cache_ops=val           Set the cache operation to on/off (default:0  -> cache-coherency set), 1 - Turn on cache off -> cache-coherency off)
       smmu=0|1                1 to enable smmu support (default: 0)
       virt_id=val             Set the virt_id to use for the dma channel when smmu is enabled
       hw_csum=1               1 to enable hw csum (default: 0)
       joinvlan="1;2;3..."     List of VLANs to join
       rx_intr_prio=val        Set the rx interrupt thread priority (default: 21)
       tx_intr_prio=val        Set the tx interrupt thread priority (default: 21)
       cpts_intr_prio=val      Set the cpts interrupt thread priority (default: 22)
       no_stack_thread=val     1 to disable using the stack thread needed for bridge and fastforward to work  (default: 0)
       rx_pacing=0|1           1 to enable rx interrupt pacing (default:0, use rx interrupt)
       rx_pacing_msec=val      Set the rx interrupt pacing internal in msec (default: 1 msec)

     Examples:
       # Start io-pkt using the driver and with static IP address
       io-pkt-v6-hc -d cpsw2g
       ifconfig am0 192.0.2.1

       # Start io-pkt using the driver and with DHCP IP address
       io-pkt-v6-hc -d cpsw2g
       dhclient -nw am0

       # Start io-pkt using the driver for mac-to-mac mode in gitbit speed
       io-pkt-v6-hc -d cpsw2g verbose=1,mac-to-mac=1,speed=1000
       ifconfig am0 192.0.2.1

       # Start io-pkt using the driver with custom mac address
       io-pkt-v6-hc -d cpsw2g p0mac=001122334455
       ifconfig am0 192.0.2.1

       # Start io-pkt using the driver with typed memory "ram":
       io-pkt-v6-hc -d cpsw2g typed_mem=ram -ptcpip pkt_typed_mem=ram
       ifconfig am0 192.0.2.1

       # Start io-pkt using the driver with typed memory "ram", preferred udma channel "24" and smmu enabled:
       io-pkt-v6-hc -d cpsw2g ptp=1,typed_mem=ram,udma_chnum=24,smmu=1 -ptcpip pkt_typed_mem=ram
       ifconfig am0 192.0.2.1

       # Start io-pkt using the driver with hw csum enabled
       io-pkt-v6-hc -d cpsw2g hw_csum=1
       ifconfig am0 tcp4csum udp4csum tcp6csum udp6csum
       ifconfig am0 192.0.2.1


  **Starting driver with other options**

  To run the cpsw2g devnp driver with full debug log (run "slog2info" to see the debug log):

  .. code:: bash

     io-pkt-v6-hc –d cpsw2g verbose=0xff

  To run the cpsw2g devnp driver in mac-to-mac mode with 1Gbps:

  .. code:: bash

     io-pkt-v6-hc –d cpsw2g mac-to-mac=1,speed=1000

  To run the cpsw2g devnp driver in mac-to-mac mode with 1Gbps with gPTP:

  .. code:: bash

     io-pkt-v6-hc –d cpsw2g ptp=1,mac-to-mac=1,speed=1000

  To get a dynamic IP address for the cpsw2g port:

  .. code:: bash

     dhclient -nw am0

  To get a static IP address for the cpsw2g port:

  .. code:: bash

     ifconfig am0 up
     ifconfig am0 <static_ip_address>

  To enabled HW CSUM offloading support:

  .. code:: bash

     io-pkt-v6-hc -d cpsw2g hw_csum=1
     ifconfig am0 tcp4csum udp4csum tcp6csum udp6csum
     dhclient -nw am0


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 :ref:`devnp_710_developer_note`.

.. ifconfig:: QNX_SDP_VERSION in ('710')

  **Overview**

  The CPSW9G DEVNP network driver implemented as “virtual" driver that communicates with the Ethernet
  Firmware Switch firmware running on the R5 core. The control message transfer is done via IPC. The
  RX and TX data packets are passed to the CPSW9G port using the UDMA.

  CPSW9G Firmware on MCU2_0 implemented TimeSync Module utilizing CPTS timer for PTP support to sync with Master clock on the network.
  TimeSync module configured PTP stack with the following default properties.

  - Ordinary Clock
  - IEEE 802.3 Transport
  - Peer Delay Mechanism (P2P)

  For TimeSync Module design, please refer to EthFW documentation for details.
  CPSW9G DEVNP driver has included an option to return CPTS timer timestamp via devctl() with PTP_GET_TIME command.
  Please refer to the example, ptp_test, to see how to use PTP_GET_TIME command to get CPTS timer timestamp from cpsw9g devnp driver.

  .. NOTE::

     Refer :ref:`psdk_rtos_components_|dev_platform|` for more information about EthFW component.

  **Running**

  Boot the board with the SDcard.
  At the QNX prompt, run below, to mount the SD card and then launch the executables:

  .. code:: bash

     tisci-mgr
     tiipc-mgr
     tiudma-mgr
     io-pkt-v6-hc -d cpsw9g
     dhclient -nw an0

  The cpsw9g driver configures all the driver created threads to have the runmask as 0x0 by default. This is to make sure
  all the threads run on core 0 of the A72. This can be configured with the *run_mask_cpu=* command-line option.
  See the *use* command or :ref:"Usage of devnp-cpsw9g.so" for further details.

  For debug traces, run the below command before starting the DEVNP driver and start the driver with
  increased verbose parameter (ex: verbose=0x3ff) this will show all the drivers slog messages

  .. code:: bash

     slog2info -c
     slog2info -w &

  **Additional steps**

  - Run "if_up -p an0" to check if the interface is ready
  - Run "ifconfig an0 up" to bring UP the link.
  - Run "dhclient -nw an0" for DHCP server provide the IP address
  - Run "ifconfig -v" to check the assigned IP address and status
  - Run "tcpdump -e" to look at the tcp traffic

  **Usage of devnp-cpsw9g.so**

  We can run the below command to get the usage of the DEVNP driver

  .. code:: bash

     $ use devnp-cpsw9g.so

     devnp-cpsw9g.so j721e cpsw 9G virtual ethernet driver based on enet low level driver

     Syntax:
       io-pkt-v6-hc -d cpsw9g [option[,option ...]] ...

     Options (to override autodetected defaults):
       verbose=num             Set verbosity level (default: 0).
       ptp=0|1                 1 to enable PTP support (default: 0)
       typed_mem=name          Set the typed memory
       udma_chnum=val          Set the preferred udma channel to use (default: dynamic allocation)
       tx_freeq_threshold=val  Set the tx free Q threshold value (default: 120), must be less than no of TX descriptors.
       tx_descriptor_cnt=val   Set the tx descriptors count value (default: 128, Max: 256)
       rx_descriptor_cnt=val   Set the rx descriptors count value (default: 128, Max: 256)
       run_mask_cpu=val        Set the run mask - cpu core where threads are scheduled (default:0) (0 - core0, 1 - core1, 2 - both core)
       poll_phy_ms=val         Set the frequency in ms, to poll the phy status, and poll for management of resources (default: 10000)
       cache_ops=val           Set the cache operation to on/off (default:0  -> cache-coherency set), 1 - Turn on cache off -> cache-coherency off)
       smmu=0|1                1 to enable smmu support (default: 0)
       virt_id=val             Set the virt_id to use for the dma channel when smmu is enabled
       mac-to-mac=1            Set for mac-to-mac mode (default: 0) (only when EthFW is setup for mac-to-mac mode)
       speed=100|1000          Media data rate for link in Mb/s. (default: 1000)
       joinvlan="1;2;3..."     List of VLANs to join
       rx_intr_prio=val        Set the rx interrupt thread priority (default: 21)
       tx_intr_prio=val        Set the tx interrupt thread priority (default: 21)
       no_stack_thread=val     1 to disable using the stack thread needed for bridge and fastforward to work  (default: 0)
       hw_csum=1               1 to enable hw csum (default: 0)
       p0mac=XXXXXXXXXXXX      Custom MAC address to use on virtual port
       rx_pacing=0|1           1 to enable rx interrupt pacing (default:0, use rx interrupt)
       rx_pacing_msec=val      Set the rx interrupt pacing internal in msec (default: 1 msec)

     Examples:
       # Start io-pkt using the driver:
       io-pkt-v6-hc -d cpsw9g
       ifconfig an0 192.0.2.1

       # Start io-pkt using the driver with typed memory "ram":
       io-pkt-v6-hc -d cpsw9g typed_mem=ram -ptcpip pkt_typed_mem=ram
       ifconfig an0 192.0.2.1

       # Start io-pkt using the driver with typed memory "ram", preferred udma channel "24" and smmu enabled:
       io-pkt-v6-hc -d cpsw9g ptp=1,typed_mem=ram,udma_chnum=24,smmu=1 -ptcpip pkt_typed_mem=ram
       ifconfig an0 192.0.2.1

       # Start io-pkt using the driver for mac-to-mac mode in gitbit speed
       io-pkt-v6-hc -d cpsw9g mac-to-mac=1,speed=1000
       ifconfig am0 192.0.2.1

  **Starting driver with other options**

  To run the cpsw9g devnp driver with gPTP:

  .. code:: bash

     io-pkt-v6-hc –d cpsw9g ptp=1

     Run "ptp_test" utility to  verfiy/get the synchronized time from EthFW.

  To run the cpsw9g devnp driver in mac-to-mac mode with 1Gbps:

  .. NOTE::

     To run mac-to-mac mode, changes are required on EthFW side.
     Please refer E2E FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/998242/faq-tda4vm-how-to-configure-enet-lld-and-ethfw-cpsw-for-mac-2-mac-connection-for-tda4-and-dra821/3687628

  .. code:: bash

     io-pkt-v6-hc –d cpsw9g mac-to-mac=1

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:

.. code:: bash

   k3conf --help

TIHWMON utility
================

The TIHWMON utility is used to monitor/reports various aspects of the TI SoC. Launch the TIHWMON using the following
command-line.

.. code:: bash

   ti-hwmon

The current implementation monitors the following information:

DIEID
-----

A 4 word identifier for the TI J7 SOCs. To get this value execute the following command on your serial console

.. code:: bash

   cat /dev/tihwmon/dieid


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 

.. code:: bash

   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

.. code:: bash

   cat /dev/tihwmon/vtm/thermal_zoneX

where X is an index to a zone from 0 to the max num of zone supported - 1 .

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:

.. code:: bash

   get_thermal_data.sh -run_time=60 --polling_rate=100 --csv_output=/tmp/thermal_data.csv

VXE384MP2 Video Encoder
=======================

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

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

.. code:: bash

   $ 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

D5520MP2 Video Decoder
======================

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

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

.. code:: bash

   $ 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
