RidgeRun SDK Overview

From RidgeRun Developer Connection
Jump to: navigation, search

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 2011.Q2 SDK, features:

  • Linux Kernel 2.6.x / 3.x (specific kernel depends on the platform).
  • ARM GCC based toolchain (specific version depends on the platform).
  • Bootloader (specific version depends on the platform).
  • Integrated build and configuration system.
  • Deploy utilities to automated deployment of firmware during development cycle (RidgeRun SDK installer).
  • Integration with Yocto packages (available for some specific platforms).

Features

Relevant features of the SDK are:

  • Full integration of the whole SDK configuration under one main menu. This allows the access to all the configuration menus for toolchain, bootloader, file-system and others from a centralized point.
  • Transparently management of architecture dependencies. In order to made changes as target hardware, toolchain or bootloader configurations, just choose the correct configuration of your in the SDK main menu and all the necessary dependencies will be handled by the SDK.
  • Easy integration of new user applications.


Main 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/uboot 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.

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.



Basic SDK Layout

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 structure.png

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

  • bootloader

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

  • bsp

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

  • documentation

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

  • downloads

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 my 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
  • fs

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

    • fs: This directory is created when you built your SDK and stores the entire file system that is used by your board, if you are using NFS file system type you can access the board's file system by just accessing this directory.
    • apps: This directory stores all the available architecture independent applications for the SDK such as ipiped, bash, glib, alsa-utils and much more.
    • host-apps: This directory includes some applications required for the host machine and that have been configured for the SDK, for example this directory usually includes the VALA API against with some applications stored on the apps directory will be built.
  • images

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.

  • installer

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

  • kernel

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

  • myapps

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.

  • proprietary

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.

  • toolchain

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 9.04; however is strongly recommended to use the latest stable version of Ubuntu (12.04 at the moment). 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.


System Requirements

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

A host computer with a 686 or better family processor
1 GB free hard disk space
A Linux distribution configured on the host computer. For instructions for setting up on Ubuntu Linux please refers to Appendix I.
Target hardware for the SDK
Optional: a network card installed and configured on the host computer
Optional: Internet connection for SDK updates


RidgeRun SDK (HOST MACHINE REQUIREMENTS)

Downloading RidgeRun SDK

In order to have access to RidgeRun's SDK Pro version, please submit your inquiry using the following link:

RidgeRun's contact page

An Evaluation SDK version is also available through our download center:

RidgeRun's download center


NOTE: Please make sure you go through the Linux Host Setup section commands before trying to download the SDK.


Linux Host Setup

  • Install GIT and Subversion versioning tools.
sudo apt-get install git
sudo apt-get install subversion


  • Install the corresponding toolchain for your board


Processor Toolchain Installation Instructions
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
DM8168 Code Sourcery ARM toolchain 2009q1-203
Zynq 7000
Refer to Zynq 7000 ZedBoard Getting Started Guide









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


  • Configure additional services required by the RidgeRun SDK (TFTP and NFS)

TFTP configuration for fast image downloads to the target hardware

NFS configuration so the root file system used by the target can be located on the host


  • In case termnet is preferred over minicom as serial console / terminal app, please refer to the short guide below

TERMNET terminal app configuration, alternative to minicom


  • Additionally, it might be the case that it is necessary to install some proprietary tools according to the platform, among others:

- Texas Instruments Digital Video SDK (DVSDK) for Davinci DM644x, DM36x and DM373x processors.

- Texas Instruments Linux EZ SDK (EZSDK) for Davinci DM816x and DM814x processors.

- Xilinx Vivado and ISE Design environment for Zynq 7000 processor.


RidgeRun SDK (CONFIGURATION /  BUILDING / INSTALLATION)

First time configure / build

If this is the first time using RidgeRun's SDK, it will be likely the case that there are some missing packages in your host machine that are required in order to build the SDK. During the early build stages of the SDK, it will check for missing packages and suggest a apt-get  install like command to get those dependencies installed on your machine:

$(DEVDIR)$ make config
The system is ubuntu-12.04 running in a 64 bit architecture
SYSID: ubuntu-12.04_64
Checking for host packages required by the SDK build system:
 >> curl (curl) is NOT installed
    buildsystem (build-essential) is installed
    Checking dependencies for libtool-2.2.8
    make (make) is installed
 >> ncurses (libncurses5-dev) is NOT installed
 >> texinfo (texinfo) is NOT installed
 >> minicom (minicom) is NOT installed
    perl (perl) is installed
 >> quilt (quilt) is NOT installed
    dc (dc) is installed
    subversion (subversion) is installed
 >> git (git-core) is NOT installed
    Checking dependencies for automake-1.11
    Checking dependencies for libtool-2.2.8
    Checking dependencies for pkg-config-0.25
 >> autoconf (autoconf) is NOT installed
 >> crypt-ssleay (libcrypt-ssleay-perl) is NOT installed
    Checking dependencies for xz-5.0.3
 >> ccache (ccache) is NOT installed
 >> uuid-dev (uuid-dev) is NOT installed
 >> liblzo2 (liblzo2-dev) is NOT installed
 >> intltool (intltool) is NOT installed
 >> xsltproc (xsltproc) is NOT installed
    Checking dependencies for usb_loader
 >> libusb (libusb-1.0-0-dev) is NOT installed
 >> perl-expect (libexpect-perl) is NOT installed
 There are missing packages, please install them with the following commands:
 
                             
 sudo apt-get install curl libncurses5-dev texinfo minicom quilt git-core autoconf libcrypt-ssleay-perl ccache uuid-dev liblzo2-dev intltool xsltproc libusb-1.0-0-dev libexpect-perl

How to configure RidgeRun SDK

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

$(DEVDIR)$ make config
Ridgerun Linux SDK
Board configuration: Xilinx Zynq-7000 Zedboard
Multi-core machine, using 16 out of 8 cores for building

Processing toolchain...
Processing kernel...
Processing fs...
Building Apps.defs
Entering host-apps...
Entering apps...
Entering avahi-0.6.19...
Entering busybox...
Entering /home/dchaverri/devdirs/RidgeRun/zedboard_may19/toolchain...
Entering arch...
Entering base...
Entering mach...
Entering base...
Entering proprietary_src...
Entering myapps...
Processing bootloader...
Processing installer...

Then a menu screen similar to the one below should appear:

Config Menu


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: By default, for each platform RidgeRun has a SDK for, a default configuration setup is assigned. This configuration that comes with the SDK is a known-to-work setup and can be used as it is to build the SDK for the first time, later on the user is free to do as many configuration adjustments as necessary.


How to build RidgeRun 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 <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 (PLEASE NOTICE THAT SOME OF THE COMMANDS ARE DEPRECATED BUT HAVE NOT BEEN REMOVED FOR COMPATIBILITY REASONS):

make help

It will show a list as the shown bellow:

RidgeRun Integrated Linux Software Developer's Kit


Make targets:

   build           - build kernel, target filesystem, bootloader
   force_build     - same as build, but forces the recompilation of the target filesystem
   kernel          - build kernel
   fs              - build target filesystem
   cmdline         - build cmdline for target kernel (fs target does the same as well)
   bootloader      - build bootloader
   patch           - fetch the source and apply any patches
   unpatch         - remove all applied patches
   config          - allow SDK to be configured
   config_batch    - attempt to configure without user interaction
   clean           - delete all derived files
   remove_fs       - delete the filesystem
   remove_fsdev    - delete the filesystem staging directory
   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
   rrsdk_patches_refresh - Update merged series file contains arch, mach, and top level
                     patches.  Only for bootloader, kernel and dvsdk/ezsdk directories.
   copyrights      - generate the copyright documentation for every package in the SDK
   copyrights_check - check if the link of each package is valid
   sourcedistro    - generate the source distribution package
   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

 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



Note: A useful target is the "doc" target that is used for generating documentation providing details regarding internal implementation of the SDK and the API to interact with his components. So for example, to see the documentation regarding RidgeRun SDK Class and its parameters run:

make doc

Then go to documents directory:

cd $DEVDIR/documentation/html

Open the index.html file and go to Modules -> RidgeRun SDK Class.


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

