From Texas Instruments Embedded Processors Wiki

WARNING: The information presented here is for Demostrative Applications propuses, if you want to start products development using TI Gstreamer Plugins, see Platform Development and Testing of the TI GST Plugins 2.x Platform_Development_and_Testing_of_the_TI_GST_Plugin_2.x

Introduction

Arago provides a set of recipes and development infrastructure for building embedded distributions upon the OpenEmbedded meta-building system. This page describes the step by step instructions for setting up an Arago development directory and creating a tar.gz file with the TI GStreamer Plugin version 2.x. There is information 1.x versions of the plug-in available also.

Setting up Arago

Host Configuration

This set of steps assumes a Ubuntu 9.04 Linux distribution. Further steps for setting up a Ubuntu-based development environment are described at the Linux Host Configuration page. OpenEmbedded can be sensitive to the version of host applications - please update this page as you get the build to work on your favorite Linux distribution.

Setting up the Development Environment

Arago distributions are mostly self-contained and hosted in a local directory created by cloning several git repositories. The $OEBASE environment variable holds the location of the local Arago directory. For this particular example, the base directory is $HOME/workspace.

First, we are going to clone the overlay created for building the Gstreamer Binaries needed by TI GStreamer Plugin version 2.x.

cd $HOME/workspace
git clone git://arago-project.org/git/people/snunez/arago-gstti.git arago-gstti/

Then we define the $OEBASE variable and create the 'downloads' directory

export OEBASE=$HOME/workspace/arago-gstti
mkdir -p $OEBASE/downloads

Obtaining the Arago Distribution

Once the host tools are in place, a working Arago directory can be built. For a more through description of the build system configuration, visit the Setting Up Building Environment page at the Arago Web site.

cd $OEBASE
git clone git://arago-project.org/git/arago.git
git clone git://arago-project.org/git/arago-oe-dev.git
git clone git://arago-project.org/git/arago-bitbake.git

At the end of the process, you should end up with five directories inside $OEBASE: arago, arago-oe-dev, arago-bitbake, arago-custom and downloads.

Switching to the Next Branch

Arago repositories have a stable branch and a next branch. New platforms are being constantly added and improved in the next branch (with some experimental features). The stable branch is far behind what current development requires and therefore is not suitable for our task. For each cloned repository, move to the next branch.

cd $OEBASE/arago
git checkout -b next origin/next
cd $OEBASE/arago-oe-dev
git checkout -b next origin/next
cd $OEBASE/arago-bitbake
git checkout -b next origin/next

Setting up Helper Scripts

Arago requires some environment parameters for directing the build process. These are the files and modifications to them.

cd $OEBASE/arago
cp setenv.sample setenv

Edit the setenv file and set $OEBASE with the appropriate value:

# Set OEBASE to where Arago overlay and OpenEmbedded repositories reside
export OEBASE=$HOME/workspace/arago-gstti

# Set SCRATCH variable accordingly if you want to use scratch area
# export SCRATCH=/sim/scratch_AID

# Set the paths...
export BBPATH=$OEBASE/arago:$OEBASE/arago-oe-dev
export PATH=$OEBASE/arago-bitbake/bin/:$PATH

# The whitelist seems to be broken for now, thus preserve all the vars
export BB_PRESERVE_ENV=1
# export BB_ENV_EXTRAWHITE="OEBASE http_proxy ftp_proxy"

# Spawn three processes for compiling the Arago tree
export BB_NUMBER_THREADS=3

Create a base copy of the local.conf file. This file controls several parameters within Arago and should not be edited unless you get acquainted first with OpenEmbedded distributions.

cd $OEBASE/arago/conf
cp local.conf.sample local.conf

Arago is set by default to a machine specification named arago, a unified platform for building OMAP3 and DaVinci code. This is a unified version and normally does not need to be changed. In case you want or need to do so, please edit the local.conf file in line 91:

