ECE597 BeagleBoard DSP Software Setup

From eLinux.org
Revision as of 15:02, 14 April 2010 by Embrybd (talk | contribs) (Preparing to install)
Jump to: navigation, search


This is an adaptation of GSG: OMAP35x_DVEVM Software Setup for the BeagleBoard. Presently it's a work-in-progress. Follow the instructions and make corrections as you go. Change references to DVEVM to Beagle once you've tested a section and know it's correct. There are several links that pointed to pages on the original wiki. Fix them if you know how.

Software Overview

To begin developing applications, you need to install the Beagle development environment. This section outlines the steps required to load the Beagle software onto the development host. You will need to download the files from the Download page to get started.

The OMAP35x software approach provides interoperable, optimized, production-ready video and audio codecs that leverage DSP and integrated accelerators. These codecs are built into configurable frameworks, and are presented via published APIs within popular operating systems (such as Linux) for rapid software implementation.

The following software is provided in the Download page.

  • TI DVSDK Software. This includes demo applications, codec engine software, example codec servers, DVTB and DVSDK documentation. It contains the following files.
  • Getting Started Guide (this link)
  • DVSDK Product Release Notes
  • DVSDK Product Installer (dvsdk_#_##_##_##_Setup.bin)
  • OMAP3525/OMAP3530 DVSDK Collaterals
  • Linux TSPA DSP Codec Server Installer (cs1omap3530_setupLinux_1_00_01-03.bin)
  • Linux TSPA DSP Codec Server Release Notes
  • Demonstration Multimedia Files-containing audio and video clips (data_dvsdk_#_##_##_##.tar.gz)
  • DVSDK OMAP3525/3530 Demo Overlay containing prebuilt DVSDK Binaries/Multimedia files. This should be added to an existing PSP file system (overlay_dvsdk_#_##_##_##.tar.gz)
  • Complete DVSDK file system including Pre-built DVSDK Binaries [overlay] and self starting DVSDK demos - suitable for NFS mount (nfs_dvsdk_#_##_##_##.tar.gz)
  • Complete DVSDK file system including Pre-built DVSDK Binaries [overlay] and self starting DVSDK demos - JFFS2 file system format [NAND flash] (rootfs_dvsdk_#_##_##_##.jffs2)
  • I don't know if these will work on the Beagle:
    • Prebuilt Kernel image for OMAP3525 and OMAP3530 default configuration (uImage-omap35x-evm.bin - Note that this is not a binary installer but needs to be renamed to uImage-omap35x-evm to use it for booting on OMAP3x EVM)
    • Prebuilt u-boot image for OMAP3525 and OMAP3530 default configuration (u-boot-omap35x-evm.bin)
  • Linux Platform Support Package
  • PSP Release Notes
  • PSP User Guide
  • PSP Data Sheet
  • PSP Product Installer(AM35x-OMAP35x-PSP-SDK-setuplinux-##.##.##.##.bin) - This installation file contains the linux source and binaries for OMAP35x platform and the necessary tools required for development on Linux for OMAP35x platform. This also contains the target file system


Command prompts in this guide

Commands are preceded by prompts that indicate the environment where the command is to be typed. For example:

host $ 
Indicates command to be typed into the shell window of the host Linux workstation.
Beagle # 
Indicates commands to be typed into the U-Boot shell in a console window connected to the EVM board’s serial port. (see Setup Terminal Program for EVM instructions. We need Beagle instructions).
target $ 
Indicates commands to be typed into the Linux shell in the terminal window connected to the Beagle board's serial port.


NOTE: The document lists down various commands that needs to be executed on the target or on the u-boot prompt for various operations required through out the document. Kindly note that a direct copy and paste of these commands might result in insertion of lines for a single command. Hence it would not work on the u-boot prompt or the target. Kindly ensure that you copy the long commands into notepad, remove the line spaces between them and add a space wherever you have removed the line spaces, before recopying and pasting it on the command prompts.

Preparing to install

On a host system, copy the following .bin files from the Download page to a temporary location with at least 2 GB free space. Since you can delete the installation files after installing the software, a directory like /tmp is recommended.

(I have copies of these that you can sftp from afs.rose-hulman.edu. They are in users/faculty/yoder/Public/beagle/downloads.)

  • AM35x-OMAP35x-PSP-SDK-setuplinux-##.##.##.##.tgz
  • dvsdk_#_##_##_##_Setup.bin
  • xdctools_setuplinux_#_##_##.bin
  • bios_setuplinux_#_##_##.bin
  • TI-C6x-CGT-v#.#.##.#.bin
  • cs1omap3530_setupLinux_#_##_##-##.bin
  • overlay_dvsdk_#_##_##_##.tar.gz
  • nfs_dvsdk_#_##_##_##.tar.gz
  • rootfs_dvsdk_#_##_##_##.jffs2
  • data_dvsdk_#_##_##_##.tar.gz

Ensure all the .bin files are set with executable permissions.

host $ chmod +x *.bin


Installing the software

Installing the software used by the DVEVM involves performing the following steps:


Installing the Target Linux Software

This section explains how to install Linux for use on the target board.

Note that separate versions of Linux are used by the target and your host Linux workstation. The following Linux host operating systems have been used with the Beagle.

  • Ubuntua 9.10, x86 32 bit

To install the Linux software, follow these steps:

  1. Move AM35x-OMAP35x-PSP-SDK-setuplinux-##.##.##.##.tgz file (where ##.##.##.## is the current version number) from the temporary location that it was copied to your home directory.
    host $ mv AM35x-OMAP35x-PSP-SDK-setuplinux-##.##.##.##.tgz /home/<useracct>
    host $ cd
    host $ tar xvzf  AM35x-OMAP35x-PSP-SDK-setuplinux-##.##.##.##.tgz
  2. In future, all references in the document will assume that the user has installed the OMAP35x SDK using his user account and hence will refer to the OMAP35x SDK installation path as /home/<useracct>/AM35x-OMAP35x-PSP-SDK-##.##.##.##

Note: The Linux Support Package (LSP) is a multi-platform LSP and is not configured for a particular platform. As shipped, this LSP cannot be used to build the demo or example applications. It must first be copied to a user area and configured/built for the Beagle. Please see the Rebuilding the Linux Kernel section for instructions.

Installing the DVSDK Software

The TI DVSDK software includes demos, example software, Codec Engine components, DSP/BIOS Link, xDAIS and xDM header files, Local Power Manager Module, Framework Components and a contiguous memory allocator for Linux (CMEM). The DVSDK also contains the Digital Video Test Bench that enables testing the codecs and LSP with various configurations that are not possible with the Out of the Box demos.

Note: The installers for XDC, DSP/BIOS and Code Generation Tools (codegen) have a different default installation location. However, we strongly recommend that you change the default installation locations to place the components together (if you have not already installed the Linux versions of these components elsewhere). This simplifies the build setup steps.

To install the DVSDK software using the DVSDK Linux installer, follow these steps:

  1. Log in using a user account. In the following steps, we refer to the home directory as "~".
  2. Execute the DVSDK installer that you previously downloaded from the DVSDK download page. For example:
    host $ chmod +x dvsdk_#_##_##_##_Setup.bin
    host $ ./dvsdk_#_##_##_##_Setup.bin

    The installer will start as a GUI application. Follow the instructions in the dialog boxes. You’ll be asked to agree to the End User License Agreement. When you are prompted for an installation location, use the default installation location, that points to /home/<useracct>/dvsdk/dvsdk_#_##_##_##. This location will be used as the DVSDK installation folder through out this document.

  3. Execute the XDC installer that you previously downloaded from the DVSDK download page. For example:
    host $ chmod +x xdctools_setuplinux_#_##_##.bin
    host $ ./xdctools_setuplinux_#_##_##.bin

    When you are prompted for an installation location, do not use the default installation location. Instead, install the software in the directory created in the previous step. For example, /home/<useracct>/dvsdk/dvsdk_#_##_##_##/xdctools_#_##_##_##

    NOTE: When prompted select Typical for the type of Setup.

  4. Execute the DSP/BIOS installer that you previously downloaded from the DVSDK download page. For example:
    host $ chmod +x bios_setuplinux_#_##_##.bin
    host $ ./bios_setuplinux_#_##_##.bin

    When you are prompted for an installation location, do not use the default location. Instead, install the software in the directory created in step 2. For example, /home/<useracct>/dvsdk/dvsdk_#_##_##_##/bios_#_##_##_##

  5. Execute the Codec Server installer that you have previously downloaded from the DVSDK download page. For example:
    chmod +x cs1omap3530_setupLinux_#_##_##-##.bin
    host $ ./cs1omap3530_setupLinux_#_##_##-##.bin

    When you are prompted for an installation location, install it in the location as specified or under the directory as created in step 2. For example, /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_##_##

  6. Execute the Code Generation Tools installer that you previously downloaded from the DVSDK download page. The download link looked like TI-C6x-CGT-v#.#.##.#.bin; however the file you downloaded looked like ti_cgt_c6000_#.#.#_setup_linux_x86.bin. Run this file. For example:
    host $ chmod +x ti_cgt_c6000_#.#.#_setup_linux_x86.bin
    host $ ./ti_cgt_c6000_#.#.#_setup_linux_x86.bin

    When you are prompted for an installation location, install it in the location as specified or under the directory as created in step 2. If you are installing it under the DVSDK installation folder created in step 2, create a new folder under the dvsdk installation folder and then proceed to install. For example, /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_##, where #_#_## is the version number.

  7. Remember to set the environment variable as directed by the installer. For example: csh: (in the .cshrc file)
    host $ setenv C6X_C_DIR /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_#/include:/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_#/lib

    ksh or bash: (in the .bashrc file)

    host $ export C6X_C_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_#/include:/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_#/lib
  8. You can now delete the .bin files that you loaded into the temporary directory.

Note: You can uninstall these components by using the uninstall file in the respective installation directories. For example:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/xdctools_#_#_#
host $ ./uninstall 


Installing the A/V demo files

These are very big, so I skipped them. --may

The TI DVSDK software installer, by itself does not contain the media files used by the demos. You can download the data files from DVSDK download page. Please use the steps mentioned below for extracting the media files into the desired location.

The Download page contains the Audio/Video files used by the demo. After following the instructions in the previous section, follow these instructions to install the A/V files:

  1. Go to the DVSDK directory that you set up previously. For example
    host $ cd ~/dvsdk/dvsdk_#_##_##_##/clips
  2. Copy the A/V data which you have downloaded from Download page to your DVSDK clips directory.For example:
    host $ cp data_dvsdk_#_##_##_##.tar.gz .
  3. Extract the A/V data files. For example:
    host $ tar -xvzf data_dvsdk_#_##_##_##.tar.gz
  4. Now you can delete the tar file from the clips folder.


Installing the toolchain

This guide assumes use of the LITE version of the CodeSourcery toolchain.

Toolchain version to be used for DVSDK v3.01

The toolchain used is ARM GNU/Linux EABI 2009q1. It can be downloaded from here

To install the toolchain, follow the sequence below. These are to be executed on the Linux host platform.

$ mkdir –p /home/<useracct>/toolchain
$ cp arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 /home/<useracct>/toolchain
$ cd /home/<useracct>/toolchain
$ tar -jxvf  arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
$ rm arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

I haven't tested these sections on use NFS

Exporting a Shared File System for Target Access

Although the board’s NAND flash contains a file system, during development it is more convenient to have the target board NFS mount a file system on a host Linux workstation. Once you test the application, you can store it on the board’s flash for a standalone demonstration.

Before the board can mount a target file system, you must export that target file system on the host Linux workstation. The file system uses an NFS (Network File System) server. The exported file system will contain the target file system and your executables.

To export the file system from your NFS server, perform the following steps. You only need to perform these steps once.

  1. Log in with a user account on the host Linux workstation. (In the following steps, we refer to the home user directory as "~".)
  2. Perform the following commands to prepare a location for the OMAP35x EVM target file system.
    host $ cd ~
    host $ mkdir -p workdir/filesys
    host $ cd workdir/filesys
    
  3. Switch user to "root" on the host Linux workstation.
    host $ su 
    password:
    

    There will be a prompt for entering the password as shown above. Type the root password, for getting the root permissions

  4. If you have already prepared a directory tree to use for the NFS root file-system (see Section Rebuilding the NFS Image) you can proceed to the next step. Otherwise, copy the prepared version(nfs_dvsdk_#_##_##_##.tar.gz) from the OMAP3530 DVSDK from the Download page to a new directory created in step 2. Perform the following commands. Note:Un-tar the file with root permissions
    $ cp /tmp/nfs_dvsdk_#_##_##_##.tar.gz .
    $ tar –xvzf nfs_dvsdk_#_##_##_##.tar.gz
    
  5. Make sure you can write into the opt folder in the file system by setting the permissions of the opt folder within the target file system with your user account. Perform the following command
    host $ chown -R <useracct> /home/<useracct>/workdir/filesys/opt

    Alternatively, if you want to have permissions to write or create folders within the target file system that you want to export as NFS, perform the following command

    host $ chown -R <useracct> /home/<useracct>/workdir/filesys
  6. Make sure the NFS server is configured and functioning properly. Add the following line to the /etc/exports file of the server. Ensure you have root permission before editing this file.
    /home/<useracct>/workdir/filesys 	*(rw,no_root_squash,no_all_squash,sync)

    NOTE: On some systems you may wish to add the no_subtree_check option to avoid warnings like:

     exportfs: /etc/exports [3]: Neither 'subtree_check' or 'no_subtree_check' specified for export <export listed here>.
       Assuming default behaviour ('no_subtree_check').
       NOTE: this default has changed since nfs-utils version 1.0.x
    
  7. Then issue the following command to notify the NFS server about the new exported directory.
    host $ /usr/sbin/exportfs –a
    ''' For Redhat Linux''' 
    host $ /sbin/service nfs restart
    ''' For Ubuntu''' 
    host $ /etc/init.d/nfs-kernel-server restart
    
    
  8. Verify that the server firewall is turned off:
    host $ /etc/init.d/iptables status

    If the firewall is running, disable it:

    host $ /etc/init.d/iptables stop
  9. Make sure you exit from having the root permissions after completing all the above steps
    host $ exit


Testing the shared file system

To test your NFS setup, follow these steps:

  1. Get the IP address of your host Linux workstations as follows. Look for the IP address associated with the eth0 Ethernet port.
    host $ /sbin/ifconfig
  2. Open a terminal emulation window to connect to the EVM board via RS-232 using the instructions in the Setup Terminal Program topic. If you have a Windows workstation, you can use HyperTerminal. If you have a Linux workstation, you might use Minicom. (You may need to turn on line wrap.)
  3. Power on the EVM board, and abort the automatic boot sequence by pressing a key in the console window. This gets you into the U-Boot prompt where you can configure how U-Boot will boot the Linux kernel.
  4. Set the following environment variables in the console window:
    EVM # setenv nfshost <ip address of nfs host> 
    EVM # setenv rootpath <directory to mount>

    For DVSDK Releases from 3.00.00.36 upto and including 3.00.01.42, use the following bootargs:

    EVM # setenv bootargs "console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock mem=88M
                           omapfb.rotate=1 omapfb.rotate_type=1 omap_vout.vid1_static_vrfb_alloc=y"

    For DVSDK release 3.00.02.44, use the following bootargs:

    EVM # setenv bootargs "console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock mem=99M
                           mpurate=600 omapfb.rotate=1 omapfb.rotate_type=1 omap_vout.vid1_static_vrfb_alloc=y"

    Note that the setenv bootargs command should be typed on a single line. Also note that you should avoid using the numeric keypad to enter numbers, as it can sometimes insert extra invisible characters. These environment variables must be typed in perfectly including capitals, if anything is typoed you will likely run into boot errors.

    The <directory to mount> must match what you specified in Step 5 of the Exporting a shared file system for target access section. For example, /home/<user>/workdir/filesys.

    Hints: If the kernel version stored in the NAND flash on the EVM is out of date you may wish to flash the latest kernel image (using the uImage file in the /home/<useracct>/AM35x-OMAP35x-PSP-SDK-##.##.##.##/images/kernel directory) or boot using TFTP

    Hints: You may want to use the printenv command to print a list of your environment variables. You can also save these setenv commands in a .txt file from which you can paste them in the future.

  5. Save the environment so that you don't have to retype these commands every time you cycle power on the EVM board:
    EVM # saveenv
  6. Boot the board using NFS:
    EVM # boot
  7. You can now log in as "root" with no password required. See the Alternate boot methods section for information about booting with TFTP, NFS, or the board's NAND flash.


Notes on using production codecs

As part of the OMAP35x DVSDK installation, you received a number of codecs:

  • MPEG4 Simple Profile Decoder. This decoder is compliant with IVIDDEC2 Interface
  • H.264 Base Profile Decoder. This decoder is compliant with IVIDDEC2 Interface
  • MPEG2 Main Profile Decoder. This decoder is compliant with IVIDDEC2 Interface
  • Sequential JPEG Decoder. This decoder is compliant with IIMGDEC1 Interface
  • MPEG4 Simple Profile Encoder. This decoder is compliant with IVIDENC1 Interface
  • H.264 Base Profile Encoder. This decoder is compliant with IVIDENC1 Interface
  • JPEG Encoder. This encoder is compliant with IIMGENC1 Interface
  • Advance Audio Codec (AAC) Decoder. This decoder supports both AAC-HE and AAC-LC configurations. It is compliant with IAUDDEC1 interface
  • G.711 Speech Decoder. This decoder is compliant with ISPHDEC1 interface
  • G.711 Speech Encoder. This encoder is compliant with ISPHENC1 interface

NOTE: Though the standalone codec server contain JPEG decode, the DVSDK decode demos do not support playback of JPEG streams. In order to evaluate these decoders, use Digital Video Test Bench (DVTB) which is included in the OMAP3530 DVSDK. The media files for MPEG2 MP and JPEG format streams are not available as part of the DVSDK installation, but they are available as part of data_dvsdk_#_##_##_##.tar.gz that can be downloaded from the OMAP software update site http://www.ti.com/omapsoftwareupdates

Setting up the build/development environment

To set up the development and build environment, follow these steps:

  1. Log in to your user account (and not as root) on the NFS host system.
  2. Add the /host/<useracct>/toolchain/<toolchain_version>/bin directory to your path. This is typically done by adding an additional line to your shell resource file (~/.bashrc). For the path given above, the line to add to your .bashrc file is:
    PATH=“/home/<useracct>/toolchain/<toolchain_version>/bin:$PATH”

    This adds the CodeSourcery tools to your path and allows you to execute the tools using arm-none-linux-gnueabi-gcc (or other tools in the tool chain) from any directory.

  3. Remember to use the following command after modifying your .bashrc file. The source command essentially executes the .bashrc script so that the path you just added to it is added to your environment variables:
    host $ source .bashrc
  4. You can test that the toolchain is installed correctly by starting a new shell and using the following command:
    host $ arm-none-linux-gnueabi-gcc –v

    When you execute this command, you will get an output like the one shown below.

    Using built-in specs.
    Target: arm-none-linux-gnueabi
    Configured with: /scratch/sandra/lite/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 2008q1-126 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/libc --enable-poison-system-directories --with-build-time-tools=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/bin
    Thread model: posix
    gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)
    


Writing a simple program and running it on the EVM

Make sure you have performed the steps in the Exporting a shared file system for target access section and the Setting up the build/development environment section before continuing with the steps in this section.

Perform the following steps on the NFS host system as user (not as root):

  1. host $ mkdir –p ~/workdir/filesys/opt/hello
  2. host $ cd ~/workdir/filesys/opt/hello
  3. Create a file called hello.c with the following contents:
    #include <stdio.h>
    
    int main() {
    printf("Welcome to OMAP35x World!\n");
    return 0;
    }
    
  4. Build the new C file:
    host $ arm-none-linux-gnueabi-gcc hello.c -o hello


    Perform the following steps on the target board. You may use either the target's console window (see Setup Terminal Program) or a telnet session.

  1. Move to the new directory on the target:
    target $ cd /opt/hello
  2. Run the new executable:
    ./hello

The output should be:

Welcome to OMAP35x World!


Rebuilding the Software

This section describes how to rebuild pieces of the software delivery. Ensure that the toolchain setup and install has been completed (see Installing the Toolchain).

Rebuilding U-boot

Rebuilding the U-boot is described in more detail in the LSP User’s Guide available at AM35x-OMAP35x-PSP-SDK-##.##.##.##/docs/omap3530/UserGuide-##.##.##.##.pdf

Copy the U-Boot source archive from AM35x-OMAP35x-PSP-SDK-##.##.##.##/src/u-boot directory into your working directory

host $ cd ~
host $ mkdir –p workdir/opt
host $ cp /home/<useracct>/AM35x-OMAP35x-PSP-SDK-#.##.##.##/src/u-boot/u-boot-##.##.##.##.tar.gz ~/workdir/opt/.

Un-tar the U-Boot source archive by performing the command given below.

host $ cd workdir/opt
host $ tar -zxvf u-boot-##.##.##.##.tar.gz

To configure U-Boot for building, issue the following commands:

host $ cd uboot-##.##.##.##
host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean
host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_config

Once ready to build U-Boot, run the command:

host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm

The resulting U-Boot image named u-boot.bin will be in the current directory, ready to be loaded on the target.

Rebuilding the Linux Kernel

Rebuilding the kernel is described in more detail in the User’s Guide available at AM35x-OMAP35x-PSP-SDK-##.##.##.##/docs/omap3530/UserGuide-##.##.##.##.pdf

Note that building the kernel requires using mkimage, a host side utility built by the u-boot makefile. If you have not already done so please build u-boot using the instructions in the Rebuilding U-Boot section. You will need to build U-boot and place mkimage in your Path. A command like below can be used. If you are using a bash shell, kindly add the following in the .bashrc file in your user account.

export PATH=/<path_to_uboot>/tools:$PATH

Copy the Linux kernel source archive from AM35x-OMAP35x-PSP-SDK-##.##.##.##/src directory into your working directory.

host $ cd ~
host $ mkdir –p workdir/opt
host $ cp /home/<useracct>/AM35x-OMAP35x-PSP-SDK-##.##.##.##/src/kernel/linux-##.##.##.##.tar.gz ~/workdir/opt/.

Un-tar the Linux kernel source archive by performing the commands given below.

host $ cd /home/<useracct>/workdir/opt
host $ tar -zxvf linux-##.##.##.##.tar.gz

In order to prepare the kernel for building, follow these commands:

host $ cd linux-##.##.##.##
host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_defconfig

If you need to make changes to the default configuration, perform the following command.

host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm menuconfig

Once ready to build the kernel, run the following command

host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm uImage modules

The resulting kernel image uImage will be placed under arch/arm/boot and is ready to be loaded on the target.

Once the modules are built they must be installed on the target file system in order to be used. The following command will install the modules to the target file system and create the modules dependency file.

host $ su root
host $ make CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=<target filesys dir> modules_install

For example if you have been following the Getting Started Guide you should have created a target file system at /home/<useracct>/workdir/filesys. In the above command you should replace <target filesys dir> with /home/<useracct>/workdir/filesys.

Rebuilding the DVSDK software for the target

To place demo files in the /opt/dvsdk directory, you need to rebuild the DVSDK software. To do this, follow these steps:

  1. If you have not already done so, rebuild the Linux kernel as described in the Rebuilding the Linux Kernel section.
  2. Change directory to dvsdk_#_##_##_##.
  3. Edit the Rules.make file in the dvsdk_#_##_##_## directory.
    host $ vi Rules.make
  4. Check the following directory definitions. If you installed components in the default locations, the directory definitions may already be correct, but you should verify them in any case.
    • Set PLATFORM to match your EVM board as follows (Note that this variable is case sensitive):
      PLATFORM=omap3530
    • Set DVSDK_INSTALL_DIR to the top-level DVSDK installation directory as follows, note that by default ${HOME} refers to your /home/<useracct> directory:
      DVSDK_INSTALL_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##
    • Modify the following variable as needed to match the location of XDCtools on your Linux host. We recommend that XDCtools be installed in the /home/<useracct>/dvsdk/dvsdk_#_##_##_## directory, but you may have installed it elsewhere.
      XDC_INSTALL_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##/xdctools_#_##_##_##
    • Make sure EXEC_DIR points to the opt directory on the NFS exported file system as follows. Refer Exporting a Shared File System for Target Access for setting up the NFS exported file system.
      EXEC_DIR=/home/<useracct>/workdir/filesys/opt/dvsdk/omap3530
    • Make sure UBOOT_INSTALL_DIR is defined as follows so it points to where you copied the uboot source in the Rebuilding U-Boot section.
      UBOOT_INSTALL_DIR=/home/<useracct>/workdir/opt/uboot-##.##.##.##
    • Make sure LINUXKERNEL_INSTALL_DIR is defined as follows so it points to where you copied the Linux kernel tree in the Building a New Linux Kernel section.
      LINUXKERNEL_INSTALL_DIR=/home/<useracct>/workdir/opt/linux-##.##.##.##
    • Make sure OMAP3503_SDK_INSTALL_DIR is defined as follows. (If you have installed it in a different location, ensure you set the correct path).
      OMAP3503_SDK_INSTALL_DIR=/home/<useracct>/AM35x-OMAP35x-PSP-SDK-##.##.##.##
    • Make sure CODEC_INSTALL_DIR is defined as follows. (If you have installed it in a different location, ensure you set the correct path).
      CODEC_INSTALL_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_##
    • Change the path of the CSTOOL_DIR to point to the location where you have installed the CodeSourcery tool-chain. (Refer Installing the Toolchain)
      CSTOOL_DIR=/home/<useracct>/toolchain/<toolchain_version>
    • Make sure CODEGEN_INSTALL_DIR is defined as follows. (If you have installed it in a different location, ensure you set the correct path).
      CODEGEN_INSTALL_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_##
    • Note PSP_INSTALL_DIR donot need to be updated.They will be pointing to DVSDK installation directory.
    • Check the path of all component installation directories to match the location where you want to point to. The default locations specified will choose the component versions as installed as part of the DVSDK installation
  5. The top level DVSDK Makefile re-builds the kernel modules required by the DVSDK demonstration software (CMEM and LPM) and hence it is very important to at least perform the following commands (in case you have not performed the steps in Rebuilding the Linux Kernel), after extracting the Linux kernel source code in your work directory, whose path is provided in the top level DVSDK Rules.make. Refer section Rebuilding the Linux Kernel for more details on “Rebuilding the Linux Kernel”.
    host $ cd /home/<useracct>/workdir/opt/linux-##.##.##.##
    host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_defconfig
    host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
    
  6. Once the installation is complete please use the following commands to verify the paths set in Rules.make and components installed in DVSDK are proper.
    host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##
    host $ make check
    host $ make info
    
  7. While in the same directory that contains Rules.make, use the following commands to build the DVSDK demo applications and put the resulting binaries on the target file system specified by EXEC_DIR.
    host $ make clean
    host $ make all
    host $ make install
    
    • Note : The make all command builds only the DVSDK demos, its dependent components and DVTB
  8. Additional commands for cleaning and building all the components are as mentioned below.
    • Note : The PSP examples under AM35x-OMAP35x-PSP-SDK-##.##.##.##/src/examples have to be extracted before using below commands
    host $ make clobber
    host $ make everything
    
  9. For information on individually building the components please use the folowing command
    • Note:Certain components have dependency on other components.So please make sure you have executed the make all command before proceeding for individual component build.
    host $ make help
    

NOTE: The dependencies for indivdual component builds are not addressed in the top level DVSDK Makefile. If you perform 'make clobber' or 'make clean' and then try building indivdual components like 'make dmai', the build will fail. Alternatively, if you perform 'make clobber' and then perform 'make everything', the build will go through. In addition to that, if you try cleaning the individual component and then build the same again, the build will go through. For example, after performing 'make everything', performing 'make dmai_clean' followed by 'make dmai' will work.

Rebuilding the DSP side server executables

The DSP side codec libraries are available under /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_## directory or if you have installed it in a different location specified by CODEC_INSTALL_DIR

The top level Makefile and the config.bld files are provided under the top level directory mentioned above. The codec binaries, header files as well as documents are RTSC packaged and available under /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_##/packages/ti/sdo/codecs folder.

Ensure that the path settings for the DSP side code generation tools are set properly in the config.bld file

C64P.rootDir = /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_# OR 
C64P.rootDir=java.lang.System.getenv("CODEGEN_INSTALL_DIR"); 
cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_##
host $ make clean
host $ make 

The rebuilt server executable can be found in the /home/<useracct>/dvsdk/dvsdk_#_##_##_##/cs1omap3530_#_##_##/packages/ti/sdo/server/bin directory and is named cs.x64P.

The DSP side server executables can also be built from the DVSDK installation directory itself by following the below commands.

Ensure that DSP side code generation tools are set properly in the Rules.make in DVSDK installation directory

CODEGEN_INSTALL_DIR=/home/<useracct>/dvsdk/dvsdk_#_##_##_##/cg6x_#_#_##

Re-building the Servers from DVSDK installation directory can be done using the following commands.

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##
host $ make codecs_clean
host $ make codecs
host $ make install


Rebuilding the Initial NAND X-loader

Copy the X-Loader source archive from OMAP35x-PSP-SDK-##.##.##.##/src/boot-strap directory into your working directory

host $ cd ~
host $ mkdir –p workdir/opt
host $ cp x-loader-##.##.##.##.tar.gz ~/workdir/opt/.

Un-tar the X-Loader source archive by performing the following command.

host $ cd /home/<useracct>/workdir/opt
host $ tar -zxvf x-loader-##.##.##.##.tar.gz

Configure X-Loader for OMAP35x EVM target:

host $ cd xloader-##.##.##.##
host $ make omap3evm_config

To build X-Loader, run the command:

host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm

The above command produces the x-load.bin file, but in order for the X-Loader to be loaded by the OMAP35x ROM bootloader, it needs to be signed with the signGP program from the AM35x-OMAP35x-PSP-SDK-##.##.##.##/host-tools/linux directory.

host $ /home/<useracct>/AM35x-OMAP35x-PSP-SDK-#.##.##.##/host_tools/linux/signGP x-load.bin

The resulting signed X-loader is named x-load.bin.ift and should be ready for the target. For MMC/SD Card boot loading this file must be called MLO.

host $ cp x-load.bin.ift MLO


Rebuilding the Target-side UART Loader

Copy the UART loader dnld_util_target.tar.bz2 file from AM35x-OMAP35x-PSP-SDK-##.##.##.##/src/utils directory into your working directory.

host $ cd ~
host $ mkdir –p workdir/opt
host $ cp dnld-util-target.tar.bz2 ~/workdir/opt/.

Un-tar the UART loader by performing the following command.

host $ tar -jxvf dnld_util_target.tar.bz2
host $ cd dnld_util_target

Run the following command to build it.

host $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm

The resulting binary is called dnld_startup_omap3_evm.bin. This file is used with DownloadUtility.exe for UART peripheral boot.

Rebuilding the NFS Image

Kindly refer to the GSG:_AM35x_EVM_Software_Setup#Rebuilding_the_NFS_Image (part of AM35x Getting Started Guide),for rebuilding NFS for AM35x SDK. This will contain different set of demos and sample applications. The OMAP3535/OMAP3530 DVSDK installer has the script to (re)build the NFS image that includes the OMAP3525/OMAP3530 DVSDK demos under ~/dvsdk/dvsdk_#_##_##_##/targetfs folder.

In order to rebuild the NFS image with OMAP3530 DVSDK demos, make sure you have performed the steps in Section OMAP35x DVEVM Software Setup and Section Rebuilding the DVSDK Software for the target.

NOTE: Also ensure that you have copied the overlay_dvsdk_#_##_##_##.tar.gz file to your /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs folder.

The following command removes the old the NFS tarball image:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make clean_old_rootfs DVSDKVER=<your version number #_##_##_##>

The following command will create the NFS tarball image:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make omap3530_dvsdk_nfs DVSDKVER=<your version number #_##_##_##>

The following command will remove the NFS creation logs and the temporary NFS directory:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make clean_nfs DVSDKVER=<your version number #_##_##_##>

For any clarification about the procedure please perform the below command

host $ make –f targetfs_make help

Executing above command requires the users to have sudo access. The linux host would prompt for the user password and the user needs to enter his password for the make to continue. The user can make sure he has sudo access by including the following line in /etc/sudoers file.

<useracct>	ALL=(ALL)	ALL

Executing above commands will create the new NFS file system with the DVSDK demo executables and all the media files required by the demonstrations. You will see nfs_dvsdk_#_##_##_##.tar.gz created under the current folder (/home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs).

Rebuilding the Full Ramdisk Image

Refer to the GSG:_AM35x_EVM_Software_Setup#Rebuilding_the_Full_Ramdisk_Image (part of AM35x Getting Started Guide),for rebuilding full ramdisk image for AM35x SDK. This will contain different set of demos and sample applications.

The full ramdisk image cannot be built to include the OMAP3530 DVSDK demos as the ramdisk size requirement exceeds 40MB after the image is un-tarred and the bootargs given in step 5 in Section Running the Re-flash Procedure will not work

Rebuilding the Minimal Ramdisk Image

Refer to the GSG:_AM35x_EVM_Software_Setup (part of AM35x Getting Started Guide),for rebuilding minimal ramdisk image for AM35x SDK. The minimal ramdisk image does not contain any demos or examples.

Rebuilding the JFFS2 File-System Image

Refer to the GSG:_AM35x_EVM_Software_Setup#Rebuilding_the_JFFS2_File-System_Image (part of AM35x Getting Started Guide),for rebuilding jffs2 image for AM35x SDK. This will contain different set of demos and sample applications.

The OMAP3525/OMAP3530 DVSDK installer has the pre-built JFFS2 root file system image that includes the OMAP3525/OMAP3530 DVSDK demos under ~/dvsdk/dvsdk_#_##_##_##/targetfs folder.

Check if the linux distribution on the host PC contains the mkfs.jffs2 utility. If not, download the binary from ftp://sources.redhat.com/pub/jffs2/mkfs.jffs2. Place this binary under /sbin directory in the Linux host development PC and ensure to include /sbin to the PATH environment variable in the .bashrc file.

In order to rebuild the JFFS2 root file system image with OMAP3530 DVSDK demos, make sure you have performed the steps in Section OMAP35x DVEVM Software Setup and Section Rebuilding the DVSDK Software for the target. Then, perform the following steps.

NOTE: Also ensure that you have copied the overlay_dvsdk_#_##_##_##.tar.gz file to your /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs folder.

Clean the old file system images:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make clean_old_rootfs DVSDKVER=<your version number #_##_##_##>

Create the JFFS2 Image (This requires building the NFS image to create the JFFS2 image from):

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make omap3530_dvsdk_jffs2 MKJFFS2=<your_jffs2_install_path> DVSDKVER=<your version number #_##_##_##>

Clean up the temporary NFS file system directory:

host $ cd /home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs
host $ sudo make –f targetfs_make clean_nfs DVSDKVER=<your version number #_##_##_##>

For any clarification about the procedure please perform the below command

host $ make –f targetfs_make help

Executing above commands requires the users to have sudo access. The linux host would prompt for the user password and the user needs to enter his password for the make to continue.

The user can make sure he has sudo access by including the following line in /etc/sudoers file.

<useracct>	ALL=(ALL)	ALL

Executing above commands will create the new NFS and JFFS2 root file system with the DVSDK demo executables and all the media files required by the demonstrations. You will see nfs_dvsdk_#_##_##_##.tar.gz and rootfs_dvsdk_#_##_##_##.jffs2 files created under the current folder (/home/<useracct>/dvsdk/dvsdk_#_##_##_##/targetfs).

What's next?

The next chapter of this Getting Started Guide is GSG: OMAP35x DVEVM Additional Procedures.