$(DEVDIR)$ make
The system is ubuntu-12.04 running in a 64 bit architecture
SYSID: ubuntu-12.04_64
Checking for host packages required by the SDK build system:
curl (curl) is installed
buildsystem (build-essential) is installed
Checking dependencies for libtool-2.2.8
Building internal SDK version of libtool-2.2.8...
Source code for libtool-2.2.8 not found, fetching it...
Found libtool-2.2.8.tar.gz on /opt/ridgerun/downloads (verified)
Processing libtool-2.2.8.tar.gz...
make (make) is installed
ncurses (libncurses5-dev) is installed
texinfo (texinfo) is installed
minicom (minicom) is installed
perl (perl) is installed
quilt (quilt) is installed
dc (dc) is installed
subversion (subversion) is installed
git (git-core) is installed
Checking dependencies for automake-1.11
Checking dependencies for libtool-2.2.8
Building internal SDK version of libtool-2.2.8...
Checking dependencies for pkg-config-0.25
Building internal SDK version of pkg-config-0.25...
Source code for pkg-config-0.25 not found, fetching it...
Found pkg-config-0.25.tar.gz on /opt/ridgerun/downloads (verified)
Processing pkg-config-0.25.tar.gz...
.
.
.
.  
(CONTINUES)

or you can compile each component separately:

$(DEVDIR)$ make kernel
  Processing kernel...
    Source code for kernel not found, fetching it...
    Found linux-2.6.32.17-psp03.01.01.39.tar.gz on /opt/ridgerun/downloads (verified)
    Unpacking linux-2.6.32.17-psp03.01.01.39.tar.gz... 

Merging arch patches into the series...
Merging mach patches into the series...
    Applying quilt patches
  Generating include/asm-arm/mach-types.h
scripts/kallsyms.c: In function ‘read_symbol’:
scripts/kallsyms.c:112:9: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result]
scripts/mod/modpost.c: In function ‘get_markers’:
scripts/mod/modpost.c:1563:12: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result]
scripts/mod/modpost.c: In function ‘add_marker’:
scripts/mod/modpost.c:1983:10: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result]
kernel/sched.c: In function 'update_sysctl':
kernel/sched.c:7053: warning: comparison of distinct pointer types lacks a cast
drivers/char/tty_buffer.c: In function 'tty_insert_flip_string':
drivers/char/tty_buffer.c:250: warning: comparison of distinct pointer types lacks a cast
drivers/char/tty_buffer.c: In function 'tty_insert_flip_string_flags':
drivers/char/tty_buffer.c:287: warning: comparison of distinct pointer types lacks a cast
net/ethernet/eth.c:402: warning: 'print_mac' is deprecated (declared at net/ethernet/eth.c:398)
net/ethernet/eth.c:402: warning: 'print_mac' is deprecated (declared at net/ethernet/eth.c:398)
lib/psrwlock.c: In function '__psread_lock_slow':
lib/psrwlock.c:368: warning: unused variable 'subclass'
lib/psrwlock.c: In function '__pswrite_lock_slow_common':
lib/psrwlock.c:689: warning: unused variable 'subclass'
lib/psrwlock.c:683: warning: unused variable 'task'
lib/psrwlock.c: In function '_pswrite_unlock_slow':
lib/psrwlock.c:860: warning: unused variable 'nested'
drivers/i2c/busses/i2c-davinci.c: In function 'i2c_recover_bus':
drivers/i2c/busses/i2c-davinci.c:280: warning: unused variable 'pdata'
drivers/i2c/busses/i2c-davinci.c: At top level:
drivers/i2c/busses/i2c-davinci.c:145: warning: 'generic_i2c_clock_pulse' defined but not used
drivers/media/video/davinci/dm365_generic_prgb_encoder.c:217: warning: function declaration isn't a prototype
drivers/media/video/davinci/dm365_generic_prgb_encoder.c:252: warning: function declaration isn't a prototype
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
    Build complete

$(DEVDIR)$ make bootloader
Processing bootloader...
Building images for bootloader
Build complete

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

  • VERBOSE. This option set the verbose level of the build system while building the SDK.
    • Level 0: no messages are printed, all command outputs are redirected to LOGFILE (see below).
    • Level 1: Commands, info and warning messages will be shown
    • Level 2: Same level 1, but using verbose kernel build
$(DEVDIR)$ make VERBOSE=1
  Ridgerun Linux SDK
  Board configuration: Xilinx Zynq-7000 Zedboard
  Multi-core machine, using 16 out of 8 cores for building

if [ -d toolchain ] ; then echo -e "\040" "Processing toolchain..."; export PATH="/opt/Xilinx/14.4/ISE_DS/EDK/gnu/arm/lin"/bin:$PATH ; make   -C toolchain  DEVDIR=/home/dchaverri/devdirs/RidgeRun/zedboard_may20 TABINDEX="\040\040\040" ; fi
  Processing toolchain...