MACHINE ?= "arago"
# MACHINE = "omap3evm"
# MACHINE = "beagleboard"
# MACHINE = "davinci-dvevm"</code>

In order to generate the gstreamer binaries, we create the file gstti-preferred-versions.inc, containing the fixed versions needed for some distrubution files. This file needs to be included into angstrom-2008.1.conf file.

cd $OEBASE/arago/conf/distro
mcedit angstrom-2008.1.conf (or any other editor)

Please edit the angstrom-2008.1.conf file in line 37, be sure the line is added after angstrom-2008-preferred-versions.inc:

33  require conf/distro/include/sane-srcdates.inc
34  require conf/distro/include/sane-srcrevs.inc
35  require conf/distro/include/angstrom-2008-preferred-versions.inc
36  require conf/distro/include/preferred-opie-versions-1.2.4.inc
37  require ${OEBASE}/arago-custom/conf/gstti-preferred-versions.inc

Setting the Toolchain

After environment variables have been set, indicate what cross-compiler will be used. The following steps are performed assuming that the CodeSourcery Toolchain is installed. Instructions on how to find and setup the CodeSourcery Toolchain can be fount at the Getting CodeSourcery Toolchain page.

In this example, the toolchain is installed in /opt/codesourcery/arm-2009q1

export PATH=$PATH:/opt/codesourcery/arm-2009q1/bin

Running Bitbake

Once all previous steps have been performed, we are in place to build our TI GST images. The end result of the process will be a compressed tarball that can be overlayed on top of any Monta Vista based file system.

First, source the toplevel Arago helper script:

source $OEBASE/arago/setenv

Finally, run bitbake with the TI GST base image:

bitbake task-gstti-base

Creating the Gstreamer binaries

After bitbake creates the GST packages are located in $OEBASE/arago-tmp/deploy/ipk/armv5te, and after the process, you should end up with a list of packages similar to this one:

-rw-rw-r-- 1 snunez sdk    24992 2010-03-11 12:21 gst-plugin-aacparse_0.10.12-r2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk     1510 2010-03-11 12:21 gst-plugin-aacparse-dev_0.10.12-r2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk    16076 2010-03-11 12:21 gst-plugin-adder_0.10.25-r7.2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk     1530 2010-03-11 12:21 gst-plugin-adder-dev_0.10.25-r7.2.5_armv5te.ipk
...
-rw-rw-r-- 1 snunez sdk    37728 2010-03-11 12:21 libgstrtsp-0.10-0_0.10.25-r7.2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk    11904 2010-03-11 12:21 libgstsdp-0.10-0_0.10.25-r7.2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk    28916 2010-03-11 12:21 libgsttag-0.10-0_0.10.25-r7.2.5_armv5te.ipk
-rw-rw-r-- 1 snunez sdk    15998 2010-03-11 12:21 libgstvideo-0.10-0_0.10.25-r7.2.5_armv5te.ipk

The ipk package format works on the spirit of Debian packages. The final task for generating the images is to create a directory, unpack and obtain a file system that can be overlayed on top of the standard TI build system.

In Arago, the usual way to add our packages into the rootfs image is to use another recipe ( it would be something like gstti-base-image.bb). This kind of recipes have an image inherit from arago-base-image recipe, in order to avoid all the work that implies defining all of the ingredients that go into a functioning root file system image. However, we do not pretent to generate the entire root file system image, that is why we create the script "generate_gstti.sh", it does the final task, with just the gstreamer binaries necessary in a filesystem to test the ti-gstreamer-plugins.

cd $OEBASE
./generate_gstti.sh

You should obtain three directories in $OEBASE:

• gstti contains files that can be copied directly to the file system and executed. A tarball with the result of this procedure can be found here.
• gstti_dev  the same and also contains headers and static library files for development.
• gstti_src contains the gstreamer tarballs, as well as its dependent packages tarballs.

In case you want to test your own GStreamer applications, please refer to the particular documentation of the build system in use.

Patches against the GStreamer source

