RidgeRun Turrialba SDK User Guide

From RidgeRun Developer Connection

(Difference between revisions)
Jump to:navigation, search
(DVSDK 4 or EZSDK Installation)
(2 intermediate revisions not shown)
Line 84: Line 84:
=== Supported Linux Distributions ===
=== Supported Linux Distributions ===
-
RidgeRun SDK have been developed and tested on Ubuntu, and requires at minimum Ubuntu 9.04; however is strongly recommended to use the latest stable version of Ubuntu. Other Linux distribution may be used if they provide glibc 2.4 or up, but have non been tested and the SDK host tool checking will need to be bypassed or extented.
+
RidgeRun SDK have been developed and tested on Ubuntu, and requires at minimum Ubuntu 12.04; however is strongly recommended to use the latest stable version of Ubuntu. Other Linux distribution may be used if they provide glibc 2.4 or up, but have non been tested and the SDK host tool checking will need to be bypassed or extented.
Ubuntu is a well supported and easy to use Linux distribution with commercial support. You can get pre-installed and enterprise supported Ubuntu desktops for your company.
Ubuntu is a well supported and easy to use Linux distribution with commercial support. You can get pre-installed and enterprise supported Ubuntu desktops for your company.
Line 110: Line 110:
|-
|-
| DM36x || [[Code Sourcery ARM toolchain 2009q1-203]]
| DM36x || [[Code Sourcery ARM toolchain 2009q1-203]]
-
|-
 
-
| OMAP3 || [[Code Sourcery ARM toolchain 2009q1-203]]
 
-
|-
 
-
| OMAP-L138 || [[Code Sourcery ARM toolchain 2009q1-203]]
 
|-
|-
| DM3730 || [[Code Sourcery ARM toolchain 2009q1-203]]
| DM3730 || [[Code Sourcery ARM toolchain 2009q1-203]]
Line 132: Line 128:
|-
|-
| DM368 || [http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/4_02_00_06/exports/dvsdk_dm368-evm_4_02_00_06_setuplinux  dvsdk_dm368-evm_4_02_00_06_setuplinux]
| DM368 || [http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/4_02_00_06/exports/dvsdk_dm368-evm_4_02_00_06_setuplinux  dvsdk_dm368-evm_4_02_00_06_setuplinux]
-
|-
 
-
| OMAP3 || [http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/4_01_00_09/index_FDS.html dvsdk_omap3530-evm_4_01_00_09_setuplinux]
 
-
|-
 
-
| OMAP-L138 ||
 
|-
|-
| DM3730 ||  
| DM3730 ||  

Revision as of 17:29, 6 February 2013

(PAGE UNDER CONSTRUCTION)

Contents

Read First

There are different versions of the RidgeRun's SDK depending on the target processor you plan to use. The information in this document is general and is completely agnostic of the type of hardware or SDK configuration that the customer is using. For more specific information refer to the specific SDK documentation for your target hardware.

SDK Overview

Characteristics

The RidgeRun Linux Turrialba SDK, features:

Features

Relevant features of the SDK are:

Basic Structure

The SDK is implemented as a collection of directories that allows the integration of all the functional parts (file system, kernel, bootloader, user applications), the basic structure of the SDK is shown in the following image, they are shown only the most relevant directories since the SDK is compound of a much more complex structure:

SDK's basic structure.

The following is a brief description of the purpose of each directory displayed in the image.

This directory contains all the files related to the boot software such as u-boot, x-loader and so on.

On this directory is stored all the files related with the SDK's configuration and architecture and machine files. Into this folder it can be found the arch and mach directories on whose are stored specific files and patches for each architecture (i.e. dm365) and each machine (i.e. leopardboard).

This folder contains the SDK's documentation for the user.

The SDK needs a set of basic packages such as kernel and bootloader and some other extra packages which depends of the user's configuration such as bash, glib, ipiped and so on. Those packages are downloaded and stored on the downloads directory so it will avoid you to download again any package when you run a make clean command on some applications, it will just look into this directory for the required package.

If you install the SDK into more than one development directory (a very common practice), then you can avoid downloading packages by making a global directory to hold the downloads. The following steps will create and configure the global download directory:

sudo mkdir -p /opt/ridgerun/downloads
sudo chmod ugo+rwx /opt/ridgerun/downloads

This directory contains the entire file systems and the SDK's applications, you can find three main folders on this directory:

This directory will store all the generated images that will be flashed on the board with the make install command. If you are using a NAND type file system such as JFFS2 or UBIFS you will find the file system image here, the same way you will find images for SD card when you are using this deployment mode.

On this folder are stored some tools used for the installer mechanism of the SDK.

This directory stores the kernel source code used for the SDK.

On this folder you will be able to find some example applications and it is targeted to be the built folder for the user's application, this way the example applications included on this folder also work as reference point to the user to create its own application and integrate it with the SDK.

All the proprietary applications used by the SDK are stored on this folder, the main application you will find on this directory is the DVSDK/EZSDK package provided by TI.

This directory contains some files needed to configure the toolchain.

Supported Linux Distributions

RidgeRun SDK have been developed and tested on Ubuntu, and requires at minimum Ubuntu 12.04; however is strongly recommended to use the latest stable version of Ubuntu. Other Linux distribution may be used if they provide glibc 2.4 or up, but have non been tested and the SDK host tool checking will need to be bypassed or extented.

Ubuntu is a well supported and easy to use Linux distribution with commercial support. You can get pre-installed and enterprise supported Ubuntu desktops for your company.

The SDK can be used over a virtual machine, but it is not recommended due to performance concerns. RidgeRun SDK is a source code “build from scratch” system, and the build process is I/O intensive. Virtual machines technologies perform better on CPU intensive applications, but not I/O intensive ones, unless you use a optimized hardware configuration. In addition, the SDK installer uses the serial port, which has been known to drop data when used with a VM.

Please contact RidgeRun support for more information or if you require support for other distributions.

Installation

Getting the RidgeRun's EVAL SDK Turrialba

If you want to get the RidgeRun's EVAL SDK Turrialba you need to go to our (Download link) page and select the SDK you need. You will be asked for your email address and some information. Once you have submitted the required information you will receive an email with the following information:

CodeSourcery Toolchain Installation

New SDK Turrialba uses the Codesourcery toolchain for cross compilation. You need to download and install the toolchain before you can build the SDK. Below are shown the toolchains need for each supported platform.

Processor Toolchain Installation Instructions
DM36x Code Sourcery ARM toolchain 2009q1-203
DM3730 Code Sourcery ARM toolchain 2009q1-203
DM8168 Code Sourcery ARM toolchain 2009q1-203

In order to download and install the CodeSourcery's toolchain for the SDK Turrialba please see Code Sourcery ARM toolchain 2009q1-203.

DVSDK 4 or EZSDK Installation

In addition to the toolchain, it is necessary to install the TI's Digital Video Software Development Kit (DVSDK) package before installing the SDK. RidgeRun doesn't have the rights to re-distribute TI's DVSDK/EZSDK packages so you have to fetch and install them yourself. There is a general TI web page listing the latest version of each DVSDK / EZSDK. You need to use the exact version required by the RidgeRun SDK or the patch files will not apply cleanly.

Processor DVSDK/EZSDK version
DM365 dvsdk_dm365-evm_4_02_00_06_setuplinux
DM368 dvsdk_dm368-evm_4_02_00_06_setuplinux
DM3730
DM8168 ezsdk_dm816x-evm_5_02_01_59_setuplinux

The download and installation instructions are detailed below (the example shown is for the DVSDK 4 for DM365):

1. The dvsdk_dm365-evm_4_02_00_06_setuplinux binary file can be downloaded from TI's site.

2. Install it by executing the binary file with the following commands:

sudo chmod a+x dvsdk_dm365-evm_4_02_00_06_setuplinux
./dvsdk_dm365-evm_4_02_00_06_setuplinux

3. You will be asked for the Toolchain's path, you need to specify the path to the binaries' directory of the toolchain as is shown in the following image:

Figure 1. DVSDK 4 Toolchain check window.

4. Install the DVSDK with the default configuration.

Host Configuration

Usually the SDK will ask you to install any missing package it requires that is not installed on your host machine. You can install them using the following command:

sudo apt-get install package_name

The following is the list of the required packages by the SDK:

It is possible you need to install some additional packages when some features require them, the SDK will ask you for this packages in the form of a error message as is shown below:

Checking for host packages required by the SDK build system:
    buildsystem (build-essential) is installed
    make (make) is installed
    ncurses (libncurses5-dev) is installed
    texinfo (texinfo) is installed
 >> minicom (minicom) is NOT installed
    perl (perl) is installed
    quilt (quilt) is installed
    dc (dc) is installed
    subversion (subversion) is installed
    curl (curl) is installed
    git (git-core) is installed
    autoconf (autoconf) is installed
    crypt-ssleay (libcrypt-ssleay-perl) is installed
    quilt (quilt) is installed
    libusb (libusb-dev) is installed
    perl-expect (libexpect-perl) is installed
    mono (mono-devel) is installed
There are missing packages, please install them:
 apt-get install minicom
make: *** [.oscheck] Error 1


In addition, you need to configure your host sudo, TFTP, and NFS services:

Installing the SDK

RidgeRun delivers the SDK in either two ways: a binary installer for x86 platforms, or for customers with a established development relationship through a custom SCM (typically svn) repository. This instructions details the installation procedure for the binary installer. If you are using a shared SCM repository, please contact RidgeRun for detailed instructions.

System Requirements

Listed below are the minimum recommended requirements for installing and using the RidgeRun SDK:

Installation

The RidgeRun SDK is delivered as binary self installer.

RidgeRun toolchains must be installed on /opt and therefore you need either to install the toolchain as root, or to have write permissions over /opt for your normal user. If you decide to assign your user permissions over /opt:

$ sudo chown $USER /opt

It is recommended to install the SDK as normal user (without using sudo). When installing the SDK as normal user, the default installation target for the SDK is /home/$USER/<name and version of your SDK>.

So, after you get the binary file for the SDK proceed to execute the installer:

$ ./DMXXXSDK-12345-Linux-x86-Install.bin

If you are running from a graphical UI it will show the graphical installer, where you can follow the instructions to install the SDK. Otherwise it will use the console installation method.


The other option is to install the SDK as superuser. If you decide to install as superuser it is recommended to change the owner ship of the SDK directory to your normal user after the installation, since working as root is not recommended, and the SDK has support for handling root-required operations with sudo. When installing as superuser the default installation target for the SDK is /opt/<name and version of your SDK>.

If you want to change the ownership of your SDK development directory after installing the SDK you can execute:

$ sudo chown $USER -R /opt/DMXXXSDK12345


Below are shown the steps to install the SDK from the UI mode (the example shown is for a SDK Turrialba for LeopardBoard DM365 but it is almost the same for the rest of platforms):

1. Give execution permissions to the file:

sudo chmod a+x LeopardBoardDM365sdk-Turrialba-Linux-x86-Install.bin
./LeopardBoardDM365sdk-Turrialba-Linux-x86-Install.bin

2. Click Yes in the start up window.

