OMAP5 GLSDK Software Developers Guide

From Texas Instruments Wiki
Jump to: navigation, search

TIBanner.png

Contents

Introduction

Welcome to the OMAP5 Processor SDK Linux Automotive Software Developer's Guide.

Thank you for choosing the OMAP5 uevm for your application. The purpose of this guide is to get you going with developing software for the OMAP5 on a Linux development host only.

Note! All instructions in this guide are for Ubuntu 14.04. At this time, this is the only supported Linux host distribution for development.

Some commands are to be executed on the Linux development host, some on the Linux target and some on the u-boot (bootloader) prompt. The following conventions are used to distinguish the commands on a host and on the target:

host $ <this command is to be executed on the host>
target # <this command is to be executed on the target>
u-boot :> <this command is to be executed on the u-boot prompt>

Migrating from previous release to latest release

Migrating the linux kernel repository:

After the 6_01_00_01 release, location of linux kernel remote repository has changed from git.ti.com to omapzoom.org kernel repository. To port the locally developed patches from the glsdk_dev branch of 6_01 linux installation folder to the new release, please follow the steps given below:

  • Go to the linux source directory i.e $GLSDK_6_01_00_01/board-support/linux.
  • Create patches of your local commits after the commit-id- 6076e688 by using the command git format-patch -<n> (n is the number of commits from commit id 6076e688).
  • Apply and merge these patches on the new linux kernel source in the $GLSDK_6_xx_xx_xx/board-support/linux directory.

Migrating the u-boot repository:

After the 6_02_01_02 release, location of u-boot remote repository has changed from git.ti.com to omapzoom.org u-boot repository. To port the locally developed patches from the glsdk_dev branch of previous u-boot installation to the new release, please follow the steps given below:

  • Go to the u-boot source directory i.e $GLSDK_6_02_00_02/board-support/u-boot.
  • Create patches of your local commits after the commit-id- 317da0e by using the command git format-patch -<n> (n is the number of commits from commit id 317da0e).
  • Apply and merge these patches on the new u-boot source in the $GLSDK_6_xx_xx_xx/board-support/u-boot directory.

Starting your software development

Setup up ARM linux development Environment on the host. Please refer to this link to see how to set one up.

Configuration of ARM Linux development Environment

Step 1: Install the Processor SDK Linux Automotive release on the host machine.

  • Download the Processor SDK Linux Automotive installer.
  • If necessary make the installer executable manually by executing:
host $ chmod +x ti-processor-sdk-linux-automotive-omap5-uevm-6.04.00.02-installer.bin
  • Execute the installer on the host and follow the instructions:
host $ ./ti-processor-sdk-linux-automotive-omap5-uevm-6.04.00.02-installer.bin

Step 2: Setup the INSTALL_DIR environment variable to the location where the Processor SDK Linux Automotive is installed (the following assumes that Processor SDK Linux Automotive was installed at default location):

host $ export INSTALL_DIR="${HOME}/ti-processor-sdk-linux-automotive_omap5-uevm_6_04_00_02"

Step 3: Setup the Processor SDK Linux Automotive on host

Host Setup

  • Ubuntu

The recommended Linux distribution is Ubuntu 14.04 or Ubuntu 16.04.

The following build host packages are required for Ubuntu. The following command will install the required tools on the Ubuntu Linux distribution.

For Ubuntu 14.04 and 16.04, please run the following:

$ sudo apt-get install git build-essential python diffstat texinfo gawk chrpath dos2unix wget unzip socat doxygen libc6:i386 libncurses5:i386 libstdc++6:i386 libz1:i386


The build also requires that bash is configured as the default system shell. The following steps will configure Ubuntu to use bash instead of the default dash.

$ sudo dpkg-reconfigure dash

(Select "no" when prompted)

Code Composer Studio

Code Composer Studio 6.1.3.00034 must be downloaded manually and placed into either the downloads directory, or placed on a mirror. Please see CCS v6 Download for details and download the Linux off-line installation tarball, e.g., CCS6.1.3.00034_linux.tar.gz.


NOTE

If the CCS Linux tarball is copied to tisdk/downloads directory, please also run "touch tisdk/downloads/CCS6.1.3.00034_linux.tar.gz.done".



The Processor SDK Linux Automotive comes with a script for setting up your Ubuntu 14.04 LTS development host. It is an interactive script, but if you accept the defaults by pressing return you will use the recommended settings. This is recommended for first time users. Note that this script requires ethernet access as it will update your Ubuntu Linux development host with the packages required to develop using the Processor SDK Linux Automotive.
Note: Please make sure that the proxy settings are done for http, https, git, ftp and wget before proceeding further.
Execute the script in the Processor SDK Linux Automotive release directory using:

host $ cd ${INSTALL_DIR}
host $ ./setup.sh

The setup script would perform the following operations:

  1. Installs all the necessary package on the host for the SDK.
  2. Prepares the UART terminal to communicate with the target over Debug USB on Minicom. If you want to use a windows host for connecting to the target instead, see the #Setting_up_Tera_Term section
  3. Setups the linaro cross compiler
  4. Installs the dependencies for the repo tool.
  5. Initialize the repo by pointing it to Processor SDK Linux Automotive release manifest location.

To start minicom on your Linux development host execute minicom -w (or Tera Term on Windows).

Step 4: Prepare SD card
To install the release image, you need a µSD Card (at least 4GB) with 2 partitions:

  • boot (vfat) partition.
  • rootfs (ext4 or ext3) partition.

The following procedure prepares the sdcard: (however, the user can choose to do it manually as well)

  • Plug an SD card reader to your PC and insert a µSD card. It must be at least 4GB size.
  • Identify which device corresponds to the SD card reader. sudo fdisk -l command can help you find out where the µSD Card is mapped. We will call it /dev/sdY here.
Note : If you are using NFS file system, then edit ${INSTALL_DIR}/board-support/pre-built-images/uenv.txt, add "ip=dhcp" in bootargs.
  • Re-format your µSD card with this script mksdboot.sh from the bin directory in the Processor SDK Linux Automotive
$ sudo ${INSTALL_DIR}/bin/mksdboot.sh --device /dev/sdY --sdk ${INSTALL_DIR}

The above script would prepare the SD card with the prebuilt images and yocto filesystem for SD boot.

Step 5: Booting the board
To boot the board with the above created SD card, refer to the Quick Start Guide at the Processor SDK Linux Automotive download location Link to setup the board.
Then, power cycle the board and login with username as root.



Repo tool Usage

Starting source code development using repo tool

The Processor SDK Linux Automotive release uses the repo tool to effectively manage the different components.

NOTE :

1: The first step to the repo tool is the repo initialization and this is done as part of the $INSTALL_DIR/setup.sh script