In order to provide support for the TI GST DMAI plugin, a serie of patches are required against the source of GStreamer, the GST plugins and dependency libraries. All the packages that needed to be patched, are listed in this chapter, as well as an explanation for each one of them.

To ensure the correct application of the patches, the versions of the dist_files have been fixed in the gstti-preferred-version.inc file. They are summarized in the following chart:

Packages patched

In arago-gstti overlay, we ported the patches applied by TI_BuildSystem

Glib-2.0

In this overlay, we create the recipe for glib-2.0_2.22.2, base on the recipe with version 2.22.1. For this last version, the open embedded project had patches to support correctly the new architectures with gatomic and the old ones with thumb. DM6446 will be tested against these fixes, and see if they are enough.

Gst-plugins-base

A recipe for the version required already exists in the OpenEmbedded project, as well as the patch needed to fix playbin2. The problem fixed is that this element does not create audio/video sink elements when flags property is set to configure the native audio/video sink, so the patch handles the native audio/video flags accurately.

Gst-plugins-good

We create the recipe for the version 0.10.16, the one required. Previous versions on the Open Embedded project used a patch to "fix-unit-scale-assertation", however, in this version the source code already include the logic for that fix, so the patch was not included anymore.

TI Build System use to apply three patches adding the support for the TI-LSP and other changes needed, the "fix-OSS-support-to-handle-all-supported-sample-rates" and "fix-for-streaming-encode-with-rtph264pay", were included in the overlay without any change.By the other hand, the "support-for-non-standard-colorspaces-and-custom-V4L2" was divided into several patches: the first one add the v4l2src_davinci files, the second one all the general functionality for custom TI LSP, basically all those changes included in the old patch if the DAVINCI_LSP_WORKAROUND variable was defined, and the last patches adding specific functionalities depending on the platform(dm365,dm6467, dm357). These patches were configured in the recipe to be applied just if the specific platform was selected.

Gst-plugins-bad

This package does not need any special patch, is it added in the overlay just to have the recipe with the version required.

Gst-plugins-ugly

It was necessary to create a recipe for the version 0.10.13, and the patch that support gstmad in 16 bits had been already added in previous version in the OpenEmbedded project, so the OE patch was the one used.

Libmad

A recipe for the version requiered already exists in the OpenEmbedded project, as well as the patch needed to add the pkgconfig functionality. Changes on Makefile.in added by the TI-BuildSystem patch seems to be not necessary. Indeed, changes done by a patch in this file could be lost when bitbake executes the configure command. Testing will be done to ensure that changes done by OE patch are enough.

Libid3tag

A recipe for the version required already existed in the OpenEmbedded project. However, we created an overlay of this recipe to apply a patch adding the pkgconfig functionality, in the same way it was done by OpenEmbedded with the Libmad package.

Liboil

A recipe for the version required was added in this overlay, however the patch needed to fix liboil preprocessor checks had been already added in the open embedded project in previous version of the packages, so the same patches were applied. Liboil was building hand-coded VFP assembly, but the check for VFP support was not correct. The OE patch fixes the check for VFP.

TI-BuildSystem patches ported to the arago-gstti overlay

Just to clarify, the following chart summarizes the patches included in the TI-BuildSystem, and how they were ported in the overlay.

Deploying a GST TI distribution

In order to deploy GST TI it is required to have a working environment for the architecture of your interest. Further information on how to set up a build system and get started with a particular architecture is available at the TI Wiki.

The Arago-based overlay is intended to replace the build system from where GStreamer is currently included. Some of its advantages are:

• It uses OpenEmbedded, a reproducible environment that TI has targeted for all its future developments
• Once configured, the only download required is an overlay with the TI plugin, not a complete build environment
• No environment variables are needed for correct operation
• The file system overlay is deployed in /usr and /etc directly, avoiding complications experienced usually when running from /opt

The following table describes the status of support for various architectures with respect to the overlay. Support for an architecture implies the overlay has been tested with Test Pipelines and does not present problems with the glibc and libc versions included in the file system.