[[File:|400px|thumb|center| Figure 2. Installer's start up window.]]

3. Click Next in the main window.

[[File:|400px|thumb|center| Figure 3. Installer's main window.]]

4. Accept the license terms in order to use the EVAL SDK and click Next to continue.

[[File:|400px|thumb|center| Figure 4. Installer's License Agreement window.]]

5. Choose the destination directory to where the EVAL SDK will be installed. Note: The installation directory must be a folder that doesn't exist since the installer will create it in the process.

[[File:|400px|thumb|center| Figure 5. Installer's destination directory window.]]

6. Once you have selected the installation directory a confirmation window will be displayed. Click Next to start the installation or Back to change any data. Note: Be sure to have an Internet connection before click Next since the installer needs to download some packages

[[File:|400px|thumb|center| Figure 6. Installer's confirmation window.]]

7. Wait while the EVAL SDK is installed in your computer.

[[File:|400px|thumb|center| Figure 7. Installer's installation progress window.]]

8. Once the EVAL SDK has been successfully installed the next window will be displayed. Click Finish to close the installer and start using the EVAL SDK.

[[File:|400px|thumb|center| Figure 8. Installer's installation complete window.]]

You can have more than one development directory installed, just remember to have the DEVDIR shell variable set properly.

Build SDK

Several packages are needed in order to compile the SDK. The SDK build process will let you know what packages are needed. While compiling you will be prompted to install them using sudo apt-get install <packages>.

You can get a description of all the available commands for the SDK by running the following command into your SDK's installation directory:

make help

It will show a list as the shown bellow:

RidgeRun Integrated Linux Software Developer's Kit

Make targets:

   build           - build kernel, target fs, bootloader
   kernel          - build kernel
   fs              - build target filesystem
   cmdline         - build cmdline for target kernel (fs target does the same as well)
   bootloader      - build bootloader
   config          - allow SDK to be configured
   config_batch    - attempt to configure without user interaction
   clean           - delete all derived files
   update          - Checks for repository updates for the SDK
   show_updates    - Checks for available updates for the SDK's release; use revision=<number> to specify a particular revision or range (same syntax as svn log) or showdirs=1 to enable showing change details in the log displayed.
   env             - Displays commands to run to setup shell environment
   coreconfig      - Select toolchain, bootloader, and kernel (updates bsp/mach/Make.conf)
   doc             - Generate the SDK API documentation into the documentation folder
   prelink         - prelink the root filesystem
   install         - Install all out of date images to target
   installbootloader - Install bootloader to target
   installmtd      - Install uBoot MTD partition table
   installkernel   - Install kernel to target
   installfs       - Install file system to target
   installcmdline  - Install uBoot kernel command line
   installbootcmd  - Install uBoot boot command
   svnup           - recursively run the 'svn up' command.

Make parameters:

   VERBOSE         - set to 1 to output executing commands
   LOGFILE         - set to built output filename

Make update parameters:

   FORCE_UP        - set to force the application/removal of patches
   DEBUG_UP        - set to output the executing commands

 U-boot Installer Parameters ($DEVDIR/installer/u-boot-installer)
   PORT            - Host serial port to use for install
   HOST_IP         - Host IP address to use for TFTP install
   FORMAT          - Set to 1 to force SD card to be formatted
   FORCEINSTALL    - Set to yes to force performing the requested install target
   ERASECHIP       - Set to yes if you want to scrub the FLASH chip during bootloader installation

Examples:

   make                   # same as 'make build'
   make VERBOSE=1
   make installbootloader PORT=/dev/ttyUSB1

Configure the features you want to have in your board using (instructions shown below):

make config

Set the PATH to include the toolchain and aslo set the DEVDIR shell variable

$(make env) # this is the same as using grave accents to execute the output from the command - `make env`

Compile the SDK:

make

Install bootloader, kernel, and target file system on LeopardBoard 365

Verify bootloader is active

First a minicom (or any other terminal emulator used) session must be opened in order to stop the booting process at the bootloader prompt:

minicom

Reboot the board and stop the autoboot when

Hit any key to stop autoboot: ...

is displayed. Then close your minicom session. Be sure to use the Ctrl-A,Q method, not Ctrl-A,X (Exiting with Q doesn't inject extra modem characters into the terminal session)

Save bootloader to target hardware

The next step is to install the bootloader on the target. Typically you only install the SDK bootloader once.

make installbootloader

Update target hardware with new images

Power cycle your target hardware, and install uboot environment / kernel / FS on the target (per your SDK configuration choices):

make install

Similar to the bootloader installation, to install the devdir on the target the booting process should be stopped at the bootloader prompt.

Updating your SDK

Since the SDK is in a SVN respository RidgeRun can periodically make updates to the contents. To have an up-to-date SDK the following command must be executed on the SDK root directory

make update

If, for any reason, modifications to any files that are included in a patch were made, the make update process won't be able to finish successfully. In order to override this the following command must be executed

make update FORCE_UP=1

Note that all changes previously made to these files will be lost.

Also, a debug functionality is implemented where all the executed commands will be displayed on the standard error (usually the same as standard output). To activate it use

make update DEBUG_UP=1

Of course, a combination of both options can be used

make update FORCE_UP=1 DEBUG_UP=1

A brief help menu explaining these features can be displayed using

make help

A list of all current updates available is shown when running the following command

make show_updates

SDK Components

This SDK has several main components that will be explained in the following sections, they are: bootloader, file-system, kernel and toolchain. There are other non standard components that depends on the specific client configuration, check the specific documentation for such components.

Bootloader

The bootloader allows the loading, storing, and invoking of a Linux kernel and root file system. In normal operation, the bootloader resides in the boot storage device (NOR flash, NAND disks, etc) at the reset vector. It is the first program run on power up and, unless something else is specified, the bootloader will typically transfer control to the stored Linux kernel and file system.

Currently the RidgeRun SDK's support U-Boot bootloader. Information is available at http://sourceforge.net/projects/u-boot and in the SDK directory $DEVDIR/bootloader/u-boot-*/src/doc.

The user interface communicates over the board's serial line with a host terminal session such as minicom on Linux, or TeraTerm on Windows. Do not use HyperTerm since it does not support a 8 bit binary transfer mode. Using HyperTerm will cause the images being downloaded to be corrupted.

Target File-System

The target file system holds the master file system structure used to create the target file system. This includes all the files, drivers, nodes and others entries, that will be mounted in the target board when Linux finishes to boot up.

Kernel

The Linux kernel supplied with your SDK is pre-configured and ready for use. If your project requires components that are not contained in the default RidgeRun kernel, you may want to change the kernel configuration.

Toolchain

Holds the tools and utilities used to build applications and other code for the target hardware, in other words, supports cross compilation, which is the process of compiling on your host machine executables for a different target processor.

Using the SDK

The SDK is pre-configured so that it can be installed, compiled and tested out from the box. The SDK is pre-configured with a default configuration which may not include all that is needed during future development steps for your target hardware. In the following sections we will describe the necessary steps to modify and re-configure the SDK.

Root Password Entry

During the SDK's installation process and building the target file system, you will be asked for the root password several times. Root privileges are necessary at certain points in the configuration of the target file system image (creation of devices, setting of file ownership, etc.). The build process provides an alternative to reduce the number of times you have to enter passwords. If you define the following environment variable in your shell startup script (e.g. .bashrc):

export SU=sudo

Then you will be asked for a password only once. For Ubuntu the password that you provide is your personal password, not the root password.

In order for the sudo command to work correctly, you must have an entry for your user ID in /etc/sudoers. You need to edit this file as the root user. Also, you can add a default timestamp entry to disable sudo from periodically asking for your user password. The following two lines can be added to the /etc/sudoers file to reduce the number of times you have to enter passwords.

Defaults:	<user ID> timestamp_timeout=-1
	       	<user ID> ALL=(ALL) ALL

More information about sudo can be found at http://www.courtesan.com/sudo/

How to configure the SDK

In the root directory where the SDK is installed run the make target “config”. For example:

$ make config
  Ridgerun Linux SDK
  DM320 TI SoC EVM Board configuration

  Processing toolchain...
  Processing kernel...
  Processing fs...
    Entering arch...
    Entering mach...
    Entering apps...
  Processing bootloader...
#

Then a menu like the one in Figure 9 will show up:

Fig.9: SDK Configuration

From this main menu it is possible to configure SDK components like: architecture specific memory addresses, toolchain path and flags, bootloader specific memory addresses, the kernel configuration, the file system type and the applications that will be added to the target file system.

The help option of every menu is useful to understand the different options of the SDK components. The detailed SDK configuration documentation can be found there.

Once the SDK configuration is finished save it and compile the SDK.

Note: Before performing any installation in the board make sure that the installer is properly configured (see How to use the installer system)

How to compile the SDK

In the SDK each component can be compiled separately or the whole SDK can be compiled in one command. For example to make everything:

$ make
  Ridgerun Linux SDK
  DM320 TI SoC EVM Board configuration

  Processing toolchain...
    Build complete
  Processing kernel...
  CHK     include/linux/version.h
  SPLIT   include/linux/autoconf.h -> include/config/*
  SYMLINK include/asm-arm/arch -> include/asm-arm/arch-dm320
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  Building modules, stage 2.
    Build complete
  Processing fs...
    Entering arch...
      Entering base...
    Entering mach...
    Entering apps...
      Entering busybox-1.1.2...
     Entering dosfstools-2.11...
    Entering arch/targets...
      Entering initrd...
    Entering mach/targets...
    Build complete
  Processing bootloader...
      Building images for bootloader
    Build complete

or you can compile each component separately:

$ make kernel
  Processing kernel...
  CHK     include/linux/version.h
  SPLIT   include/linux/autoconf.h -> include/config/*
  SYMLINK include/asm-arm/arch -> include/asm-arm/arch-dm320
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
  Building modules, stage 2.
    Build complete
$ make fs
  Processing fs...
    Entering arch...
     Entering base...
    Entering mach...
    Entering apps...
      Entering busybox-1.1.2...
      Entering dosfstools-2.11...
    Entering arch/targets...
      Entering initrd...
    Entering mach/targets...
    Build complete
$ make bootloader
  Processing bootloader...
      Building images for bootloader
    Build complete

There are some options that can be passed to the make command:

$ make VERBOSE=1
Ridgerun Linux SDK
  DM320 TI SoC EVM Board configuration

if [ -d toolchain ] ; then echo -e "\040" "Processing toolchain..."; export PATH="/opt/RidgeRun/dm320/linux-2.6/crossdev"/bin:$PATH ; make -C toolchain  DEVDIR=/home/trivas/cdx-devdir -demo TABINDEX="\040\040\040"; fi
   Processing toolchain...
make[1]: Entering directory `/home/trivas/cdx-devdir-demo/toolchain'
make  -C uclibc build
make[2]: Entering directory `/home/trivas/cdx-devdir-demo/toolchain/uclibc'
make[2]: Nothing to be done for `build'.
make[2]: Leaving directory `/home/trivas/cdx-devdir-demo/toolchain/uclibc'
echo -e "\040\040\040" "Build complete"
    Build complete
make[1]: Leaving directory `/home/trivas/cdx-devdir-demo/toolchain'
$ make LOGFILE=/home/trivas/temp/logfile
  Ridgerun Linux SDK
....
    Build complete
$ cat /home/trivas/temp/logfile
<log file contents>

How to compile an arbitrary directory inside the SDK

The SDK build system uses several system variables that are set-up by the main Makefile in order to build the different components, and find the toolchain components. Therefore if you attempt to compile a single directory inside the SDK structure, it will fail.

A workaround for such limitation is possible and requires two steps:

$ export DEVDIR=/path/to/devdir
$ export PATH=/path/to/toolchain/binaries:$PATH

However the SDK offers a simplified method to set the DEVDIR and PATH values:

 `make env` or $(make env)

After you perform these steps you can go inside any particular directory of the SDK and execute the makefiles contained within them. Be aware that you should recompile the file system images or any other component in order to update your target.

This feature allows you to build a single application instead of build all the parent directory, for example you can clean and rebuild the bash application on $DEVDIR/fs/apps/bash instead of rebuild all the file system. Even more, this feature is extremely useful when using NFS file system since you can modify an application and install it directly to the file system on $DEVDIR/fs/fs and immediately you will be able to test it on your board.

Other SDK Make targets

From within the root of the development directory (devdir)'s root, and through the Makefile file that's been mentioned, many commands and utilities some of which have already been discussed above can be used. The following is a list of these, commented with their respective functionality and usage. Note that at any time a similar guide can be displayed by using the "Make help" command, present within that same file in the devdir's root directory.

Make targets

Make parameters

Make update parameters

U-boot Installer Parameters ($DEVDIR/installer/u-boot-installer)

How to add my application to the SDK

This is a quick reference for introduction on how to build applications with the SDK, for more detailed instructions please refer to the Development and Integration Guide found in the documents of the SDK.

Under your SDK development directory is a directory named myapps. This directory allows customers to locate their own applications to be run on the target hardware. Inside this directory is a Makefile with logic to detect new applications and add them to the SDK build procedure.

A example hello application can be found on the myapps directory and can be use as reference for creating new customer application.

Step 1: Creating the application directory

Go into myapps directory and create a new directory for your application:

$ cd $DEVDIR/myapps
$ mkdir NewApp
$ cd NewApp
Step 2: Create the build system files

Create a file named “Config”. This file will contains logic to select if your application should be build within the SDK. A simple example file is:

config USER_APPS_NEWAPP
	bool “NewApp Customer Application”
	default y
	help
		Build my NewApp program

For further information about the syntax of this file check $DEVDIR/bsp/bspc/kconfig-language.txt

HINT: Look at other Config files in the SDK to find one that is similar to your needs and use it as your starting point.

Once the file is created you can run the “config” target (make config) on your system to enable the build of the new application. A screen will appear as follow (in the SDK configuration window go to User applications):

Fig.10: Adding a new application

Then create a file named Makefile. This is a standard Makefile file to build your application, however it requires certain rules to be integrated with the SDK build system.

HINT: a template Makefile should look like this:

#
# myapps/NewApp/Makefile
#
.PHONY: build chkconfig preconfig buildfs install clean
ifeq ($(DEVDIR),)
$(error ====== DEVDIR variable is empty, invoke this Makefile from the SDK root, or provide the path to it =====)
endif
include $(DEVDIR)/bsp/mach/Make.conf

build:
	<build commands for your app>

install: 
	<install commands for your app>

clean: 
	<clean command for your app>

# Empty but required targets
chkconfig:
preconfig:
buildfs:

The rules for the SDK Makefile are:


In order to compile the files with the proper cross-compiler you can use the follow environment variables (imported from the Make.conf file):

HINT: You can see how to use the variables by looking at the hello example Makefile.

How to update the SDK with the latest patches from RidgeRun

NOTE: If you are a customer using a custom SCM repository shared with RidgeRun, this instructions aren't valid, since updates are delivered directly into the shared SCM.

RidgeRun SDK includes a feature to update your SDK with the latest patches provided by support engineers. This feature requires Internet connectivity.

In order to update your SDK to the latest patches, perform the follow commands:

$ cd $DEVDIR
$ make update

You will be asked for an username and password to access RidgeRun support servers. Contact RidgeRun support to get this information.

A brief report of actions will be displayed:

$ make update
RidgeRun SDK update tool
This program will check against RidgeRun update servers to find and apply
updates for your SDK. Please provide the customer user name and password
provided by RidgeRun support services in order to access the updates.
 
Username: ridgerun
Password: 
 
Getting patch list... done

RidgeRun SDK update complete, your SDK is up-to date with Patch 002

$

How to use the installer system

The SDK Turrialba has a huge variety of options for installation methods that allows the user to get a flexible way to control the images handling. You can explore such options into the Installer Configuration and File System Configuration sections into the configuration window.

Bootloader and Kernel installation

The installer system allows to install the system images (bootloader and kernel) to NAND or use them from a SD card. A brief explanation of each method available will be shown below.

1.Booting from NAND

In order to get the bootloader and kernel images flashed into the NAND memory it is necessary to select the Attached board on communication port option in the Installer Configuration window as is shown in the following image.

Fig 11. Selecting attached board installation method.

When the option is selected two new sub-sections will be created: Installer to U-boot communication options and Transfer options for installation. This sections ask for the necessary information to transmit the images and data from the host computer to the target.

In this section you will be asked for the necessary information for communicating with the board. The first parameter you need to enter is the Communication method with the target board. There are two communication methods available: Serial port and Telnet-serial adaptor. In the case of serial port you need to specify the serial port device name and with telnet-serial adapter you will be asked for the IP address of the host machine and the communication port associated.

In the Transfer options for installation section you will be asked for the protocol to be used for the transmission of the images to the target and the location of the images (kernel and bootloader).

Once you have selected the option you can rebuild your SDK with the make command and install the new firmware running the make env command and then it will install the bootloader and kernel images to the NAND using the communication method provided.

2. Booting from an SD card

The installer allows to boot with the bootloader and kernel images stored into a SD card, to activate this option it is necessary to select the Deploy all the firmware to an SD card option of Firmware deployment mode tag in the Installer Configuration window as is shown in the following image.

Fig 12. Selecting SD card installation method.

Once you have selected the option you can install the images and create a bootable SD card following the steps described in How to boot a board from a SD card.

File system installation

The installer allows to install the file system using different methods. You can find the available methods in the File system image target option in the File system Configuration section. The available file system types will be displayed as is shown in the following figure.

Fig 13. Selecting the file system type.

The following is a brief description of the available file systems.

1. Initramfs filesystem

This file system type allows to create a whole image containing the kernel and file system images.

2. JFFS2 disk image

JFFS2 (Journalling Flash File System version 2) allows to install the file system into NAND and run it without the need of an SD Card or network connection. When using JFFS2 file system two new options will be displayed: Do not include the cleanmarker block and Change JFFS2 endianness. The first one will ommit the cleanmarker in the blocks so they won't be erased, this option must be used for NAND memory devices. The second option will change the endianness of the data generated which by default is set to the endianness of the host machine on which the image is cerated (little endian for x86-based systems).

3. NFS root file system

NFS or Network File System allows to load the file system through an existent network, so the system files will be stored in a remote system and the target will be able to read, modify or notice any change on it. When using this option the target must have connection to the same network in which the host machine is located so it can access the file system stored on it.

4. Secure Digital Card

This installation method allows to create a SD card image with the file system data, then when the target starts, it will look for the file system in its SD card slot.

5. UBIFS volume

UBIFS is a successor of JFFS2 and in many aspects better than it tending to perform better than JFFS2 for large NAND FLASH devices becoming faster than JFFS2. When selected, a new option called UBIFS sub-page size will be displayed. To reduce the file system flash usage, use smaller sub page sizes to store UBI system data. [Note: UBIFS is only available in the Professional version of the SDK]

Appendixes

Appendix I: Setting up Ubuntu for use with RidgeRun SDK

Ubuntu Linux is a popular Linux Distribution based on Debian Linux. It's available for different platforms and provides a easy-setup development environment. For more information please visit http://www.ubuntu.com/.

The SDK is developed and tested against Ubuntu. This section describes the required steps to install and setup the required software environment for use of the SDK in Ubuntu, but may be useful if you want to use the SDK in another Linux distribution.

Installing Ubuntu

In order to install Ubuntu you need to get a installer CD from the project page. The specific steps to install it can be found on the CD documentation.

Required development packages

Ubuntu default installation is suited for an end-user desktop machine, so it might lack some development packages required to become a workstation. In order to install those packages you require a high-speed internet connection and use of the apt-get program.

The first step consists on upgrading all the current software. Perform the follow steps:

$ sudo apt-get update
$ sudo apt-get upgrade

Now you just need to build the SDK; the first step of this process is to check your host system and your workstation packages, you may see something like this:

$ make
The system is ubuntu-7.10 running in a 32 bit architecture 
SYSID: ubuntu-7.10_32 
Checking for host packages required by the SDK build system: 
    buildsystem (build-essential) is installed 
    libtool (libtool) is installed 
    make (make) is installed 
    mtd-tools (mtd-tools) is installed 
    ncurses (libncurses5-dev) is installed 
    texinfo (texinfo) is installed 
    tftpd (tftpd) is installed 
    minicom (minicom) is installed 

  Ridgerun Linux SDK 
  DM355 Texas Instruments EVM Board 
 
  Processing toolchain... 
    Build complete 
  Processing kernel... 
  CHK     include/linux/version.h 

...

If your host system is not one of the supported systems, the first part of this check will fail and show you a message similar to the following:

ERROR: your host system is not oficially supported by RidgeRun SDK
please contact RidgeRun support if you need support for this distribution
NOTE: your system may still work for building this SDK, is just not tested

If you are working with a supported system such as Ubuntu the packages verification process will start to check all the needed and recommended packages as follow:

...
The system is ubuntu-7.10 running in a 32 bit architecture 
SYSID: ubuntu-7.10_32 
Checking for host packages required by the SDK build system: 
    buildsystem (build-essential) is installed 

If there is any kind of problem during the verification process, the next part of the process will tell you which packages are missing, and also will alert you if the missing package is vital for building up the SDK, or if it is a highly recommended package. For example an error will look something like this:

The system is ubuntu-7.10 running in a 32 bit architecture 
SYSID: ubuntu-7.10_32 
Checking for host packages required by the SDK build system: 
 >> buildsystem (build-essential) is NOT installed 
    ...
There are missing packages, please install them: 
  build-essential 
make: *** [.oscheck] Error 1 

To install the missing packages use the the apt-get program (for more information about apt-get do: man apt-get). For example:

sudo apt-get install build-essential

If there is some kind of warnings you will be alerted and you could chose to stop your building process in order to correct the warning or continue the installation. NOTE: if there is only warnings the message will be displayed just one time, the next time you won't be notified.

Useful Ubuntu Links

Navigation
Toolbox