2: The repo tool is downloaded into the bin folder in the Processor SDK Linux Automotive directory. Please ensure that this path is updated in the environment variable as shown below

host $  export PATH=${INSTALL_DIR}/bin:$PATH

The Processor SDK Linux Automotive release contains a helper script that sets up the development environment. Run the script as shown below:

host $ cd ${INSTALL_DIR}
host $ ./bin/fetch-sources.sh

The script does the following:

  • Check for the repo tool.
  • Perform repo sync
  • Create a branch called dev
  • Checkout the branch dev

It is expected that the development is done on the dev branch.


How to get updates

If there are changes in the remote repositories, it could be fetched using the same script.
However, please make note of these important points.

1. The script will fetch the latest changes, and switch back to the dev branch.
2. The new updates from the remote, will be available in the master branch.
3. The decision on whether to merge the changes to the local branch or merge the local branch to the master is left to the developer


Building Yocto Filesystem

Please ensure that the setup.sh script is run as described in Starting your software development section and answer 'yes' to fetch-sources prompt.
Before building the filesystem, ensure that the svn, http, ftp and git proxies are set correctly. Refer to the following link for these settings https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy.

Add the Linaro cross-compile toolchain path in the PATH environment variable.

host $ export PATH=<Path to Linaro cross-compile toolchain>/bin:$PATH

Run this command to as a one-time setup for the yocto build

host $ cd $INSTALL_DIR
 NOTE:
 # Prior to running the setup-yocto.sh script, make sure that GCC Linaro cross compiler installation path and the CCS binary is downloaded into a particular directory
 # Update the ./bin/setup-yocto.sh file to indicate this path, the default path is set to /sdk/tools and this may vary on every machine. 
 
host $ ./bin/setup-yocto.sh

For building core sdk , run the build-core-sdk.sh passing machine name as an argument.

host $ cd yocto-layers

Create a downloads directory (if building using Yocto for the first time), where the Yocto build will place the downloads. Note the path of the directory.

host $ mkdir downloads

NOTE: Please pass the same downloads directory path to the following build-script when prompted

host $ ./build-core-sdk.sh dra7xx-evm

These scripts will build the tisdk-rootfs-image.

After build is complete the generated images can be found in yocto-layers/build/arago-tmp-external-linaro-toolchain/deploy/images/

Generated images
Image name Description
tisdk-rootfs-image-<MACHINE-NAME>-<DATE>.rootfs.tar.gz This is the filesystem tarball. Copy and extract it on the rootfs partition of the boot media.
zImage-<MACHINE-NAME>.bin zImage for the machine. Copy as zImage in /boot folder of the rootfs partition.
zImage-<MACHINE-NAME>.dtb Copy dra7-evm.dtb in boot partition. Or choose to copy the appropriate dtb based on the display and additional boards that are connected.
u-boot-<MACHINE-NAME>.img Copy as u-boot.img in boot partition.

Note: The build does not generate a uenv.txt. You need to copy it from the prebuilt binaries in the release.

Modifying source code and rebuilding a component

Once the Yocto setup is complete developers would like to modify a certain component source code and rebuild it. The source code for the generic components like omapdrmtest can be found in ${INSTALL_DIR}/yocto-layers/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-neon-linux-gnueabi/

Steps to rebuild:

1. Modify the source of the component in its work area

2. cd to yocto-layers

  host $ cd ${INSTALL_DIR}/yocto-layers

3. export PATH if not done previously:

  host $ export PATH=<Path to Linaro cross-compile toolchain>/bin:$PATH

4. Run one/combination of the folowing tasks:

a. To configure and compile with the latest changes in the work area:

  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c configure <RECIPE-NAME>
  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile <RECIPE-NAME>

For example, if the omapdrmtest source is modified and you want to generate only the binaries for dra7xx-evm, the compile task should suffice:

  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile omapdrmtest

The binaries will be present in the same folder as the source files.

b. To generate .ipk package in addition to the binaries, following additional tasks need to be run after above steps:

  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c install <RECIPE-NAME>
  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c package <RECIPE-NAME>
  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c package_write_ipk <RECIPE-NAME>

This will generate .ipk packages for the recipe. They can be found in the deploy-ipks folder of the work area of the recipe.
The .ipk packages can be copied and installed on the target by:

  target $ opkg install <PACKAGE-NAME>

This approach is useful in the case of recipes that generate a large number of binaries, that are difficult to copy manually, like gst-plugins-bad.

c. During building and debugging the kernel or kernel modules, the compile_kmodules task needs to be executed that generates kernel modules.

  host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile_kmodules <RECIPE-NAME>

For a complete set of tasks that a specific recipe executes during its build, please refer to the log.task_order in the temp folder of the component.
Pass the relevant tasks to build-specific-recipe.sh for required outcome.

5. For a robust solution , once the change in source area is tested with the above steps, please update the recipe.

a. create a patch of the change
b. copy it in the folder where the recipe is present
c. add the patch name in the SRC_URI variable in the recipe

The build-specific-recipe.sh recognizes the change in the recipe and builds it if required.

To build a specific component after recipe is updated, use the build-specific-recipe.sh

host $ ./build-specific-recipe.sh <MACHINE-NAME> <RECIPE NAME>

For example to build omapdrmtest:

 host $ ./build-specific-recipe.sh <MACHINE-NAME> omapdrmtest

MACHINE-NAME can be either omap5-evm or dra7xx-evm

To clean a specific component:

host $ ./clean-specific-recipe.sh <MACHINE-NAME> <RECIPE NAME>

Processor SDK Linux Automotive software overview

Glsdk omap5 software overview.jpg
Processor SDK Linux Automotive Software Stack

The Processor SDK Linux Automotive contains many software components. Several components are developed by the open source community (white). A few components that leverage HW acceleration in SoC are developed by Texas Instruments. TI contributes, and sometimes even maintains, some of these open source community projects, but the support model is different from a project developed solely by TI.

Running Examples

Running OMAP DRM DSS Examples

The drmclone, drmextended, and modetest examples demonstrates how to create a CRTC (i.e. FB) and display planes (overlays) on the CRTC. Additionally, drmtest demonstrates similar functionality as the previously mentioned demos, along with dynamic plane updates for 2 CRTCs.

Retrieve the omapdrm-tests source

 git clone https://github.com/tomba/omapdrm-tests.git
 cd omapdrm-tests

Run (or example planescale)

./planescale

Graphics Demos from Command Line

The graphics driver and userspace libraries and binaries are distributed along with the SDK.