Deployment procedure for the GST overlay

Host

1. Setup the board with the kernel image and file system. For testing purposes, an NFS shared directory is prefered.
2. In the root file system, copy all the files from the obtained overlay.

cd $(ROOTFS)
sudo cp -Rf -R $OEBASE/gstti/* .

ROOTFS is the location of the target file system, an NFS export the target mounts via bootargs.

Target

1. Power-cycle the board and login into Linux via a terminal (serial)
2. The gst-inspect and gst-launch should be available for testing. A simple test is:

gst-launch videotestsrc ! fakesink -v

Testing

In order to test the overlay, three important items must be completed once the board boots after a power-cycle:

1. GStreamer commands are available and correctly deployed
2. The plugins are available for use
3. A test pipeline is able to run

For ensuring the executables are in place, issue the commands

which gst-inspect
which gst-launch

If correctly deployed from the overlay, both commands should indicate the paths /usr/bin/gst-inspect and /usr/bin/gst-launch respectively.

In order to check for a correct installation of plugins and elements, execute

gst-inspect | wc -l

If your installation is working fine, the following output will show up

gstsiren:  sirenenc: Siren Encoder element
gstsiren:  sirendec: Siren Decoder element
gstrtpmanager:  gstrtpssrcdemux: RTP SSRC Demux
gstrtpmanager:  gstrtpsession: RTP Session
gstrtpmanager:  gstrtpptdemux: RTP Demux
gstrtpmanager:  gstrtpjitterbuffer: RTP packet jitter-buffer
...
dvdlpcmdec:  dvdlpcmdec: DVD LPCM Audio decoder
staticelements:  bin: Generic bin
staticelements:  pipeline: Pipeline object

Total count: 128 plugins, 418 features

The next step, testing a basic (fake) pipeline, can be performed with the following command

gst-launch fakesrc ! fakesink -v

After you verify that buffers are being generated and consumed, test ALSA input and output

gst-launch alsasrc ! alsasink -v

Finally, try reading an MPEG4 video from file and sending it to a fake sink. For this particular example, the MPEG4 640x360 version of Big Buck Bunny is used and assumed to be in the directory where the pipeline is run.

gst-launch filesrc location=BigBuckBunny_640x360.mp4 ! fakesink -v

Common Errors and Pitfalls

This section is devoted to speedup detection of errors during the build process and diminish the startup time for new users. Here are listed some of the common errors and pitfalls and how to solve them.

Error: some package fails to build

Example:

NOTE: Handling BitBake files: \ (7887/8212) [96 %]ERROR: Error in executing: /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_svn.bb
ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'check_gcc3' is not defined
ERROR: Printing the environment of the function
ERROR: 	0003:    __anon_70_classes_packaged_staging_bbclass(d)
ERROR: 	0004:    __anon_37_classes_src_distribute_local_bbclass(d)
ERROR: 	0005:    __anon_148__home_snunez_workspace_arago_arago_oe_dev_classes_package_bbclass(d)
ERROR: 	0006:    __anon_315_classes_package_ipk_bbclass(d)
ERROR: 	0007:    __anon_123__home_snunez_workspace_arago_arago_oe_dev_classes_native_bbclass(d)
ERROR: 	0008:    __anon_10__home_snunez_workspace_arago_arago_oe_dev_recipes_qemu_qemu_gcc3_check_inc(d)
ERROR: 	0009:
ERROR: global name 'check_gcc3' is not defined while parsing /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_svn.bb
ERROR: Error in executing: /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_cvs.bb
ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'check_gcc3' is not defined
ERROR: Printing the environment of the function
ERROR: 	0003:    __anon_70_classes_packaged_staging_bbclass(d)
ERROR: 	0004:    __anon_37_classes_src_distribute_local_bbclass(d)
ERROR: 	0005:    __anon_148__home_snunez_workspace_arago_arago_oe_dev_classes_package_bbclass(d)
ERROR: 	0006:    __anon_315_classes_package_ipk_bbclass(d)
ERROR: 	0007:    __anon_123__home_snunez_workspace_arago_arago_oe_dev_classes_native_bbclass(d)
ERROR: 	0008:    __anon_10__home_snunez_workspace_arago_arago_oe_dev_recipes_qemu_qemu_gcc3_check_inc(d)
ERROR: 	0009:
ERROR: global name 'check_gcc3' is not defined while parsing /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_cvs.bb
ERROR: Error in executing: /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_20070613.bb
ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'check_gcc3' is not defined
ERROR: Printing the environment of the function
ERROR: 	0003:    __anon_70_classes_packaged_staging_bbclass(d)
ERROR: 	0004:    __anon_37_classes_src_distribute_local_bbclass(d)
ERROR: 	0005:    __anon_148__home_snunez_workspace_arago_arago_oe_dev_classes_package_bbclass(d)
ERROR: 	0006:    __anon_315_classes_package_ipk_bbclass(d)
ERROR: 	0007:    __anon_123__home_snunez_workspace_arago_arago_oe_dev_classes_native_bbclass(d)
ERROR: 	0008:    __anon_10__home_snunez_workspace_arago_arago_oe_dev_recipes_qemu_qemu_gcc3_check_inc(d)
ERROR: 	0009:
ERROR: global name 'check_gcc3' is not defined while parsing /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_20070613.bb
NOTE: Handling BitBake files: / (7893/8212) [96 %]ERROR: Error in executing: /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_0.9.1.bb
ERROR: Exception:<type 'exceptions.NameError'> Message:global name 'check_gcc3' is not defined
ERROR: Printing the environment of the function
ERROR: 	0003:    __anon_70_classes_packaged_staging_bbclass(d)
ERROR: 	0004:    __anon_37_classes_src_distribute_local_bbclass(d)
ERROR: 	0005:    __anon_148__home_snunez_workspace_arago_arago_oe_dev_classes_package_bbclass(d)
ERROR: 	0006:    __anon_315_classes_package_ipk_bbclass(d)
ERROR: 	0007:    __anon_123__home_snunez_workspace_arago_arago_oe_dev_classes_native_bbclass(d)
ERROR: 	0008:    __anon_10__home_snunez_workspace_arago_arago_oe_dev_recipes_qemu_qemu_gcc3_check_inc(d)
ERROR: 	0009:
ERROR: global name 'check_gcc3' is not defined while parsing /home/snunez/workspace/arago/arago-oe-dev/recipes/qemu/qemu-native_0.9.1.bb
NOTE: Handling BitBake files: \ (8212/8212) [100 %]
NOTE: Parsing finished. 7543 cached, 316 parsed, 349 skipped, 161 masked.
ERROR: Parsing errors found, exiting...

Solution: update all three respositories with git pull

Error: Python reports deprecation warning and process fails

Example:

/var/lib/python-support/python2.6/bb/COW.py:29: DeprecationWarning: the sets module is deprecated
  import types, sets
ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable.
snunez@optimus:~/workspace/arago$ export CACHE=$OEBASE/cache
snunez@optimus:~/workspace/arago$ bitbake arago-base-image
/var/lib/python-support/python2.6/bb/COW.py:29: DeprecationWarning: the sets module is deprecated
  import types, sets
ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable.

Solution: source the $OEBASE/arago/setenv script

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Building GStreamer Binaries with Arago here.

	Links
	ARM Microcontroller MCU ARM Processor Digital Media Processor Digital Signal Processing Microcontroller MCU Multi Core Processor Ultra Low Power DSP 8 bit Microcontroller MCU 16 bit Microcontroller MCU 32 bit Microcontroller MCU

Comments

Comments on Building GStreamer Binaries with Arago

A0693620 said ...

Jguillot said ...

fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/next' which can not be resolved as commit?

Jguillot said ...