make[1]: Entering directory `/home/dchaverri/devdirs/RidgeRun/zedboard_may20/toolchain'
make  -C arm-xilinx-linux-gnueabi build
make[2]: Entering directory `/home/dchaverri/devdirs/RidgeRun/zedboard_may20/toolchain/arm-xilinx-linux-gnueabi'
ln -sf copyrights.xml.2.15 copyrights.xml
# We install all the applications during the normal build process, but only
# if the FSROOT directory already exists, otherwise we may break the detection
# for running the buildfs target if required, because we will create the FSROOT ahead of time
if [ -d /home/dchaverri/devdirs/RidgeRun/zedboard_may20/fs/fs ] ; then \
     make  buildfs ; \
  .
  .
  .
  .
(CONTINUES)

  • LOGFILE. This option is similar to VERBOSE, except that all the log, info and warning messages will be redirected to the file path specified after the LOGFILE parameter. The log file path must be an absolute path and the directory path to such file must exist. The LOGFILE option is only useful at VERBOSE level 0. Example:
$(DEVDIR)$ make LOGFILE=/tmp/logfile
  Ridgerun Linux SDK
  Board configuration: Xilinx Zynq-7000 Zedboard
  Multi-core machine, using 16 out of 8 cores for building
 
  Processing toolchain...
    Build complete
  Processing kernel...
    Device tree generated
    Build complete
    Build complete
  Processing fs...
    Building Apps.defs
  .
  .
  .
  .
(CONTINUES)

....
Build complete
$(DEVDIR)$ cat /tmp/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:

  • Set and export the DEVDIR environment variable to the absolute path of your development directory:
$ export DEVDIR=/path/to/devdir
  • Include on your PATH variable the path to the binary cross-compiler toolchain being used:
$ export PATH=/path/to/toolchain/binaries:$PATH

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

$ `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

  • build: Builds the kernel, target File System and Bootloader.
  • kernel: Builds kernel.
  • fs: Builds the target filesystem.
  • cmdline: Builds cmdline for target kernel (fs target does the same as well).
  • bootloader: Builds the bootloader.
  • config: Enters SDK configuration mode.
  • config_batch: Attempts to configure without user interaction.
  • clean: Deletes 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 log (svn log command) 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: Prelinks the root filesystem.
  • install: Installs 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


How to use the installer system

The RidgeRun SDK provides a series of alternatives when it comes to installation methods. This 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.

Sdk installer attached.jpg

When the option is selected two new options become available: 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.

  • Installer to U-boot communication options

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.

  • Transfer options for installation

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.

Sdk installer sdcard.jpg

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.


3. Create a SD card flasher

This installation method allows the developer to create a SD card capable of flashing the firmware component into flash (NAND, NOR, etc). In order to enable this option proceed to select the corresponding option under Firmware deployment mode as shown below:

Sdk installer flasher.jpg

The rest of configuration settings required are the same as with the Booting from an SD card procedure and specified in How to boot a board from a SD card. The Flasher SD card is a bootable card, once inserted into the board (make sure that your hardware is configured to boot over SD card) just power ON the board, you should get an output similar to the following:

U-Boot 2010.12-rc2-00000-g6425bdf-dirty (May 08 2014 - 13:58:49)
Cores: ARM 297 MHz
DDR:   243 MHz
I2C:   ready
DRAM:  128 MiB
NAND:  256 MiB
MMC:   davinci: 0, davinci: 1
*** Warning - booting from SD, using default environment

Splash Composite (720,480)
Image (350,260)
Composite output initialized
Net:   Ethernet PHY: GENERIC @ 0x00
DaVinci-EMAC
Hit any key to stop autoboot:  0 
reading uEnv.txt

98 bytes read
Importing environment from mmc ...
Running Installer...
reading installer.scr

2350 bytes read
## Executing script at 82000000





  __________ .__     .___               __________
  \______   \|__|  __| _/  ____    ____ \______   \ __ __   ____
   |       _/|  | / __ |  / ___\ _/ __ \ |       _/|  |  \ /    \ 
   |    |   \|  |/ /_/ | / /_/  >\  ___/ |    |   \|  |  /|   |  \ 
   |____|_  /|__|\____ | \___  /  \___  >|____|_  /|____/ |___|  / 
          \/          \//_____/       \/        \/             \/ 

Embedded Linux Solutions


SDCard Installer Script Generated by RidgeRun SDK

Target Platform: Leopard Board DM365

  Press any key to continue...



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.

SDK file system types.jpeg

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]