Graphic demos can also run from command line. In order to do so, exit Weston by pressing Ctrl-Alt-Backspace from the keyboard which connects to the EVM. Then, if the LCD screen stays in "Please wait...", press Ctrl-Alt-F1 to go to the command line on LCD console. After that, the command line can be used from serial console, SSH console, or LCD console.

Please make sure the board is connected to atleast one display before running these demos.

Finding Connector ID

Note: Most of the applications used in the Demos would require the user to pass a connector id. A connector id is a number that is assigned to each of the display devices connected to the system. To get the list of the display devices connected and the corresponding connector id one can use the modetest application (shipped with the file system) as mentioned below:

  target #  modetest

Look for the display device for which the connector ID is required - such as HDMI, LCD etc.

Connectors:
id  encoder status      type    size (mm)   modes   encoders
4   3   connected   unknown 0x0     1   3
  modes:
    name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1280x800 60 1280 1328 1360 1404 800 804 811 823 flags: nhsync, nvsync; type: preferred, driver
...
16  11  connected   HDMI-A  700x390     31  11
  modes:
    name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1280x720 60 1280 1390 1430 1650 720 725 730 750 flags: phsync, pvsync; type: preferred, driver

Usually LCD is assigned 4 (800x480), HDMI is assigned 16 (multiple resolutions).

Finding Plane ID

To find the Plane ID, run the modetest command:

  target #  modetest

Look for the section called Planes. (Sample truncated output of the Planes section is given below)

Planes:
id      crtc    fb      CRTC x,y        x,y     gamma size
19      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...
20      0       0       0,0             0,0     0
 formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY
 props:
 ...

kmscube

Run kmscube on default display (HDMI):

  target # kmscube



kmscube with video

This demo allows a video frame to be applied as a texture onto the surface of the kmscube. The user can invoke the demo by following the syntax below:

  target # viddec3test <path_to_the_file> --kmscube --connector <connector_number>

This feature is not supported on OMAP5 based releases.



Additionally, to change the field of view of the rotating cube, the user can specify the same on the command line like below:

  target # viddec3test <path_to_the_file> --kmscube --connector <connector_number> --fov <number>


Wayland/Weston

The supported Wayland/Weston version brings in the multiple display support in extended desktop mode and the ability to drag-and-drop windows from one display to the other.

To execute the demos, the graphics driver must be initialized by running start weston, if this has not been done earlier.

  target # /etc/init.d/weston start

To launch weston without using systemd init scripts, do the following:



By default, the screensaver timeout is configured to 300 seconds.

The user can change the screensaver timeout using a command line option

 --idle-time=<number of seconds>

To disable the screen timeout and to configure weston configured to display on all connectors, use the option with "0" as the input:

 --idle-time=0


The filesystem comes with a preconfigured weston.ini file which will be located in /etc/weston.ini

Running weston clients

There is one icon on the top right hand corner of the weston desktop window which has been configured for

  • weston-terminal

Clicking this icon should launch the applications on the Weston Desktop.

It is possible to add other icons by editing the weston.ini file.

There are several other applications that are included in the default filesystem. To invoke these applications, the user should launch the weston-terminal (top right hand corner of the desktop) and then invoke the client apps as described below from within the terminal window:

       wayland sh # /usr/bin/weston-flower
       wayland sh # /usr/bin/weston-clickdot
       wayland sh # /usr/bin/weston-cliptest
       wayland sh # /usr/bin/weston-dnd
       wayland sh # /usr/bin/weston-editor
       wayland sh # /usr/bin/weston-eventdemo
       wayland sh # /usr/bin/weston-image /usr/share/weston/terminal.png
       wayland sh # /usr/bin/weston-resizor
       wayland sh # /usr/bin/weston-simple-egl
       wayland sh # /usr/bin/weston-simple-shm
       wayland sh # /usr/bin/weston-simple-touch
       wayland sh # /usr/bin/weston-smoke
       wayland sh # /usr/bin/weston-info
       wayland sh # /usr/bin/weston-terminal


Running multimedia with Wayland sink

The GStreamer video sink for Wayland is the waylandsink. To use this video-sink for video playback:

  target # gst-launch-1.0 playbin uri=file://<path-to-file-name> video-sink=waylandsink


Exiting weston

Terminate all Weston clients before exiting Weston. If you have invoked Weston from the serial console, exit Weston by pressing Ctrl-C.

It is also possible to invoke Weston from the native console, exit Weston by using pressing Ctrl-Alt-Backspace.

Using IVI shell feature

The SDK also has support for configuring weston ivi-shell. The default shell that is configured in the SDK is the desktop-shell.

To change the shell to ivi-shell, the user will have to add the following lines into the /etc/weston.ini.

To switch back to the desktop-shell can be done by commenting these lines in the /etc/weston.ini (comments begin with a '#' at the start of line).

[core]
shell=ivi-shell.so

[ivi-shell]
ivi-module=ivi-controller.so
ivi-input-module=ivi-input-controller.so

After the above configuration is completed, we can restart weston by running the following commands

target# /etc/init.d/weston stop
target# /etc/init.d/weston start

NOTE: When weston starts with ivi-shell, the default background is black, this is different from the desktop-shell that brings up a window with background.

With ivi-shell configured for weston, wayland client applications use ivi-application protocol to be managed by a central HMI window management. The wayland-ivi-extension provides ivi-controller.so to manage properties of surfaces/layers/screens and it also provides the ivi-input-controller.so to manage the input focus on a surface.

Applications must support the ivi-application protocol to be managed by the HMI central controller with an unique numeric ID.

Some important references to wayland-ivi-extension can be found at the following links: https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start https://at.projects.genivi.org/wiki/display/PROJ/Wayland+IVI+Extension+Design


Running weston’s sample client applications with ivi-shell

All the sample client applications in the weston package like weston-simple-egl, weston-simple-shm, weston-flower etc also have support for ivi-shell. The SDK includes the application called layer-add-surfaces which is part of the wayland-ivi-extension. This application allows the user to invoke the various functionalities of the ivi-shell and control the applications.

The following is an example sequence of commands and the corresponding effect on the target.

After launching the weston with the ivi-shell, please run the below sequence of commands:

target# weston-simple-shm &

At this point nothing is displayed on the screen, some additional commands are required.

target# layer_add_surfaces 0 1000 2 &

This command creates a layer with ID 1000 and to add maximum 2 surfaces to this layer on the screen 0 (which is usually the LCD).
At this point, the user can see weston-simple-shm running on LCD. This also prints the numericID (surfaceID) to which client’s surface is mapped as shown below:

 CreateWithDimension: layer ID (1000), Width (1280), Height (800)
 SetVisibility      : layer ID (1000), ILM_TRUE
 layer: 1000 created
 surface                : 10369 created
 SetDestinationRectangle: surface ID (10369), Width (250), Height (250)
 SetSourceRectangle     : surface ID (10369), Width (250), Height (250)
 SetVisibility          : surface ID (10369), ILM_TRUE
 layerAddSurface        : surface ID (10369) is added to layer ID (1000)

Here 10369 is the number to which weston-simple-shm application’s surface is mapped.

User can launch one more client application which allows layer_add_surfaces to add second surface to the layer 1000 as shown below.

target# weston-flower &

User can control the properties of the above surfaces using LayerManagerControl as shown below to set the position, resize, opacity and visibility respectively.

target# LayerManagerControl set surface 10369 position 100 100
target# LayerManagerControl set surface 10369 destination region 150 150 300 300
target# LayerManagerControl set surface 10369 opacity 0.5
target# LayerManagerControl set surface 10369 visibility 1
target# LayerManagerControl  help  

The help option prints all possible control operations with the LayerManagerControl binary, please refer to the available options.

IMG PowerVR Demos

The Processor SDK Linux Automotive filesystem comes packaged with example OpenGLES applications. Both DRM and Wayland based applications are packaged as part of the filesystem.

The examples running on Wayland can be invoked using the below commands.

 target # /usr/bin/SGX/demos/Wayland/OGLES2ChameleonMan
 target # /usr/bin/SGX/demos/Wayland/OGLES2Navigation

The examples running on DRM/KMS can be invoked using the below commands.

 target # /usr/bin/SGX/demos/Raw/OGLES2ChameleonMan
 target # /usr/bin/SGX/demos/Raw/OGLES2Navigation

After you see the output on the display interface, hit q to terminate the application.


Using the PowerVR Tools

Please refer to http://community.imgtec.com/developers/powervr/graphics-sdk/ for additional details on the tools and detailed documentation.

The target file system includes tools such as PVRScope and PVRTrace recorder libraries from Imagination PowerVR SDK to profile and trace SGX activities. In addition, it also includes PVRPerfServerDeveloper toolfor Jacinto6 platform.

PVRTune

PVRPerfServerDeveloper tool can be used along with the PVRTune running on the PC to gather data on the SGX loading and activity threads. You can invoke the tool with the below command:

target # /opt/img-powervr-sdk/PVRHub/PVRPerfServer/PVRPerfServerDeveloper

PVRTrace

The default filesystem contains helper scripts to obtain the PVRTrace of the graphics application. This trace can then be played back on the PC using the PVRTrace Utility.

To start tracing, use the below commands as reference:

target # cp /opt/img-powervr-sdk/PVRHub/Scripts/start_tracing.sh ~/.
target # ./start_tracing.sh <log-filename> <application-to-be-traced>

Example:

target # ./start_tracing.sh westonapp weston-simple-egl

The above command will do the following:

  1. Setup the required environment for the tracing
  2. Create a directory under the current working directory called pvrtrace
  3. Launch the application specified by the user
  4. Start tracing the PVR Interactions and record the same to the log-filename

To end the tracing, user can invoke the Ctrl-C and the trace file path will be displayed.

The trace file can then be transferred to a PC and we can visualize the application using the host side PVRTrace utility. Please refer to the link at the beginning of this section for more details.

Testing DSS WB pipeline

Memory to Memory (M2M)

  1. Identify the WB pipeline M2M device.

    # ls /sys/class/video4linux/
    Video0 video10 video11
    # cat  /sys/class/video4linux/video10/name
    omapwb-m2m
  2. Look at list of formats supported.

    # v4l2-ctl -d /dev/video10 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Index       : 0
            Type        : Video Capture Multiplanar
            Pixel Format: 'NV12'
            Name        : Y/CbCr 4:2:0
    
            Index       : 1
            Type        : Video Capture Multiplanar
            Pixel Format: 'YUYV'
            Name        : YUYV 4:2:2
    
            Index       : 2
            Type        : Video Capture Multiplanar
            Pixel Format: 'UYVY'
            Name        : UYVY 4:2:2
    
            Index       : 3
            Type        : Video Capture Multiplanar
            Pixel Format: 'XR24'
            Name        : 32-bit BGRX 8-8-8-8
  3. Use v4l2-ctl command to test the input output. Below command converts from NV12 to YUYV using WB pipeline in M2M mode.

    # v4l2-ctl -d /dev/video10 --set-fmt-video-out=width=1920,height=1080,pixelformat=NV12  \
    --stream-from=test/BigBuckBunny_1920_1080_24fps_100frames.nv12 \
    --set-fmt-video=width=1920,height=1080,pixelformat=YUYV \
    --stream-to=out/video_test_file.yuyv --stream-mmap=3 --stream-out-mmap=3 --stream-count=70 --stream-poll

Capture

  1. Identify the WB pipeline capture device.

    # ls /sys/class/video4linux/
    Video0 video10 video11
    # cat  /sys/class/video4linux/video11/name
    omapwb-cap
  2. Look at list of formats supported.

    # v4l2-ctl -d /dev/video11 --list-formats
    ioctl: VIDIOC_ENUM_FMT
            Index       : 0
            Type        : Video Capture Multiplanar
            Pixel Format: 'NV12'
            Name        : Y/CbCr 4:2:0
    
            Index       : 1
            Type        : Video Capture Multiplanar
            Pixel Format: 'YUYV'
            Name        : YUYV 4:2:2
    
            Index       : 2
            Type        : Video Capture Multiplanar
            Pixel Format: 'UYVY'
            Name        : UYVY 4:2:2
    
            Index       : 3
            Type        : Video Capture Multiplanar
            Pixel Format: 'XR24'
            Name        : 32-bit BGRX 8-8-8-8
    
  3. Use v4l2-ctl command to test the input output. Below command converts from NV12 to YUYV using WB pipeline in M2M mode.

    # v4l2-ctl -d /dev/video11 -i 0 --set-fmt-video=pixelformat=NV12 \
    --stream-to=/test/video_test_file.yuv --stream-mmap=6 --stream-count=10 --stream-poll
    Video input set to 0 (CRTC#0 - LCD1: ok)
    <<<<<<<<< 7.84 fps
    <
    # v4l2-ctl -d /dev/video11 -i 1 --set-fmt-video=pixelformat=NV12 --stream-to=/test/video
    _test_file.yuv --stream-mmap=6 --stream-count=10 --stream-poll
    Video input set to 1 (CRTC#1 - DIGIT/TV: ok)
    <<<<<<<<<< 8.65 fps

Running aplay and arecord application

Audio playback is supported on HDMI and via headset. By default, the audio playback takes place on the HDMI. To listen to audio via the HDMI, run the aplay application

  target #  aplay <path_to_example_audio>.wav

If playback is required via headset, please make sure that the following amixer settings are done for the corresponding card (check the card no. by running the command cat /proc/asound/cards, assuming the card 1 is for headset here):

  target #  amixer cset -c 1 name='Headset Left Playback' 1
  target #  amixer cset -c 1 name='Headset Right Playback' 1
  target #  amixer cset -c 1 name='Headset Playback Volume' 12
  target #  amixer cset -c 1 name='DL1 PDM Switch' 1
  target #  amixer cset -c 1 name='Sidetone Mixer Playback' 1
  target #  amixer cset -c 1 name='SDT DL Volume' 120
  target #  amixer cset -c 1 name='DL1 Mixer Multimedia' 1
  target #  amixer cset -c 1 name='DL1 Media Playback Volume' 110
  target #  amixer sset -c 1 'Analog Left',0 'Aux/FM Left'
  target #  amixer sset -c 1 'Analog Right',0 'Aux/FM Right'
  target #  amixer sset -c 1 'Aux FM',0 7
  target #  amixer sset -c 1 'AUDUL Media',0 149
  target #  amixer sset -c 1 'Capture',0 4
  target #  amixer sset -c 1 MUX_UL00,0 AMic0
  target #  amixer sset -c 1 MUX_UL01,0 AMic1
  target #  amixer sset -c 1 'AMIC UL',0 120

Once these settings are done, one could do playback via headset using aplay by the following command:

  target #  aplay -Dplughw:1,0 <path_to_example_audio>.wav



Running GC320 application

GC320 is a 2D Graphic accelerator in DRA7xx. This IP can be utilized for the usecases like alpha blending, overlaying, bitBlit, color conversion, scaling, rotation etc.

SDK provides two sample GC320 testcases in the root filesystem. Before running the test, the gc320 kernel module needs to be inserted into system.

On 1.5GB RAM configuration

  target# insmod /lib/modules/4.4.xx-gyyyyyyyy/extra/galcore.ko baseAddress=0x80000000 physSize=0x60000000

On 2GB RAM configuration

   target# insmod /lib/modules/4.4.xx-gyyyyyyyy/extra/galcore.ko baseAddress=0x80000000 physSize=0x80000000

Now follow these instrctions to execute the applications

  target# cd /usr/bin/GC320/tests/unit_test
  target# export LD_LIBRARY_PATH=$PWD
  target# ./runtest.sh

This script executes two sample unit test cases of filling rectangles and GC320 rendered results will be stored in .bmp file in a directory "result" under /usr/bin/GC320/tests/unit_test.

Note: To run all GC320 unit testcases, clone ti-gc320-test package from git://git.ti.com/graphics/ti-gc320-test.git : branch:ti-5.0.11.p7, rebuild test application, libraries etc and install the package on target.


Running viddec3test application

viddec3test is a demo application for decoder/video playback using hardware accelerators. The application currently runs on the kms display. The application requires the connector information for display. One can get the information of the display connected to the board by running the modetest application in the filesystem, as described above. To execute the application "modetest" make sure the display is connected to the board.

Running a decode on a display

To run a hardware decode on a display connected to the board, execute the following command:

  target #  viddec3test -s <connector_id>:<display resolution> filename --fps 30

e.g.: target # viddec3test -s 4:1920x1080 file.h264 --fps 30


Running a gstreamer pipeline

GStreamer v1.6 is supported in Processor SDK Linux Automotive 3.01.


One can run an audio video file using the gstreamer playbin from the console. Currently, the supported Audio/video sink is kmssink, waylandsink and alsassink.

kmssink:
  target #  gst-launch playbin2 uri=file:///<path_to_file> video-sink=kmssink audio-sink="alsasink device=hw:1,0"
waylandsink:  
  1. refer #Wayland/Weston to start the weston
  2. target # gst-launch playbin2 uri=file:///<path_to_file> video-sink=waylandsink audio-sink="alsasink device=hw:1,0"
dri2videosink:
  1. refer #X_Server to start the X11
  2. target # gst-launch playbin2 uri=file:///<path_to_file> video-sink=dri2videosink audio-sink="alsasink device=hw:1,0"

Running VIP/VPE/CAL application

Video Input Port

Video Input Port is used to capture video frames from BT56/ BT601 Camera. Currently the VIP driver supports following features.


Running dmabuftest

dmabuftest is a user space application which demonstrates capture display loopback. It can support multiple captures at the same time

Video buffers are allocated by libdrm and they are shared to VIP through dmabuf.

It interfaces with the VIP through standard v4l2 ioctls.

Filesystem from release has dmabuftest app preinstalled.

To capture and display on the LCD screen, run following command


To capture and display on the HDMI display, run following command


To capture video in NV12 format, run following command target# dmabuftest -s 16:800x480 -d /dev/video1 -c 1280x720@NV12

To capture and display on KMScube backend (Video on a rotating cube), run following command

target# dmabuftest --kmscube --fov 20 -d /dev/video1 -c 1280x720@YUYV
This feature is currently not supported

To capture and display on wayland backend (Video in a wayland client window), run following command

target# dmabuftest -w 640x480 --pos 100x400 /dev/video1 -c 1280x720@YUYV


Capturing through OV10640/OV490 CSI camera/ISP

Linux kernel supports CSI capture from OV10640 RAW camera and OV490 ISP.

CAL works on the CSI2 protocol and supports both raw and YUYV capture. It is verified with the OV10640 raw camera and OV490 ISP. TI-EVM has support for capturing via two CSI phys. - phy0 (4data lanes) and phy1 (2data lanes)

Video capture from OV490 can be verified as follows.

  • Connect OV10640 camera to the OV490 board
  • Connect the OV490 board to the TI-EVM via the CSI2 dual 490 adaptor board
  • I2C device on Bus 4 slave address 0x24 should be probed successfully
  • VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
  • Run dmabuftest with capture format of the analog camera (e.g. '1280x720@YUYV')

Video Processing Engine(VPE)

VPE supports Scalar, Colour Space Conversion and Deinterlace.It uses V4L2 mem2mem API.

Supported Input formats: nv12, yuyv, uyvy

Supported Output formats: nv12, yuyv, uyvy, rgb24, bgr24, argb24, abgr24

Not Supported formats: yuv444, yvyu, vyuy, nv16, nv61, nv21

File to File
 test-v4l2-m2m

 Usage:
 <SRCfilename> <SRCWidth> <SRCHeight> <SRCFormat> <DSTfilename> <DSTWidth> <DSTHeight> <DSTformat> <interlace> <translen>

Note:

<interlace> : set 1, If input is interlaced and want deinterlaced(progressive) output. output height should be twice of input height.


Deinterlace(DI):-

target# test-v4l2-m2m /dev/video0 frame-176-144-nv12-inp.yuv 176 144 nv12 progressive_output.nv12 176 288 nv12 1 1

Scalar(SC):-

target# test-v4l2-m2m /dev/video0 frame-176-144-nv12-inp.yuv 176 144 nv12 frame-1920-1080-nv12-out.nv12 1920 1080 nv12 0 1

Colour Space Conversion(CSC):-

target# test-v4l2-m2m /dev/video0 frame-720-240-yuyv-inp.yuv 720 240 yuyv frame-720-240-argb32-out.argb32 720 240 argb32 0 1

SC+CSC+DI:-

target# test-v4l2-m2m /dev/video0 frame-720-240-yuyv-inp.yuv 720 240 yuyv frame-1920-1080-rgb24-dei-out.rgb24 1920 1080 rgb24 1 1
File to Display
 filevpedisplay

 Usage:
 <src_filename> <src_w> <src_h> <src_format> <dst_w> <dst_h> <dst_format> <top> <left> <w> <h> <inter> <trans> -s <conn_id>:<mode>




VIP-VPE-Display

Camera captures the frames, which are processed by VPE(SC, CSC, Dei) then displays on LCD/HDMI.

 capturevpedisplay

 Usage:
 <src_w> <src_h> <src_format> <dst_w> <dst_h> <dst_format> <inter> <trans> -s <conn_id>:<mode>

Running DSS application

DSS application is omapdrm based. This will demonstrate the z-order and alpha blending features. HDMI display must be connected to board. Application requires the supported mode information of connected display and plane ids. One can get these information by running the modetest application in the filesystem.

  target #  modetest

Running drmzalpha application

Z-order:

It determines, which overlay window appears on top of the other.

Range: 0 to 3

lowest value for bottom

highest value for top

Alpha Blend:

It determines transparency level of image as a result of both global alpha & pre multiplied alpha value.

Global alpha range: 0 to 255

0 - fully transparent

127 - semi transparent

255 - fully opaque

Pre multipled alpha value: 0 or 1

0 - source is not premultiply with alpha

1 - source is premultiply with alpha

To test drmzalpha, execute the following command:

  target # drmzalpha -s <crtc_w>x<crtc_h> -w <plane1_id>:<z_val>:<glo_alpha>:<pre_mul_alpha> -w <plane2_id>:<z_val>:<glo_alpha>:<pre_mul_alpha>

e.g.: target # drmzalpha -s 640x480 -w 15:1:255:1 -w 16:2:255:1

Testing with FPDLink Display setup

For information on debugging FPDLink integration, please refer to Debugging FPDLink integration

Current H/W setup

FPDLink display is currently supported with Spectrum Digital FPDLink display part number 703840-0001. This display includes a 1280x800 AUO LCD panel with Goodix touch screen connected over a DS90UB924Q1 deserializer.

To validate FPDLink with the current HW setup, below hardware is required.

  • DRA7xx EVM + 12V supply for the EVM.
  • FPDLink Cable between DRA7xx and FPDLink display
  • 12 V power supply for the FPDLink display if using a J6/J6 Eco/J6 Entry EVM. J6 Plus EVM supplies power to the display over FPDLink. Power supply for display is not required in this case.

The picture below shows the overall setup.

DRA7xx FPDLink AUO SD setup.png

Kernel Config modifications are not necessary as AUO panel support and fpdlink support are built into the kernel.

To test the FPDLink display,

  1. Use the device tree dra7-evm-fpd-auo-g101evn01.0.dtb to boot.
  2. Add omapdrm.num_crtc=2 to the kernel boot arguments. The above device tree will enable both HDMI and FPDlink LCD.
  3. Power on the EVM and the check the modetest output. You should see two connectors now, one for HDMI and another for FPDLink.

Legacy H/W setup

Please note that support for the below FPDLink hardware will be deprecated with the next release. This is due to availability of the single board FPDLink display listed above.

To validate FPDLink with the legacy HW setup, below hardware is required.

  • DRA7xx EVM + 12V supply for the EVM.
  • FPDLink Cable between DRA7xx and De-serilzer board (DS90UB928Q).
  • 5V power supply for De-serializer board.
  • LCD Adapter board (DS90UH928Q) that sits on De-serializer board.
  • LCD Adapter cable which is between LCD panel and the Adapter board.
  • 12V power supply for LCD Adapter board.
  • The actual LCD panel (LG101(10.1in) or AUO (7.1 in))

The picture below shows the overall setup.

DRA7xx FPDLink setup.png

Kernel Config is not necessary as the supported panels and fpdlink are built into the kernel.

To test the FPDLink display,

  1. Use the device tree dra7-evm-fpd-lg.dtb to boot.
  2. Add omapdrm.num_crtc=2 to the kernel boot arguments. The above device tree will enable both HDMI and FPDlink LCD.
  3. Power on the EVM and the check the modetest output. You should see two connectors now, one for HDMI and another for FPDLink.

HW Modifications required

With the Rev B J6 Plus EVM's, a board modification is required to supply the pixel clock to the FPDLink connector. The modification required is shown in the below image.

DRA76x FPDLink Board mod.png

Gsttestplayer

gsttestplayer is a gstreamer test application useful for testing some features not testable with gst-launch-1.0 such as:

  1. Seek - Seeking to random points in a stream
  2. Trick play - Playback at different speeds (fast forward, rewind)
  3. Pause, Resume
  4. Playing multiple streams simultaneously in the same process, in a loop or one after another.

Running gsttestplayer

Command line options:

  target # gsttestplayer -h
        Usage: gsttestplayer <options>
                -s <sinkname>    Specify the video sink name to be used, default: kmssink
                -n               Do not use VPE, implies no scaling
                -r <width>x<height> Resize the output to widthxheight, no scaling if left blank
                -a               Play with no A/V Sync
                -c <cmds file>   Non-interactive mode, reading commands from <cmds file>
                --help-gst                        Show GStreamer Options

Example: To use waylandsink and resize the output video to 800x400.

  target # gsttestplayer -s waylandsink -r 800x400

In normal mode, when -c option is not used, the application enters an command prompt at which the user enter various commands. Type "help" to print out the list of possible commands:

  target # gsttestplayer -s waylandsink -r 800x400
        Scaling output to 800x400
        Using videosink=waylandsink
        <Enter ip> help
        Commands available:
        start  <instance num> <filename/capture device>
        stop   <instance num>
        pause  <instance num>
        resume <instance num>
        seek   <instance num> <seek to time in seconds> <optional: playback speed>
        sleep  <sleep time in seconds>
        msleep <sleep time in milliseconds>
        rewind <line number>
        exit
        <Enter ip>

Example commands:

start 0 KMS_MPEG4_D1.MP4  # Start playing the file "KMS_MPEG4_D1.MP4", using instance 0.
start 1 NTSC_h264.mp4     # Start playing the file "NTSC_h264.mp4" (simultaneously) using instance 1.
stop 0                    # Stop playback of instance 0.
seek 0 0 2                # Seek to "0"th second mark of the stream playing in instance 0,
                          #  and start playing back at speed 2x.
seek 0 300 -1             # Seek to "300"th second mark of the stream playing in instance 0,
                          #  and start playing back reserve at speed 1x.
start 2 /dev/video1       # Start capturing from /dev/video1 using the v4l2src plugin

All these commands could be put into a text file and given as input to gsttestplayer with the "-c" option. In this case, gsttestplayer runs non-interactively, reading commands from the text file one line after another. The commands sleep and rewind are useful for this mode, to introduce delays or to create a loop respectively.

Notes:

  1. This application plays video only. Audio path is not used.
  2. The input filename should have the correct file extension to indicate the type of file. The supported extensions are "mp4", "avi", "ts", "asf" & "wmv".
  3. The input filename should contain the string "264", "mpeg2", "mpeg4" or "vc1"/"wmv" to indicate which video codec should be used for decoding - H.264, MPEG-2, MPEG-4 or Windows Media Video.
  4. If the input filename is a video device which matches /dev/videoX pattern, v4l2src plugin would be used for video capture instead of playback.
  5. Decode and capture can be run in parallel depending on the sink being used.

Running IPC examples

Processor SDK Linux Automotive includes IPC examples are part of the target filesystem.

User space sample application

MessageQ is the user space API provided for IPC. The sample application for MessageQ consists of an application "MessageQApp" running on the A15 and corresponding binaries running on the remotecore. The below table shows the paths under which the remotecore binaries can be found on the target filesystem. To ensure that these binaries are loaded by the kernel, please symbolic link them to the location shown in the below table.

Core Binary path on target relative to /lib/firmware Binary should be symlinked to
DSP2 ./ipc/ti_platforms_evmDRA7XX_dsp1/messageq_single.xe66 /lib/firmware/dra7-dsp2-fw.xe66
IPU2 ./ipc/ti_platforms_evmDRA7XX_ipu2/messageq_single.xem4 /lib/firmware/dra7-ipu2-fw.xem4
IPU1 ./ipc/ti_platforms_evmDRA7XX_ipu1/messageq_single.xem4 /lib/firmware/dra7-ipu1-fw.xem4
DSP1 ./ipc/ti_platforms_evmDRA7XX_dsp2/messageq_single.xe66 /lib/firmware/dra7-dsp1-fw.xe66

Boot the target and ensure that the lad daemon is running. Use the ps command to check if the lad daemon is already running. If not, please start the lad daemon.

target # /usr/bin/lad_dra7xx

Start the MessageQApp

target # /usr/bin/MessageQApp <number of messages> <core id>

The core id to be used is 1,2,3,4 for IPU2,IPU1,DSP2 and DSP1 respectively.

target # MessageQApp 10 3
Using numLoops: 10; procId : 3
Entered MessageQApp_execute
Local MessageQId: 0x80
Remote queueId  [0x30080]
Exchanging 10 messages with remote processor DSP2...
MessageQ_get #1 Msg = 0xb6400468
MessageQ_get #2 Msg = 0xb6400468
MessageQ_get #3 Msg = 0xb6400468
MessageQ_get #4 Msg = 0xb6400468
MessageQ_get #5 Msg = 0xb6400468
MessageQ_get #6 Msg = 0xb6400468
MessageQ_get #7 Msg = 0xb6400468
MessageQ_get #8 Msg = 0xb6400468
MessageQ_get #9 Msg = 0xb6400468
MessageQ_get #10 Msg = 0xb6400468
Exchanged 10 messages with remote processor DSP2
Sample application successfully completed!
Leaving MessageQApp_execute

RPMsg client sample application

RPMsg is the kernel space IPC and the building block for the user space MessageQ IPC API. The below wiki page illustrates how to build and run an rpmsg Linux kernel space client to communicate with a slave processor (e.g. DSP, IPU, etc) using IPC's RPMsg module.

RPMsg_Kernel_Client_Application

Running basic Wifi tests

To run this test, you would need to have the Wilink COM module connected to the EVM.

Check if the wlan0 interface is showing up:

target # ifconfig -a

Bring up the wlan0 inteface:

target # ifconfig wlan0 up

Search for the available Wifi networks:

target # iw wlan0 scan | grep -i ssid

Running basic Bluetooth tests

To run this test, you would need to have the Wilink COM module connected to the EVM. Make sure that this module supports the Bluetooth.

target # hciconfig hci0 up
target # hciconfig -a

Turn on the Bluetooth on the device that you want to pair and make it discoverable, then run the following command:

target # hcitool scan

How to bring up the GNSS driver and sample application

WL8 GNSS driver that is compatible with SDK is now available as part of the click wrap license at the following location. http://www.ti.com/tool/wilink-sw

Users are requested to register and obtain the package.

The package contains the driver source and the required documentation.

The document "Bring up manual for WiLink8 GNSS driver on Linux" is the starting point that contains the instructions for compiling and trying the sample application.

NOTE: These instructions are known to work if the user starts with the Processor SDK Linux Automotive installer and compiles the Linux kernel using the instructions provided in the Software Developers Guide.


Additional Procedures

Build Environment Setup

NOTE: From this release, each component i.e kernel, u-boot or any userspace application should be cross-compiled

Cross Compiler setup

The cross compiler setup for the Rules.make is done as part of the setup.sh script in the SDK installation folder. The script for cross compiler ensures that the Linaro cross compiler toolchain is installed in the ${HOME} (or user specified) folder of the host machine.
Note:Please ensure that the PATH variable is set in your machine to point to the cross compiler setup.
To compile the code (if not using the top level Makefile to build kernel and u-boot), please ensure the environment variables ARCH and CROSS_COMPILE is set to arm and to the linaro cross compiler path respectively.

Rebuilding the SDK components

The installer contains a top level Makefile to allow the re-building of the various components.

Rebuild the SDK components by first entering the SDK directory using:

host $ cd ${INSTALL_DIR}

The installer Makefile has a number of build targets which allows you to rebuild the various components. For a complete list execute:

host $ make help

After that, each of the build targets listed by 'make help' can then be executed using:

host $ make <target>_clean
host $ make <target>
host $ make <target>_install

For example, to compile the Linux Kernel, you can use the following commands

host $ make linux_clean
host $ make linux
host $ make linux_install

In order to install the resulting binaries on your target, execute one of the "install" targets. Where the binaries are copied is controlled by the EXEC_DIR variable in ${INSTALL_DIR}/Rules.make. By default, this variable is set up to point to your NFS mounted target file system when you execute the installer setup (setup.sh) script, but can be manually changed to fit your needs.

You can remove all components generated files at any time using:

host $ make clean

And you can rebuild all components using:

host $ make all

You can then install all the resulting target files using:

host $ make install

Using eMMC Boot

eMMC boot method is the same as MMC/SD flashing and booting procedure. Format MMC/SD card and create boot/rootfs partition (refer to Software development setup section).

$ sudo ${INSTALL_DIR}/bin/mksdboot.sh --device /dev/sdY --sdk ${INSTALL_DIR}

The MMC/SD boot partition contains MLO,u-boot.img and uenv.txt. The rootfs partition contains ext4 file system with kernel & DTBs in rootfs/boot directory. Formatting of eMMC device can be done by using mk-eMMC-boot.sh script. Boot the EVM with MMC/SD boot mode first and then run the mk-eMMC-boot.sh script to create the eMMC partitions.

Partitioning and formatting eMMC

  • Boot kernel using MMC/SD boot mode (refer to Software development setup section).
  • mount the MMC/SD boot partition, create uenv-emmc.txt.
 # mount /dev/mmcblk1p1 /mnt
 # cp /mnt/uenv.txt /mnt/uenv-emmc.txt
 Note: edit /mnt/uenv-emmc.txt and set rootfs=/dev/mmcblk0p2 in bootargs.
  • consider /dev/mmcblk0 is eMMC device, then use the following script to partition the eMMC device.The mk-eMMC-boot.sh will create boot, rootfs partition on eMMC device and copy the all files from MMC/SD card to eMMC.

Note: Edit mk-eMMC-boot.sh script file and make sure "mmc_dev" point to appropriate MMC/SD device node (/dev/mmcblkX).

 #./mk-eMMC-boot.sh --device /dev/mmcblk0
  • reboot EVM to u-boot prompt, and set environment variables "mmcdev" and the "bootpart" point to eMMC device.
  #env default -a
  #setenv bootpart 1:2
  #setenv mmcdev 1
  #saveenv
  • Set boot switches to EMMC boot mode.
Set SW2[7..0] = 00111000
  • Remove MMC/SD card and reboot the EVM, now should boot from eMMC device.


Partitioning and formatting eMMC from Host PC through USB

The ums (USB Mass Storage feature) command in U-Boot can be used to expose the MMC as USB storage drive (/dev/sdX) to Host PC.

Syntax: ums <usb controller instance> mmc <mmc-instance>

  • Setup: Connect USB0 port of the EVM to Ubuntu host PC.

From U-boot prompt

  • Exposing MMC/SD as storage media
 => ums 0 mmc 0 
  • Exposing eMMC as storage media
=> ums 0 mmc 1 

This command will expose the mmc device as storage device (/dev/sdX) to Ubuntu PC, further user can mount and partition, format and copy the files to device.

Creating your own Linux kernel image

The pre-built Linux kernel image (zImage) provided with in the SDK installation folder is compiled with a default configuration. You may want to change this configuration for your application, or even alter the kernel source itself. This section shows you how to recompile the Linux kernel provided with the SDK, and shows you how to boot it instead of the default Linux kernel image.

1. If you haven't already done so, follow the instructions in #Starting_your_software_development to setup your build environment.

2. Recompile the kernel provided with the SDK by executing the following:

host $ cd ${INSTALL_DIR}
host $ make linux_clean
host $ make linux
host $ make linux_install

3. You will need a way for the boot loader (u-boot) to be able to reach your new zImage. Copy the new zImage that is generated in arch/arm/boot/ directory to the rootfs/boot folder.

4. Copy the exported Linux kernel modules from the EXEC_DIR to the /lib/modules directory to the root file system


Using the statistics collector (bandwidth application)

The default filesystem includes a utility to determine the bandwidth statistics of each initiator in the J6 SoC.

This section will give an overview of how the user can use this effectively.

Target side

The tool is called glsdkstatcoll and is present under the /usr/bin folder. This tool requires a config file as an input which is also part of the filesystem

Copy the sample config file into your working directory:

target # cp /etc/glsdkstatcoll/* .
target # glsdkstatcoll -h

There are two levels of configuration that the tool allows:

  1. Configuration of the interval and the total time can be controlled via config.ini
  2. The list of initiators can be configured using the initiators.cfg file.

Note that both these files have to be present under the current directory.

After configuration, the user can launch the tool as below:

target # glsdkstatcoll -f config.ini

The tool will run for the specified duration in seconds "TOTAL_TIME" in config.ini and will sample every "INTERVSAL_US" microseconds.

The results from this tool will be available in statcollector.csv

target # ls -al statcollector.csv

Host side

To visualize this data, first install matplotlib:

host # sudo apt-get install python-matplotlib
host # git clone git://git.ti.com/glsdk/example-applications.git
host # cd example-applications/bandwidth-tool/host

Since the analysis of the data will be done over many iterations, the user has been provided with a config file in which some basic configuration can be done.

host # vi configstat.ini # Set the IP Address of the target and also the directory where the statcollector.csv was generated

Once the above setup is completed, the data can be visualized as below:

host # python statcoll_plot.py

This will tool will do the following:

  1. Fetch the file from the target
  2. Figure out all the initiators that did not have any traffic and exclude them from the plot.
  3. Plot the total traffic from EMIF1_SYS and EMIF2_SYS ports
  4. Display the peak, average and average(active) traffic on the various ports.
  5. Note that if the INTERVAL_US is other than 30000 microseconds, user will have to edit the statcoll_plot.py

If the target does not have the Ethernet capabilities, then the file can be fetched and the same tool can be run like below:

host # python statcoll_plot.py -f <name of the file>

There are some further enhancements planned, they will be posted in the git place holder.

Setting up Tera Term

Tera Term is a commonly used terminal program on Windows. If you prefer to use it instead of Minicom, you can follow these steps to set it up.

1. Download Tera Term from this location, and start the application.

2. In the menu select Setup->General... and set:

Default port: COM1

3. In the menu select Setup->Serial Port... and set the following:

Port:         COM1
Baud rate:    115200
Data:         8 bits
Parity:       none
Stop:         1 bit
Flow control: none

Download the Latest GLSDK

The latest GLSDK is available for download from http://downloads.ti.com/infotainment/esd/jacinto6/glsdk/latest/index_FDS.html

GLSDK releases can be downloaded from http://downloads.ti.com/infotainment/esd/jacinto6/glsdk/

The current version is 6_04_00_02.