Archive for the ‘Embedded System’ Category

Building the Android kernel

Velibor Cakarevic

Downloading Android kernel code

If you download Android 2.1 platform you will not get the source code of the kernel. This is due to that there is quite a huge amount of code needed to be downloaded, it takes time to build the kernel and not many application developers are interested in the kernel code. Below is a description of how to download the Android source code and compile it for ARM, using Linux as your OS. Note that porting to hardware is not in the scope of this description.

First go to your home directory and create a directory where you wish to work in, e.g. myAndroid and step into that directory. Note that ‘$’ is not part of a command but illustrates in this document the commands.
$ cd ~
$ mkdir myAndroid
$ cd myAndroid

To clone the common Android kernel and get the kernel code use the command:

$ git clone git:// android-kernel

The command creates a new folder called ‘android-kernel’ (you can choose another name if you wish) in your ‘myAndroid’ folder and downloads the kernel code.

Go to that folder:

$ cd android-kernel

Building the Android kernel code

Android relies on Linux version 2.6. When building the kernel you will do these commands:
$ make menuconfig
$ make

The command ‘make menuconfig’ configures the kernel. This process involves specifying what functionality to put into the kernel. Additionally, decisions have to be made (when possible) whether kernel code should be statically or dynamically linked. Statically linking means that all modules are built and linked into the kernel. Optimized static kernels execute much faster, since there are no shared object lookups and their binary size is smaller.

With dynamic loading you can choose to manually load the modulus to the kernel by using insmod or modprobe tool/command. Loadable kernel modules allow changing code during runtime. Loadable modules are pieces of kernel code which are not linked (included) directly in the kernel. One compiles them separately, and can insert and remove them into the running kernel at almost any time. If you want a module to be dynamically loaded give it the option <M> during ‘make config’ procedure.

If you want to make an own module you should enable the module support after doing ‘make menuconfig’

Loadable module support —> [*] Enable loadable module support

When building for another processor architecture than the one that your host processor uses you must use a crosscompiler and set the architecture parameter. This will show you how to compile the code for an ARM processor architecture. Before doing ‘make menuconfig’ set the architecture parameter:

$ export ARCH=arm

Now start the configuration of the kernel:

$ make menuconfig

Picture 1 shows the menu when configuring the kernel.

After having modified the configuration you will at the exit be prompted by a question, whether you wish to save the changes. Choose Yes if you want to do so. You can check the generated .config file by:

$ nano .config

To set the crosscompiler use do the command:

$ export CROSS_COMPILE=arm-unknown-linux-gnueabi-

Note! I am using a compiler that you may not have. If you have downloaded the whole Android 2.1 platform (perhaps you have it in another folder) you could use

In that case the command to set the cross-compiler as the one delivered and precompiled in the Android platform is:

$ export CROSS_COMPILE=~/your_android_platform_folder/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

Make starts the build process and builds the kernel according to the configuration file. To start the build process do:

$ make

The image is generated in the folder: arch/arm/boot/zImage

If you wish to search for the zImage use the find command:
$ find -name ‘zImage’

Some tips

When configuring the kernel in the menu (see figure 1) there may be some flags that you cannot remove. However you can still modify the ‘.config’-file directly if you wish to. You should on the other hand be sure of what you are doing. When building again, i.e. make you will be prompted by a question if you wish to keep that flag. Press ‘n‘ to exclude the module. If this question does not appear it is most likely that the module has not been removed.

When working with building of the kernel, the best approach is to remove modules that are not necessary in your kernel, and when adding new modules add them step by step. This will give you a fair chance to fix errors such as build failures, but also track down crashes when running on target.

When you have build errors and keep removing flags (i.e. modules) it is good to remove the object files and make a new build. Removing the objectfiles and rebuilding the kernel is done accordingly:
$ make clean
$ make

Edited 5 times. Last edit by KennyLeopold Amanda on Apr 22, 2011 at 8:46:27 PM (about 15 weeks ago).
March 15, 2011 3:35:08 PM PDT (22 weeks ago)
PhotoJayson Burak

BAE Systems
Member since Mar 15, 2011
Posts: 1
Hi there,

I apologize for asking a stupid question, but I’m curious as to what the next steps are from here, once the new zImage has been created…or in other words, how do I get the zImage loaded on the device? I have found a few different options, but none of them seem to work for me. What I mean by that is that whenever I try to flash new kernel or new boot image (kernel + ramdisk) to my device, it does not load. I don’t get any errors during the build or make process. So, I am either flashing the device wrong or something else that I have no knowledge of. Any help would be appreciated. Thanks.

~ Jay

March 16, 2011 1:25:26 AM PDT (22 weeks ago)
PhotoVelibor Cakarevic

Member since Apr 22, 2010
Location: Malmo
Posts: 2
Hello Jayson,

It is hard to tell what might be causing the device not to display the home screen. If you flash procedure would fail then you should get an error message during that procedure.

The zImage is an compressed code that is unzipped at the boot procedure. You can see the procedure in the command prompt when the device boots up (some boot-loaders print a dotted line to animate the procedure). If it is uncompressed then that should be a good sign, that you have flashed it ‘corrrectly’ (but I am comparing to my own projects). You tell the bootloader (set the environment variables) which memory address the image is stored at. I do not know which bootloader you are using but Uboot is the one I have been using [1].

Further you might not have the correct driver code for the display. Such driver code (Linux driver code) should be delivered to you by the vendor. You could ask them about this issue as well.

Have you enabled/added the display driver module (in the “make menuconfig”)? If it is statically linked (‘*’) it is built in the kernel. If it is dynamically linked (‘M’) then the kernel will load/insert the module in the runtime. You can also insert the modules manually by the ‘insmod’ [2] or ‘modprobe’ [3] command.

One tip is to mount the device’s filesystem on to a laptop (done in the bootloader by setting parameters) i.e. you boot up the device but the device gets the filesystem from a folder on your laptop. From there you can insert modules. This approach (mounting the filesystem) makes is ‘easier’ to work since you (most probably) have more space on your laptop then on your device and do not have to flash the filesystem on your device (saves you time).

Further if you are using Beagleboard, then there are ported versions of Android for their device.[4]

Google has also added some information since I posted this article. Please have a look at the “Android Platform Developer´s Guide” [5]

In order to help you I would have to be sitting next to you.



Download Android source

1. Make sure you have a ~/bin directory in your home directory, and check to be sure that this bin directory is in your path:

     $ cd ~

     $ mkdir bin

     $ echo $PATH

2. Download the repo script and make sure it is executable:

     $ curl >~/bin/repo

     $ chmod a+x ~/bin/repo

3. Download from CoreDruids Android repository –

    $ repo init -u git://

    $ repo sync

    $ make TARGET_PRODUCT=beagleboard

Prepare Root file system

     $ cd out/target/product/beagleboard

     $ mkdir android_rfs

     $ cp -r root/* android_rfs

     $ cp -r system android_rfs

     $ cd android_rfs

     $ chmod -R 777 *

     $ chown root.root *

prepare tar file for android_rfs directory

Prepare uImage

     $ cd <android_root_dir>/kernel

     $ make ARCH=arm omap3_beagle_android_defconfig

     $ export toolchain path

     $ make ARCH=arm CROSS_COMPILE=arm-eabi- uImage

For enabling USB EHCI port

1. Follow the steps in the following link to compile u-boot –
2. copy u-boot.bin in FAT partition of SD card

Prepare SD Card

To boot Android from SD card you need to create a dual partition card.

1. Follow the link for creating SD card partitions

2. Untar root file system in ext3 partition of SD card.

3. Copy the uImage to SD card’s FAT partition.

On Beagleboard

Execute the following commands in bootloader console to boot android on BeagleBoard

     $ setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2

 video=omapfb.mode=dvi:1280x720MR-24@50 init=/init rootfstype=ext3 rw rootdelay=1 nohz=off androidboot.console=ttyS2

     $ mmc init

     $ fatload mmc 0 80300000 uImage

     $ bootm 80300000

Known Issues

The kernel gives panic after couple of reboots (We observed that after re-flashing problem gets resolved)

ntroducing the BeagleBoard-xM

The BeagleBoard is a pocket-sized reference board containing a Texas Instruments Open Multimedia Application Platform (OMAP) 3 system-on-a-chip (SoC) processor, which includes an ARM Cortex-A8 core, Texas Instruments C64x+ digital signal processor (DSP), and onboard graphics engine, as well as integrated dual data rate (DDR) random-access memory (RAM). The BeagleBoard is an inexpensive platform for hobbyists, academics, and professionals who are learning Linux and small systems. Figure 1 shows the BeagleBoard-xM.
Figure 1. BeagleBoard-xM
Picture of the BeagleBoard-xM

In a previous developerWorks article, I explored booting Linux on BeagleBoard revision C, which hosts a 600MHz OMAP3530 processor, 256MB RAM, and 256MB NAND flash memory. Revision xM is more robust with a 1GHz OMAP3730 processor and 512MB RAM. It boots from the microSD card with no flash memory and hosts new interfaces, including a DB-9 serial connector, integrated 4-port Universal Serial Bus (USB) hub, and integrated Ethernet port. The BeagleBoard-xM retains many revision C features, including Digital Visual Interface (DVI)-D output, S-video, audio, Joint Test Action Group (JTAG), and a large expansion header.

Back to top

Building your working environment

The following sections show you how to source required components, set up, and test the console.

Sourcing components

The BeagleBoard-xM is packaged with a preformatted 4GB microSD card along with an adapter so you can plug the card into a standard Secure Digital (SD)/MultiMediaCard (MMC) slot, but no cables. You need the following:

Powering the BeagleBoard-xM

Traditionally, the BeagleBoard is powered from either an external 5V power source or a USB On-The-Go (OTG) cable. These cables, however, provide only up to 500mA, barely enough to power the xM. It is highly recommended that you use an external power supply—either a 5V power brick with a 2.1mm barrel (positive center) or a Y cable that plugs into two USB ports on your host.

  • Power supply
    Use a 5V external power supply.
  • Serial cable
    The BeagleBoard-xM provides a female DB9 port and requires a serial cable to connect the console to your host system. Use a straight-through (not null-modem) cable. If your host system has no serial port, use a DB9-to-USB cable.
  • USB keyboard and USB mouse
  • DVI-D capable monitor and a DVI-D to High-Definition Multimedia Interface (HDMI) cable
    Note that the board does not emit Video Graphics Array (VGA) signals through this connector, so a standard DVI-to-VGA converter cable won’t work.
  • 4GB+ microSD cards and a card reader
    You can overwrite the data on the provided card, but it is better to purchase a few cards to use with different distributions. Use a USB card reader if your host has no integrated reader.

Setting up the console

Linux users can use minicom, shown in the examples that follow. Microsoft® Windows® users can use Hyperterminal or PuTTy, and Mac users can use screen, ZTerm, or MacWise.

Connect the serial cable to the BeagleBoard-xM’s DB9 port and your host, and launch minicom in setup mode as root:

sudo minicom -s


Listing 1 shows the minicom configuration menu.
Listing 1. minicom configuration menu

            | Filenames and paths      |
            | File transfer protocols  |
            | Serial port setup        |
            | Modem and dialing        |
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |


Select Serial port setup. The resulting sub-menu is shown in Listing 2.
Listing 2. minicom serial port setup menu

    | A -    Serial Device      : /dev/ttyS0                                |
    | B - Lockfile Location     : /var/lock                                 |
    | C -   Callin Program      :                                           |
    | D -  Callout Program      :                                           |
    | E -    Bps/Par/Bits       : 115200 8N1                                |
    | F - Hardware Flow Control : No                                        |
    | G - Software Flow Control : No                                        |
    |                                                                       |
    |    Change which setting?                                              |
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |


If your cable is a straight-through serial cable, the serial device is /dev/ttyS0. If you use a USB converter, use /dev/ttyUSB0. If no text appears in the next step, it is possible your host assigned a different device, so increment 0 to 1 and try again. For all devices, the settings are 115200, 8 bits, no parity, 1 stop bit, and no hardware or software flow control.

When your settings are correct, save this setup as the default by choosing Save setup as dfl and then Exit. The minicom welcome message appears, as shown in Listing 3.
Listing 3. minicom welcome message

Welcome to minicom 2.3

Compiled on Oct 24 2008, 06:37:44.
Port /dev/ttyS0

       Press CTRL-A Z for help on special keys


To verify, apply power to your BeagleBoard-xM, and type a key to stop the boot countdown. Boot-loader messages appear showing the X-loader and U-boot version, date of build, and output, with U-boot showing specifics about system memory, input and output channels, expansion board information, and the board’s revision and die ID, as shown in Listing 4.
Listing 4. X-Loader and U-Boot

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)
Beagle xM Rev A
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz,
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial

Probing for expansion boards, if none are connected you'll see a harmless I2C error.

No EEPROM on expansion board
Beagle xM Rev A
Die ID #77f600001bf00000015739ea0701c021
Hit any key to stop autoboot:  0


Unplug power from your BeagleBoard-xM.

Preparing to boot Linux

Monitor cable

Make sure to never plug the monitor cable in while the board is powered, because that could damage the board. Always unplug the power first.

Plug your keyboard and mouse into the USB sockets on the BeagleBoard-xM. Plug a network cable, if available, into the Ethernet jack. Connect the HDMI-to-DVI cable between the board and a DVI-D monitor.

The following instructions are intended only to get your board up and running with these three Linux distributions. The links in Resources contain development kits, toolchains, and instructions for setting up full development environments.

Back to top

Booting Angstrom Linux

Angstrom Linux is an operating system developed specifically for small computers such as the BeagleBoard-xM. The fastest way to boot Angstrom on the BeagleBoard-xM is with the microSD card that comes with the board, which contains an Angstrom image. However, the image on that card is a verification image, which means that it is provided only to verify the board’s operation. It does not contain a graphical user interface (GUI) and boots by default as a RAM disk; thus any changes you make are lost when you unplug.

The included microSD card contains a single File Allocation Table (FAT) partition of approximately 117MB, containing the following:

  • Boot loaders X-loader (MLO) and U-boot (u-boot.bin)
  • Linux kernel (uImage)
  • Boot script (user.scr)
  • RAM disk root file system (ramdisk.gz)
  • md5sum file to check file sizes

The rest of the card is unformatted.

To boot, insert the microSD card and apply power. After the boot countdown, the system automatically invokes the boot script. The boot-loader text is shown again on the console, followed by boot messages showing the boot processes, including execution of the script itself, loading the kernel and RAM disk, and finally starting the kernel, as shown in Listing 5.
Listing 5. Booting Angstrom

mmc1 is available
The user button is currently NOT pressed.
reading boot.scr

** Unable to read "boot.scr" from mmc 1:1 **
reading user.scr

755 bytes read
Running bootscript from mmc ...
## Executing script at 80200000
mmc1 is available
reading ramdisk.gz

19960110 bytes read
reading uImage

3190568 bytes read
Booting from ramdisk ...
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Angstrom/2.6.32/beagleboard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3190504 Bytes =  3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux.....................................................................
[    0.000000] Linux version 2.6.32 (ubuntu@ip-10-204-115-71) (gcc version 4.3.3 .......


Linux boot messages follow, and then finally the Angstrom logo and a login prompt, as shown in Listing 6.
Listing 6. Angstrom login console

|       |                  .-.                     
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |

The Angstrom Distribution beagleboard ttyS2

Angstrom 2010.7-test-20100820 beagleboard ttyS2

beagleboard login:


Log in as root, no password necessary. You can run basic Linux commands to test the system. Try running testled, and watch the light-emitting diodes (LEDs) on the BeagleBoard-xM.

To see Angstrom in action, you need a full root file system and a matching kernel. The following instructions show how to download and boot the demo image:

  1. Navigate to the Angstrom BeagleBoard demo page and read the instructions.
  2. Download the binary images for the boot loader and root file system from the Angstrom BeagleBoard demo page. There files you need are:
    • mkcard.txt
    • MLO
    • u-boot.bin
    • Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.rootfs.tar.bz2
  3. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  4. Unmount any partitions on the card. Use your card’s device name in place of /dev/sdgin the following example:
    sudo umount /dev/sdg?
  5. Format your SD card using the mkcard.txtscript.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device name in place of /dev/sdg in the following example:

    chmod +x mkcard.txt ; sudo ./mkcard.txt /dev/sdg

    When the operation is done, your microSD card contains two primary partitions:

    • One 70MB FAT partition labeled boot.
    • One ext3 partition labeled Angstrom that takes up the rest of the card’s capacity.

    If your system does not automatically mount these partitions after the script creates them, mount them by hand, replacing your card’s device name for /dev/sdg in the following example:

    sudo mkdir -p /media/boot ; sudo mount /dev/sdg1 /media/boot
    sudo mkdir /media/Angstrom ; sudo mount /dev/sdg2 /media/Angstrom

    The rest of this example assumes these partitions are mounted as /media/boot and /media/Angstrom.

  6. Unpack files to the root file system partition (this command may take some time):
    sudo tar -C /media/Angstrom -xjvf \
  7. Copy files to the boot partition, noting that the kernel image comes directly from the root file system:
    cp MLO /media/boot
    cp u-boot.bin /media/boot
    cp /media/Angstrom/boot/uImage /media/boot
  8. When all operations are done, synchronize file systems and unmount partitions:
    sync ; sudo umount /dev/sdg?
  9. Insert the card into the BeagleBoard-xM and apply power.Note: If the first boot fails with an error like this:
     Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block...

    Restart the system, stop the boot countdown, and type the following command:

    setenv mmcroot /dev/mmcblk0p2 rw

    Then boot the system by typing boot.

The first boot takes a while as the system configures itself. The Angstrom logo appears on the monitor, while on the console each component is configured. After about 10 minutes, an Angstrom login screen appears on the monitor and a boot prompt on the console. Use the login screen to set up a new user and log in. You can also log in on the console as root, no password required.

Back to top

Booting Android

Android has proven to be a popular operating system for the BeagleBoard, as the board is an inexpensive platform for Android application development and testing. There are several ports of Android to the BeagleBoard. This article uses the rowboat project. Be sure to connect a USB keyboard and mouse as well as a DVI monitor before starting.

  1. Download the precompiled binary tarball from the Texas Instruments Android DevKit page, making sure to identify the pre-built image for the BeagleBoard-xM (beagleboard-xm.tar.gz).
  2. Unpack the tarball:
    tar zxvf beagleboard-xm.tar.gz
  3. Read the instructions in README.txt.
  4. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  5. Format your SD card using the provided script.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device in place of /dev/sdg in the following example: /dev/sdg

    When all operation is done, synchronize file systems and unmount partitions:

    sync ; sudo umount /dev/sdg?
  6. Insert the microSD card into the BeagleBoard-xM and apply power.The first boot takes a while as the system configures itself. After about four minutes, you should see the Android logo and then a home screen. If the network does not activate automatically, wait another five minutes and reboot. Note that the console remains active and automatically logs in as root.

Back to top

Booting Ubuntu

Ubuntu is fast becoming a popular distribution for netbooks, mobile Internet devices (MIDs), and other small systems. Canonical, Ubuntu’s parent company, has dedicated resources to porting Ubuntu to ARM processors such as the BeagleBoard. As with Android, make sure to plug in a monitor and USB keyboard and mouse before starting.

  1. Read the instructions on the Ubuntu OMAP Maverick Install page.
  2. Download the precompiled binary image. Make sure to identify the image for the BeagleBoard-xM: Preinstalled netbook image for TI OMAP3 computers (ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz). Do not uncompress the image at this time.
  3. Insert a microSD card with at least 4GB capacity, and determine its device name. For example, if you are using a USB card reader, use fdisk and look for a disk matching the card’s characteristics. The following example shows /dev/sdg:
    # fdisk -l
    Disk /dev/sdg: 3.9 GB, xxx bytes
    255 heads, 63 sectors/track, xxx cylinders
  4. Write the image directly to the card.Note: Be certain that you are targeting your SD card and not a system disk.

    Use your card’s device in place of /dev/sdg in the following example:

    sudo sh -c 'zcat \
     ./ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz > /dev/sdg'

    Note: If your BeagleBoard-xM is revision A3, you may need to download a different kernel. See the Ubuntu Maverick install page for details.

    When all operations are done, synchronize file systems and unmount partitions:

    sync ; sudo umount /dev/sdg?
  5. Insert the card into the BeagleBoard-xM and apply power.The first boot takes a while as the system configures itself, during which the monitor and console may stay dark. After about 5 minutes, the Ubuntu logo appears on the monitor, followed by a series of system configuration screens. Answer the configuration questions using the keyboard and mouse plugged into the BeagleBoard. If the network does not activate automatically, wait until the system is completely operational, shut it down (go to System and choose Shut Down), and then reboot.

The console does not remain active for Ubuntu. You must interact with the system through the monitor and keyboard or mouse. However, you can install a Virtual Network Computing (VNC) server from the Ubuntu Software Center and interact with the system through VNC.

Back to top

Where to go from here

Each of these operating systems has its own community ecosystem, including web sites, wikis, mailing lists, and Internet Relay Chat (IRC) channels, as does the BeagleBoard itself. Take advantage of these excellent resources while you learn about the BeagleBoard-xM and your chosen operating system.




Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.



TI Android FroYo DevKit V2.2 User Guide

User Guide – January 31, 2011


About this manual

This document describes how to install and work with Texas Instruments’ Android FroYo DevKit release for OMAP35x, AM37x, DM37x, AM35x platforms running Android. This release package provides a stable Android distribution with integrated SGX (3D graphics) drivers, TI hardware abstraction for video overlay, multimedia DSP acceleration (on DM37x and OMAP35x only), and standard applications from Android. The package also includes Linux Android kernel, tools and documentation to ease development, deployment and execution of Android based systems. The product forms the basis for all Android application development on OMAP35x, AM37x, DM37x, AM35x platforms. In this context, the document contains instructions to:

  • Install the release
  • Setting up the hardware
  • Steps to use pre-built binaries in the package
  • Running Android on the supported platforms
  • Setting up the Android debugger “adb” with the hardware platform
  • Installing and executing Android (out of market) applications hardware platforms


This section describes the list of Software and Hardware requirements to evaluate the DevKit release.

Hardware Requirements

This release of Android DevKit V2.2 is evaluated on the below given list of platforms. This package should be easily portable on other platforms on similar TI devices.

In the pre-built image for DM37x EVM, the display output is configured to the DVI port by default to support 720P decoding, therefor, the DVI monitor is mandatory in this case.

TI Device Platform Supported Version Other Accessories
OMAP35x EVM Rev G DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min)
Beagleboard Rev Cx DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min)
AM3517 Evaluation Module Rev C DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min)
AM37x Evaluation Module Rev C DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min)
BeagleBoard XM DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min)
DM37x Evaluation Module
(1GHz for 720P video decoding)
Rev D DVI Monitor, USB HUB, USB Keyboard, USB Mouse, Ethernet, UART Cable, Audio Speakers, MMC/SD Card (2GB min, Class4 min for 720P video decoding)


Software Host Requirements

If you are a Android application developer or would like to use Android SDK Tools then refer to for Host PC requirements.

To evaluate this release we recommend you to have a Linux “Ubuntu 8.04 or above” Host machine, See Ubuntu Linux installation notes

Package Content

         |-- Android_Source_Manifest
         |-- Documents
         |   |-- RowboPERF_User_Guide.pdf
         |   |-- Software_Manifests
         |   |-- Test_Performance_Results
         |   |   |-- CTS_Report.tar.gz
         |   |   |-- Performance_Results.pdf
         |   |   `-- Test_Results.pdf
         |   `-- TI-Android-FroYo-DevKit-V2.2_UserGuide.pdf
         |-- OMAP35x_Android_SGX_SDK.tar.gz
         |-- Performance_Apps
         |   |-- 0xbench
         |   |-- rowboatBench
         |   |-- RowboPERF
         |   `-- StorageIO
         |-- Prebuilt_Images
         |   |-- AM35X
         |   |-- AM37X
         |   |-- DM37X
         |   |-- beagleboard-rev-c4
         |   |-- beagleboard-xm
         |   `-- OMAP35X
         |-- Sources
         |   |-- Android_Linux_Kernel_2_6_32.tar.gz
         |   |-- u-boot.tar.gz
         |   `-- x-loader-
         |-- Tools
         |   |-- android-sdk_r06-linux_86.tgz
         |   |-- flash-utility.tar.gz
         |   |-- mk-bootscr
         |   |-- mk-mmc
         |   |-- pinmux-utility.tar.gz
         |   `-- signGP
         `-- Wireless
             `-- WL1271Android-patches.tar.gz

Out of the Box Demo

This section gives the instructions to quickly prepare an SD Card image and get an experience of Android DevKit V2.2 on TI platforms/devices.

  • Get an SD Card of minimum size 2GBytes (Class4 minimum for DM37x EVM) and a USB Card reader
  • Insert the USB SD Card reader (with SD Card) in your host Linux PC
  • Prepare the MMC/SD card Image
 tar -xzvf <Board name>.tar.gz
 cd <Board name>
 sudo ./mkmmc-android /dev/sd<device>
  • The above step prepares the SD Card.
  • Setup the board/platform
    • Do the DIP switch settings to boot from SD Card, see the section on DIP switch setting below.
    • Insert the SD Card into the Board
    • Switch on the platform
    • Wait for 35sec to get Android up on the UI screen
  NOTE: For the first time boot the System might take few minutes to boot. 

  NOTE: If your NAND flash is not empty the system might not boot with MMC, 
        in that case do the following with Serial Console / Terminal prompt in u-boot 

  #> mmc init
  #> fatload mmc 0 0x82000000 boot.scr
  #> source 0x82000000

Android Booting Procedure

Booting Android on any TI platform requires following software components

  • Kernel Image (uImage)
  • Bootloader (u-boot.bin)
  • Bootstrapping (x-load.bin.ift for NAND or MLO for MMC)
  • Filesystem (rootfs)

The above listed software components or images can be populated by

  • Building sources from this package
  • Using the pre-built images in this package

  - To build software components using sources require "ARM cross compiler tool chain".
  - The ARM tool chain can be downloaded from Android pre-built repository. Tool Chain

Software Integration

This section describes the procedure to compile and integrate all the required software components to boot Android on TI platforms.


Download the tool chain and export it in the default Linux Path.


 #> export PATH=<tool chain install path>/linux-x86/toolchain/arm-eabi-4.4.0/bin/:$PATH


Untar the kernel source located in the sources directory

  #> tar -xzvf Android_Linux_Kernel_2_6_32.tar.gz

Execute the following commands to the kernel sources

  #> make CROSS_COMPILE=arm-eabi- distclean

  #> make CROSS_COMPILE=arm-eabi- <default config> 

 Where default config is 

    omap3_evm_android_defconfig         : For OMAP35x, AM37x, DM37x EVM
    am3517_evm_android_defconfig        : For AM35x EVM
    omap3_beagle_android_defconfig      : For Beagleboard Rev Cx, XM

  #> make CROSS_COMPILE=arm-eabi- uImage 

 This command will build the Linux Kernel Image in arch/arm/boot "uImage"


Untar the u-boot sources located in the sources directory

  #> tar -xzvf u-boot.tar.gz

Execute the following commands to the kernel sources

  #> make CROSS_COMPILE=arm-eabi- distclean

  #> make CROSS_COMPILE=arm-eabi- <default config> 

 Where default config is 

    omap3_evm_config         : For OMAP35x, AM37x EVM
    am3517_evm_config        : For AM35x EVM
    omap3_beagle_config      : For Beagleboard Rev Cx, XM

  #> make CROSS_COMPILE=arm-eabi- 

 This command will build the u-boot Image "u-boot.bin"


Untar the x-loader sources located in the sources directory

  #> tar -xzvf x-loader-

Execute the following commands to the kernel sources

  #> make CROSS_COMPILE=arm-eabi- distclean

  #> make CROSS_COMPILE=arm-eabi- <default config> 

 Where default config is

    omap3evm_config         : For OMAP35x, AM37x EVM
    am3517evm_config        : For AM35x EVM
    omap3beagle_config      : For Beagleboard Rev Cx, XM

  #> make CROSS_COMPILE=arm-eabi- 

 This command will build the x-loader Image "x-load.bin"

To create the MLO file used for booting from a MMC/SD card, sign the x-loader image using the signGP tool found in the Tools directory of the Devkit.

  #> ./signGP ./x-load.bin

The signGP tool will create a .ift file, that can be renamed to MLO.


 - The Pre-built images are provided in this package to help users boot android without building the sources

Setting up Hardware

This DevKit release supports six different platforms, OMAP35x EVM, AM37x EVM, DM37x EVM, AM35x EVM, Beagleboard Rev Cx, Beagleboard XM. While they are different devices the hardware setup will almost remain the same.

  • Connect the UART port of the platform to the Host PC and have a Terminal software like TeraTerm, Minicom or Hyperterminal.
  • Connect the Ethernet (on Beagle Rev C4 we don’t have an Ethernet port)
  • Connect Audio Speakers
  • For DM37x EVM or Beagle boards you need to connect DVI Monitor through HDMI connector.
  • Use self powered USB HUB and connect it to USB Host port of the platform, mainly for Beagle and AM35x EVM. For AM37x DM37x, and OMAP35x EVM the onboard keypad can be used
    • Connect USB keyboard and USB Mouse to the USB HUB for use with Beagle or EVM

  - The AM35x EVM and Beagleboard have no keypad mappings, user is recommended to use USB Keyboard over a self powered USB HUB connected to the Host port of AM35x EVM or Beagleboard.
  • Select Appropriate DIP Switch settings on EVM(s) to boot over MMC/SD

For MMC/SD boot – On OMAP35x, DM37x and AM37x EVM the DIP switch SW4 should be set as shown below

Switch 1 2 3 4 5 6 7 8

For MMC/SD boot – On AM35x EVM the DIP switch S7 should be set as shown below

Switch 1 2 3 4 5 6 7 8

Booting Android

TI platforms (Beagle or EVM) can be booted over MMC or NAND or UART. We follow and prefer MMC based booting of platforms.

Procedure to populate MMC/SD Card

Use the mk-mmc utility provided in the tools folder of this package to populate the SD Card. This utility helps users create a MMC/SD Card with required Images to boot Android on any given TI platform.

This will partition the SD card to three partitions namely boot, rootfs and data. 1) The boot partition will get populated with the images required for booting. 2) The rootfs partition will be used as android root filesystem partition. 3) The Media inside the folder Media_Clips will get copied to the data partition. The data partition will get mounted as EXTERNAL storage when Android boots up.

Execute the following command


   #>./mkmmc-android /dev/sdc MLO u-boot.bin uImage boot.scr rootfs.tar.bz2 Media_Clips

This populates the SD/MMC card with all the images.


    To create the boot.scr boot script use the mkbootscr tool found in the Tools directory provided in the DevKit.

If you want to use the pre built images in the SDK you have to adjust the above mentioned command to take them into account, as a more direct example the commands below will generate a SD card for an OMAP3 EVM. Ensure you have your SD card connected to the Linux machine you are using and that it is in /dev/sdb for this command otherwise adjust the command accordingly (WARNING: if you get this wrong it can wipe your HDD). Note that this assumes you installed the SDK in your home (~) directory and that the command is run with sudo (or your preferred way of getting super user privileges) to allow for the reformatting of the SD card.

  HOST $ cd ~/TI_Android_FroYo_DevKit-V2.2/OMAP35X
  HOST $ sudo ../../Tools/mk-mmc/ /dev/sdb

Procedure to add Video, Audio and other media

To play media after booting Android on any platform, the content must be included in the MMC/SD card’s FAT32 partition. If you use the mk-mmc script included in the release package then it creates 3 partitions. The media content should be placed into the 3rd (FAT32) partition.


  #> sudo mount /dev/sdd3 /mnt
  #> sudo cp <all media files> /mnt
  #> sudo umount /mnt


  - This release supports all the standard Android media formats, listed here

Booting the platform

Booting over MMC using boot.scr


  - If the board has bootargs configured already, then the board will not boot for Android automatically, 
  - It is suggested to either delete the bootargs or use the following commands on u-boot prompt through UART console. 

   #> mmc init
   #> fatload mmc 0 0x82000000 boot.scr
   #> source 0x82000000

If the board is not configured for bootargs, then it automatically boots.

Boot arguments

Boot arguments for various boards are as follows.

  setenv bootargs 'console=ttyS2,115200n8 androidboot.console=ttyS2 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=600 omap_vout.vid1_static_vrfb_alloc=y'

  setenv bootargs 'console=ttyS0,115200n8 androidboot.console=ttyS0 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y'

  setenv bootargs 'console=ttyS2,115200n8 androidboot.console=ttyS2 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=720 omap_vout.vid1_static_vrfb_alloc=y'   

  setenv bootargs 'console=ttyS2,115200n8 androidboot.console=ttyS2 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y'

  setenv bootargs 'console=ttyS0,115200n8 androidboot.console=ttyS0 mem=128M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=720 omap_vout.vid1_static_vrfb_alloc=y'

  DM37x EVM:
  setenv bootargs 'mem=71M@0x80000000 mem=128M@0x88000000 console=tty0 console=ttyS0,115200n8 androidboot.console=ttyS0 root=/dev/mmcblk0p2 rw rootfstype=ext3 init=/init rootwait ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi omapfb.mode=dvi:1280x720MR-16 mpurate=1000'

Keypad mappings

The below table lists the keypad and USB Keyboard mappings to Android UI functionality.

USB Keyboard/Mouse Keypad on OMAP35x/AM37x EVM Keypad on AM35x EVM
Home Screen Home R3C2 S3
Left Left Arrow R2C1 S6
Right Right Arrow R0C2 S5
Up Up Arrow R1C3 S7
Down Down Arrow R2C0 S9
Volume Up Volume Up R1C2 S4
Volume Down Volume Down R0C1 S1
Contacts F3
Power R0C0 S2
Select Enter R3C1
Back Mouse right R2C3 S8
Menu F1 R3C3 S10


Using Network Filesystem

Android filesystem can be mounted over network, the bootargs for doing the same should include below text instead of MMC

   ip=dhcp rw root=/dev/nfs nfsroot=<your NFS server ipaddr>:/home/USER/FILESYSTEM_DIR,nolock noinitrd

   Example: Complete bootargs for OMAP35x board using NFS and LCD output

   setenv bootargs init=/init console=ttyS0,115200n8 ip=dhcp rw root=/dev/nfs nfsroot=,nolock mem=256M noinitrd androidboot.console=ttyS0

Using Flashing Utility

Android boot images x-loader and u-boot etc can be flashed to NAND from windows host, using flashing utility provided in tools. Flashing utility is tested on USB connection with AM37X Pre-built images. For instructions on flashing utility please refer the steps at

Display Support

Using DVI Monitor

On OMAP35x, AM37x and AM35x EVMs the on board LCD is used as output device by default (but on DM37x EVM the display output is configured to the DVI port by default). User is allowed to configure DVI port as output device, by changing the boot arguments as shown below.

Append the boot arguments with following text

   omapfb.mode=dvi:1280x720MR-16 omapdss.def_disp="dvi"


  To boot over MMC and use DVI at resolution 1024x768 on OMAP35x EVM, the complete bootargs would be, 

  setenv bootargs init=/init console=ttyS0,115200n8 ip=dhcp rw root=/dev/mmcblk0p2 rw init=/init rootwait mem=256M androidboot.console=ttyS0 omapfb.mode=dvi:1024x768MR-16 omapdss.def_disp="dvi"

We have noticed on few monitors the below bootargs works for DVI.

  setenv bootargs console=ttyS0,115200n8 androidboot.console=ttyS0 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=1000 omap_vout.vid1_static_vrfb_alloc=y vram=16M omapfb.vram=0:8M,1:4M,2:4M omapfb.mode=dvi:hd720 omapdss.def_disp=dvi


  - On beagleboard the DVI port is configured as default output device.

On DM37x EVM, the display is configured to the DVI port with the bootargs as following defined in boot.scr.

  setenv bootargs mem=71M@0x80000000 mem=128M@0x88000000 console=tty0 console=ttyS0,115200n8 androidboot.console=ttyS0 root=/dev/mmcblk0p2 rw rootfstype=ext3 init=/init rootwait ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi omapfb.mode=dvi:1280x720MR-16 mpurate=1000

Using S-VIDEO Monitor

By Setting Boot parameters

On OMAP35x, AM37x and AM35x EVMs the on board LCD is used as output device by default. User is allowed to configure S-video port as output device, by changing the boot arguments as shown below.

Append the boot arguments with following text



  To boot over MMC and use S-video port as output device on OMAP35x EVM, the complete bootargs would be, 

  setenv bootargs 'console=ttyS0,115200n8 androidboot.console=ttyS0 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=720 omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp="tv"'

By Sysfs configuration

Boot the device with LCD as default output device.

  To boot over MMC and use lcd as output device on OMAP35x EVM, the complete bootargs would be,
  setenv bootargs 'console=ttyS0,115200n8 androidboot.console=ttyS0 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=720 omap_vout.vid1_static_vrfb_alloc=y'
Switch video on S-video device

Use the following procedure to display video on s-video device.

Disable overlay1. Before changing any overlay attributes, it should first be disabled.

  #echo 0 > /sys/devices/platform/omapdss/overlay1/enabled;

Reset overlay1 manager which is set to lcd by default

  #echo "" > /sys/devices/platform/omapdss/overlay1/manager;

Disable display1/tv

  #echo 0 > /sys/devices/platform/omapdss/display1/enabled;

Set overlay manager to tv

  #echo "tv" > /sys/devices/platform/omapdss/overlay1/manager;

Enable display1/tv

  #echo 1 > /sys/devices/platform/omapdss/display1/enabled

Open gallery application and play video. Video will be played on s-video device and graphics will be displayed on the lcd.

Switch video on lcd device

Use the following procedure to display video on lcd device.

Disable overlay1. Before changing any overlay attributes, it should first be disabled.

  #echo 0 > /sys/devices/platform/omapdss/overlay1/enabled;

Disable display1/tv

  #echo 0 > /sys/devices/platform/omapdss/display1/enabled;

Disable display0/lcd

  #echo 0 > /sys/devices/platform/omapdss/display0/enabled;

Reset overlay1 manager which is previously set to tv

  #echo "" > /sys/devices/platform/omapdss/overlay1/manager;

Set overlay manager to lcd

  #echo "lcd" > /sys/devices/platform/omapdss/overlay1/manager;

Enable display0/lcd

  #echo 1 > /sys/devices/platform/omapdss/display0/enabled

Open gallery application and play video. Video and graphics will be displayed on the lcd.

Rotation Support

Graphics Rotation

Graphics rotation is managed by software. Use standard android API to rotate screen in portrait or landscape mode. Currently portrait and landscape graphics rotation mode is supported.

Video Rotation

Video rotation is implemented with use of Rotation Engine module in Virtual Rotation Frame Buffer(VRFB) module in OMAP3x. Rotation engine supports rotation of an image with degree 0, 90, 180 and 270.

V4L2 driver supports rotation by using rotation engine in the VRFB module. Driver provides ioctl interface for enabling/disabling and changing the rotation angle. These ioctls are VIDIOC_S_CTRL/VIDIOC_G_CTRL.ioctl.

Following code shows how to set rotation angle to 90 degree:

  struct v4l2_control control;
  int degree = 90; = V4L2_CID_ROTATE;
  control.value = degree;
  ret = ioctl(fd, VIDIOC_S_CTRL, &control);
  if (ret < 0) {
  /* Rotation angle is now set to 90 degree. Application can now do streaming to see rotated image*/

Camera Support

Devkit-V2.2 supports camera sensor (mt9v113) for beagleboard-xm.

MT9V113 Sensor









  • Go to application/activity view luncher > open camera
  • Click on camera capture
  • By default images will get stored at – /sdcard/DCIM


AM37x evm revG with the wireless module supports WLAN and Bluetooth on Android. For steps on installing the wireless module see this page.


  • Menu->Settings->Wireless & networks->Wi-Fi settings
  • click Wi-Fi and wait for few seconds. The following logs appear on serial console output
TIWLAN: driver init
TIWLAN: 977.211973: wlanDrvIf_Open()
TIWLAN: 977.331480: pInitParams->RoamingScanning_2_4G_enable 0 
SDIO clock Configuration is now set to 24Mhz
TIWLAN: 977.543120: CHIP VERSION... set 1273 chip top registers
TIWLAN: 977.549559: Working on a 1273 PG 2.0 board.
TIWLAN: 977.554228: Starting to process NVS...
TIWLAN: 977.558470: No Nvs, Setting default MAC address
TIWLAN: 977.563444: pHwInit->uEEPROMCurLen: 1c
TIWLAN: 977.567656: ERROR: If you are not calibating the device, you will soon get errors !!!
TIWLAN: 977.576109: Chip ID is 0x4030111.
TIWLAN: 977.580198: FEM Type 1 
TIWLAN: 977.583342: Starting to download firmware...
TIWLAN: 977.665770: Starting to download firmware...
TIWLAN: 977.693602: Starting to download firmware...
TIWLAN: 977.698454: Starting to download firmware...
TIWLAN: 977.710875: Starting to download firmware...
TIWLAN: 977.719420: Starting to download firmware...
TIWLAN: 977.725706: Finished downloading firmware.
TIWLAN: 977.730314: Firmware running.
TIWLAN: 977.749785: 
TIWLAN: 977.751707: --------------------------------------------------------------------
TIWLAN: 977.759611: Driver Version  : WiLink_Driver_6.
TIWLAN: 977.765318: Firmware Version: Rev
TIWLAN: 977.770170: Station ID      : 08-00-28-12-34-56
TIWLAN: 977.775145: --------------------------------------------------------------------
TIWLAN: 977.783018: 
TIWLAN: 977.799376: Interrogate TX/RX parameters
  • On the UI, Green check-mark appears and status shows scanning
  • After scan completes, available APs are listed
  • connect to desired AP by clicking on its name and enter required details (username/key etc) and click connect
  • The following appears on console
TIWLAN: 1248.835661: ************ NEW CONNECTION ************
TIWLAN: 1248.841246: -- SSID  = APNAME 
TIWLAN: 1248.845091: -- BSSID = xx-xx-xx-xx-xx-xx
TIWLAN: 1248.849516: ****************************************
  • when successfully connected, you will see status as connected to APNAME


  • To turn off Wi-Fi, click Wi-Fi in Menu->Settings->Wireless & networks
  • Following message appears on console and the green check mark is not visible on UI
TIWLAN: 1706.198423: wlanDrvIf_Release()
TI WLAN: driver unloaded


  • Menu->Settings->Wireless & networks->Bluetooth settings
  • Click Bluetooth and wait for few seconds
  • LED LD3 turns ON on the wireless module and the Bluetooth icon appears on taskbar. The following appears on the debug console
Set BT_EN of WL1271
WL1271: Powering on
  • If BT is enabled green check-mark appears and status shows scanning
  • available bt devices are listed

BT scan results

  • click on desired device to pair with
  • popup with pin will appear

PIN for pairing

  • click Pair button to confirm pairing
  • verify that the desired device shows the same pin. click ok. devices paired


  • To turn off Bluetooth, click Bluetooth in Menu->Settings->Wireless & networks
  • LED LD3 turns OFF on the wireless module, Bluetooth icon is not displayed on taskbar and the following messages appear on console:
Set BT_EN of WL1271
WL1271: Powering off

Bluetooth Object Push profile

Using Bluetooth, it is possible to send receive files (pictures, media files etc).

Sending files
  • go to Menu ->Gallery
  • Select a picture to share
  • click Menu (bottom right)
  • click share, select bluetooth from the options

Send picture from Gallery to Bluetooth

  • select paired bt device to send to
  • the bt device will prompt to accept. accept incoming file
  • once download finished. check file
Receiving files
  • on paired device (e.g. phone), select send to bt, click on omap3evm
  • on evm, notification appears about incoming connection (top left)

incoming transfer icon

  • open task bar. click on note

incoming transfer message

  • in popup click accept

Confirm incoming transfer

  • once download complete. check file

Power Management

Basic Settings

To go in suspend mode

  • Press POWER key on the keypad

To resume from suspend mode

  • Press any button on the key pad

To set the Screen timeout to go suspend

  • Select Settings->Display-> Screen Timeout
  • Select one of the options from the list

To set set the screen always on preventing suspend

  • Select Settings-> Applications-> Development-> Stay awake

To set Screen brightness

  • Select Settings->Display-> Brightness


Advanced Settings

To Disable Power Management

  • Edit init.rc file on the root directory.
  • Set the property hw.nopm to true
  • This will prevent POWER key suspend
  • Select Settings-> Applications-> Development-> Stay awake
  • The above will prevent screen timeout suspend


  • In beagle and am35x platforms there is no keypad connected to the wake up domain. So wake up is not possible by pressing keys. So power management is disabled by default in am35x and beagle platforms.
  • To enable power management in am35x platform copy init_pm.rc to init.rc. In this case, you can wake up am35x platform like below
    Press ENTER on Serial Port console and then press any key on the keypad to wake up the device.
  • If the usb device connected to the USB EHCI port when suspending the device, it might not work properly after resume.

So Disconnect any usb device connected to USB EHCI port when suspending the device.

  • After pressing the POWER key the device will go to early suspend mode. It will take a while(15 seconds)to go to the complete suspend state.

NAND Booting

Fastboot and UBI rootfs

Fastboot flashing utility is for updating the different software components of Android. Here is a guide to reflash the xloader, u-boot, kernel and root-filesystem (UBIFS image). This guide assume that Rowboat has been compiled before trying out these instructions.

Establishing Fastboot connectivity

  • Connect serial port to host PC via null modem cable.
  • Serial port settings: 115200 8N1, No flow control.
  • Apply power to the board.
  • Press any key in serial port utility during boot and get U-boot command prompt.
  • Run “fastboot” on u-boot command prompt (u-boot will echo “fastboot initialized”).
  • Connect USB cable between USB OTG port of the board and host PC.
Setup on linux host
  • On command prompt, run
   $ export ANDROID_ROOT=<rowboat top level directory>

   $ cd $ANDROID_ROOT/out/host/linux-x86/bin

   $ sudo ./fastboot devices

if a device number is echoed, fastboot is working.

Setup on Windows host
   %SingleBootLoaderInterface% = USB_Install, USB\VID_0451
  • Proceed installing, with the difference that device to be selected is “Android Bootloader Interface” instead of “Android ADB Interface”.

Creating ubifs images

  • Make sure you have all the necessary tools to build the UBI image.
   $ sudo apt-get install mtd-utils
  • Create a self explanatory ubinize.cfg configuration file. For example:
   $ cat ubinize.cfg
  • Add all the permissions to the filesystem. Android will eventually re-assign the correct/necessary permissions on first boot.
   $ chmod -R 777 temp/
  • Create ubifs.img.

We suggest using latest mtd-utils. mtd-utils(v1.3) shipped with Ubuntu have some bugs. Clone/download the latest mtd-utils sources and build them:

   $ git clone git://
   $ cd mtd-utils
   $ sudo make install

General syntax is:

   $ sudo mkfs.ubifs -r temp/ -m X -e Y -c Z -o ubifs.img

        X -> minimum I/O unit size
        Y -> logical erase block size
        Z -> maximum logical erase block count.
             See calculation here for how this number is determined.

For Am37x board(256MB NAND) it will be:

   $ sudo mkfs.ubifs -r temp/ -m 2048 -e 126976 -c 1948 -o ubifs.img

        -m 2KiB
           The minimum I/O size of the underlying UBI and MTD devices. In our case this is a 2KiB page.
        -e 124KiB
           Erase Block Size: UBI requires 2 minimum I/O units out of each Physical Erase Block (PEB) for overhead:
           1 for maintaining erase count information, and 1 for maintaining the Volume ID information. The PEB size
           is 128KiB, so this leads to each Logical Erase Block (LEB) having 124KiB available for data. 
        -c 1948
           The maximum size, in LEBs, of this mtd partition.
           Calculated as per instructions here
  • Create ubi.img for flashing.
   $ ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubinize.cfg

Fastboot commands

   $ export ANDROID_ROOT=<rowboat_top_level_build_directory>

   $ cd $ANDROID_ROOT/out/host/linux-x86/bin
  • List connected devices
   $ sudo ./fastboot devices
  • Update xloader.
   $ sudo ./fastboot flash xloader <xloader_binay_path>/MLO
  • Updating u-boot.
   $ sudo ./fastboot flash bootloader <uboot_binary_path>/u-boot.bin
   sending 'bootloader' (203 KB)... OKAY [  0.541s]
             writing 'bootloader'... OKAY [  0.552s]
   finished. total time: 1.093s
  • Updating kernel.
   $ sudo ./fastboot flash boot <kernel_image_path>/uImage
   sending 'boot' (2537 KB)... OKAY [  6.466s]
                   writing 'boot'... OKAY [  3.330s]
   finished. total time: 9.796s
  • Updating filesystem.
   $ sudo ./fastboot flash system <rootfs_image_path>/ubi.img
   sending 'system' (72320 KB)... OKAY [183.758s]
                 writing 'system'... OKAY [ 84.040s]
   finished. total time: 267.819s
  • Erasing partition.
   $ sudo ./fastboot erase <partition name> (eg. xloader)
  • Reboot
   $ sudo ./fastboot reboot
  • Display fastboot variable
   $ sudo ./fastboot getvar <variable>
  • Exit fastboot mode in uboot
   $ sudo ./fastboot continue

Booting with UBIFS rootfs

  • Set the bootarguments from u-boot prompt.
   # setenv nandboot 'echo Booting from nand ...; nand read ${loadaddr} ${boot_nand_offset} ${boot_nand_size}; bootm ${loadaddr}'

   # setenv bootcmd 'run nandboot'

   # setenv bootargs 'init=/init console=ttyS0,115200n8 noinitrd ip=off androidboot.console=ttyS0 rootwait mem=256M \
     omap_vout.vid1_static_vrfb_alloc=y rw ubi.mtd=4 rootfstype=ubifs root=ubi0:rootfs bootdelay=2'


  • AM3517evm u-boot doesn’t support Full Speed USB mode(USB 1.1) and it expects HOST machine USB port to be High Speed USB (USB 2.0).

YAFFS2 rootfs

Following the official(?) procedure how to incorporate yaffs linux to write/flash the YAFFS2 image i.e flash_erase <mtd_partition>, mount the <mtd_partition> and copy/untar the Android rootfs, from a running system (MMC/NFS), onto the mount_point to boot from NAND partition.

flashing the MTD partition

  • Copy the rootfs.tar.bz2 file-system to the rootfs partition of MMC/SD card.
  • Now boot the device from MMC/SD card and determine the MTD device for the file system partition of you Flash device
   target# cat /proc/mtd
   dev:    size   erasesize  name
   mtd0: 00260000 00020000 "U-Boot"
   mtd1: 00020000 00020000 "U-Boot Env"
   mtd2: 00440000 00020000 "Kernel"
   mtd3: 0c820000 00020000 "File System"
   mtd4: 03120000 00020000 "Reserved"

The file system partition of the flash device is /dev/mtd/mtd3

  • Erase the file system partition
   target# flash_eraseall /dev/mtd/mtd3
   Erasing 16 Kibyte @ 3b9c000 -- 99 % complete.
  • Mount the Flash file system partition using the block device node on a temporary directory /tempd.
   target# mkdir /tempd

   NOTE:  For small block NAND devices (i.e. DM6446) you must mount the file system as a YAFFS file system.
          For large block NAND devices (i.e. DM355/AM389X) the file system should be mounted as YAFFS2.
          Using the wrong version of YAFFS will result in error messages similar to:

   target# mount -t yaffs2 /dev/block/mtdblock3 /tempd
   yaffs: dev is 32505859 name is "mtdblock3"
   yaffs: Attempting MTD mount on 31.3, "mtdblock3"
   yaffs: MTD device does not support have the right page sizes
   mount: wrong fs type, bad option, bad superblock on /dev/mtdblock3,
          or too many mounted file systems
  • Untar the contents of the tarball file system image to the Flash device
   target# cd /tempd

   target# busybox tar xjf /rootfs.tar.bz2
  • Unmount the Flash file system partition
   target# cd /

   target# umount /tempd
  • Now the target is ready to mount the rootfs from NAND.
   target# reboot

Booting with YAFFS2 rootfs

  • Set the YAFFS2 bootarguments from u-boot prompt.
   # setenv bootargs 'init=/init console=ttyS0,115200n8 noinitrd ip=off androidboot.console=ttyS0 rootwait mem=256M \
     omap_vout.vid1_static_vrfb_alloc=y rw root=/dev/mtdblock3 rootfstype=yaffs2 bootdelay=2'

To Do List

  • Fastboot flashing support for YAFFS2

Building Android Sources

Android sources (filesystem) can be built by following the instructions documented here

As Google we recommend to use Ubuntu 8.04+ , but also you can use CentOS 5.3 (32 bit).

  • Install DHCP server
  • Install tftp server (actual for OMAP3EVM)
  • Install repo tool
  • Set up your Linux development environment, make sure you have the following:

Required packages:

Git 1.5.4 or newer and the GNU Privacy Guard. JDK 5.0, update 12 or higher. Java 6 is not supported, because of incompatibilities with @Override. flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.6-dev (optional), build-essential, zip, curl, minicom, tftp-server, uboot-mkimage

For Ubuntu 32-bit use such command:

  $ sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev minicom tftpd uboot-mkimage expect

Ubuntu Intrepid (8.10) users may need a newer version of libreadline:

  $ sudo apt-get install lib32readline5-dev

Configure your network

  • Configure your host Ethernet adapter
  sudo ifconfig ethX netmask up
  • Configure DHCP server for target’s network
     ; Example dhcpd.conf
     default-lease-time 600;
     max-lease-time 7200;
     subnet netmask {

     host beagleboard_rev_c3 {
       hardware ethernet 00:80:C8:xx:xx:xx;

     host omap3evm_rev_d {
       hardware ethernet 00:50:c2:xx:xx:xx;
       filename "evm/uImage"; <- this string actual for boot with tftp 
  • Configure TFTP-server

    service tftp
      protocol        = udp
      port            = 69
      socket_type     = dgram
      wait            = yes
      user            = nobody
      server          = /usr/sbin/in.tftpd
      server_args     = /tftpboot
      disable         = no
  • Clone the Sources (While build android for DM37x EVM, replace TI-Android-FroYo-DevKit-V2.xml with TI-Android-FroYo-DSP-DevKit-V2.xml in the instructions below, which has multimedia DSP acceleration enabled.)
   #> mkdir rowboat-android
   #> cd rowboat-android
   #> repo init -u git:// -m TI-Android-FroYo-DevKit-V2.2.xml
   #> repo sync
  • Build the root file system for AM37x and DM37x (Beagle XM, AM37x/DM37x REV G EVM)
   #> make TARGET_PRODUCT=omap3evm OMAPES=5.x -j8
  • Build the root file system for AM3517
   #> make TARGET_PRODUCT=am3517evm OMAPES=3.x -j8
  • Build the root file system for OMAP35x
   #> make TARGET_PRODUCT=omap3evm OMAPES=3.x -j8
  • Install the SGX (Open GL drivers) libraries and package into filesystem

This step is not needed, but still given here to explain how SGX components gets added into a Filesystem. For more details,

  • Prepare the root filesystem
   Follow the steps below to populate the Android filesystem.

   #> sudo ../../../../build/tools/ ../../../host/linux-x86/bin/fs_get_stats android_rootfs . rootfs rootfs.tar.bz2

   The rootfs.tar.bz2 is the android filesystem, it can be put on a SD/MMC Card or used our NFS.

ADB Android Debugger & Downloader

Android Debug Bridge (adb) is a versatile tool lets you manage the state of the Android-powered device. For more information about what is possible with adb, see Android Debug Bridge page at The ADB tool can be used to

  • Download an application from a host machine, install & run it on the target board.
  • Start a remote shell in the target instance.
  • Debug applications running on the device using the debugging tool DDMS ( Dalvik Debug Monitor Server) which runs on top of adb connection.
  • Copy files to and from the board to host machine

Downloading “ADB” & Host setup

The adb tool is a part of Android SDK package located at For an overview of how to install and set up the Android SDK, follow download & setup instructions from Once you install Android SDK, the directory contents look like this.

SDK Readme.txt

The adb tool is located in tools/ directory under the Android SDK installation. Export the tools directory path as shown below.

  $> export PATH=${PATH}:<your_sdk_dir>/tools

Connecting Host machine & board through adb

This release of DevKit has been tested for three different methods of connecting a given board with host machine

  • adb over USB
  • adb over USB Ethernet
  • adb over Ethernet

The below sections describe each of these methods and provides necessary instructions for the same.

adb over USB

  • Make sure that the mini-usb cable is connected between the host usb port and the target’s USB OTG port
  • Turn on “USB Debugging” on your board. On the board (UI screen)-
    • Go to home screen, press MENU,
    • Select Applications, select Development, then enable USB debugging.
    • Alternatively, you can navigate to Settings->Applications->Development and then enable the “USB debugging” option.
  • Setup host machine to detect the board. On Ubuntu Linux host machines this is done by adding a rules file to configure device vendor ID of on-board OMAP device.
  • For the EVMs and Boards covered here, the vendor ID is “18d1”.
    • Log in as root and create this file: /etc/udev/rules.d/51-android.rules
    For Gusty/Hardy, edit the file to read:
    SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"

    For Dapper, edit the file to read:
    SUBSYSTEM=="usb_device", SYSFS{idVendor}=="18d1", MODE="0666"
    • Execute the following to change the user mode for the rules file.
    $> chmod a+r /etc/udev/rules.d/51-android.rules
    • Verify the adb connectivity between host and target board
    $> adb devices 

    If device is connected, then output on screen should list the device, example:

       List of devices attached
       20100720    device

adb over USB Ethernet (Ethernet over USB)

  • Make sure that the mini-usb cable is connected between the host usb port and the target’s USB OTG port.
  • Configure the Linux kernel to use Ethernet gadget. Enable USB support, configure the Inventra controller, and add USB gadget support.

IMPORTANT NOTE: Inventra configuration must occur in two places as shown in non-highlighted lines of the screen shots below.

    #> make ARCH=arm CROSS_COMPILE=arm-eabi- menuconfig

Device Drivers — USB Support


Device Drivers — USB Support — USB Gadget Support

Android USBGadget ADB.JPG

Device Drivers — USB Support — USB Gadget Support — Enable Gadget Ethernet support

Android USBEthernet ADB.JPG


  • Build the Kernel with the above configuration changes and use the uImage to boot the board. Refer to Kernel compiling instructions above.
  • Establish network connection
    • Assign an IP address to the usb ethernet adapter.

The USB network gadget g_ether is named usb0 (instead of eth0 or other network interface names). The normal set of Ethernet configuration tools should work, such as ifconfig, netstat, and route.

For example, the following commands will assign the network address to the target. Run this on the target:

    $> ifconfig usb0 netmask up

On Host machine, run the following commands to establish the connection to the target:

    $> sudo ifconfig usb0 netmask up
    $> sudo route add dev usb0

The target and the host machine should be connected, run ping command to test the same:

    $ ping -c 3
    PING ( 56(84) bytes of data.
    64 bytes from icmp_seq=1 ttl=64 time=6.08 ms
    64 bytes from icmp_seq=2 ttl=64 time=0.511 ms
    64 bytes from icmp_seq=3 ttl=64 time=0.485 ms
    --- ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms
    rtt min/avg/max/mdev = 0.485/2.361/6.089/2.636 ms
  • Establish ADB connection

On the host machine execute following commands to establish adb connection

    $ export ADBHOST=<target's ip address>
    $ adb kill-server
    $ adb start-server

Verify the connection by executing

    $ adb devices

If connected, device name should be listed as a “emulator”

    $ adb devices
    List of devices attached
    emulator-5554    device
    $ adb shell

adb over Ethernet

  • Make sure Ethernet port on board and host machine are connected to the network
  • Check Ethernet configuration for the board
    target #> netcfg                                                                        
       lo       UP       0x00000049                       
       eth0     UP   0x00001043
  • If Ethernet was not configured, configure Ethernet of the board using ifconfig/netcfg as shown below.
    target #> netcfg eth0 dhcp
  • Configure the ADB Daemon to use an ethernet connection using setprop as shown below.
    target #> setprop service.adb.tcp.port 5555


  • If network is configured successfully (above steps) then Restart service adbd on the target,
    target #> stop adbd
    target #> start adbd
  • On the host machine use following commands to establish adb connection
    $> export ADBHOST=<target's ip address>
    $> adb kill-server
    $> adb start-server
  • Verify for device connectivity, by executing the following commands
    $> adb devices If connected, you'll see the device name listed as a "emulator"

    $> adb devices

    If connected, find the device name listed as a "emulator"

    List of devices attached
    emulator-5554    device
    $ adb shell

For more information about adb commands, see Android Debug Bridge page at

adb over USB on Windows Machine

Follow the below instructions to get ADB over USB work on a Windows PC

  • Download latest Android SDK

( and uncompress it in a local folder (i.e. c:\android_sdk).

  • Optionally, you may want to add the location of the SDK’s primary tools directory to your system PATH. Right-click on My Computer, and select Properties. Under the Advanced tab, hit the Environment Variables button, and in the dialog that comes up, double-click on Path (under System Variables). Add the full path to the tools\ directory to the path.
  • Download Android USB Driver

( and uncompress it in a local folder (i.e. c:\android_sdk\usb_driver)

  • Edit (or create and then edit if it doesn’t already exist) file in


  echo 0x18D1 > "%USERPROFILE%\.android\adb_usb.ini"
  • Edit android_winusb.inf to match EVM/Beagle vendor and product ids:

Under [Google.NTx86] section add:

  %SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_9018
  %CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_9018&MI_01

Note: Be careful to add it under Google.NTx86 and not under Google.NTamd64 unless your machine is AMD 64 bits. If you skip this step you won’t be able to later install the driver as windows will reject it.

  • Boot the board as normal and wait until shell prompt is available (micro-B USB cable must be disconnected).
  • Connect micro-B USB cable between board and Windows PC.
  • If it is proceeding as planned, Windows will tell you it found a new hardware asks you to install the driver. Install driver that was downloaded as described in step 3 above:

Answer “No, not this time” to the question about running Windows Update to search for software.

    • Choose “Install the hardware that I manually select from a list (Advanced)” this is the 2nd option, then click “Next”
    • Select “Show All Devices”, then click “Next”
    • You are going to see a grayed-out text box with “(Retrieving a list of all devices)”, click the “Have Disk…” button
    • Browse” to your driver folder (c:\android_sdk\usb_driver). It will be looking of a .inf file so select “android_winusb.inf” and click “Open” then “OK”. It’s the only file there so you shouldn’t go wrong.
    • Select “Android ADB Interface” then click the “Next” button.
    • A warning will appear, answer “Yes” but read the warning anyway.
    • Click the “Close” when the wizard is completed.
  • Disconnect and reconnect micro-B USB cable from Board(probably reboot it as well).
  • Open command prompt and restart adb server just to make sure it is in a proper state:
  adb kill-server
  adb start-server
  • List the attached devices with “adb devices”. It should show your board/device with a random number.
  • Type “adb shell”. You should see the “#” indicating it works.

Running Applications

The root File System provided in this DevKit releases contains only standard Android components and applications. User might be interested to download & run android applications (.apk) available in the market. The below procedure gives the steps to be followed to download any .apk file to the board and run it on the platform.

Installing (.apk files) application on Target Platform

  • From the host: You can use adb tool for package installation.
    $> adb install <package>.apk.

NOTE: Use -s option with the adb tool, to install the package on external storage.

On successful installation adb tool will report SUCCESS on host terminal, and the application would be listed on the android main menu.

Un-installing applications (.apk) using adb

  • To un-install non-default components (that were installed later)
    • Method 1: On the host machine execute the following
    $> adb uninstall <package>.apk
    • Method 2: On target:
    Main menu -> Menu -> Settings -> Applications -> Manage applications -> Find the package 
    Tap on it -> Uninstall -> OK -> OK
    • On successful removal, the application would have been removed from the android main menu. All the short-cuts to the application also removed.
  • To un-install default components, use the following commands from abd on host machine
    $ adb shell
    #rm /system/app/app.apk

On successful removal, the application would have been removed from the android main menu.

Setup ADB for application Debugging

ADB and Eclipse, with ADT( Android Development Tools plug-in) allow users to create and debug Android applications. Follow Developing In Eclipse, with ADT at

Steps to connect Eclipse to the board.

  • Setup the adb connection with the board by following the instructions given above in connecting board …
    Verify the connectivity by executing 
    $ adb devices
  • Open Eclipse IDE. Eclipse, with ADT plugin enable users to
    • Create an android project.
    • Build and Run the project on a connected board.
    • Debug the project using the Debug perspective.
    • Use DDMS (Dalvik Debug Monitor Server) to monitor the connected board.

For more detailed and complete information on the above follow Developing In Eclipse, with ADT at

  • Open DDMS(Dalvik Debug Monitor Server) perspective. This DDMS perspective can be opened from the eclipse menu via:
    Window -> Open Perspective -> Other -> DDMS; 
    Click on OK
  • DDMS provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information,incoming call and SMS spoofing, location data spoofing, and more.

Copy any files to and from the board over ADB

  • Using the adb commands “pull” and “push” user can copy files to and from the board.
  • Unlike the install command, which only copies an .apk file to a specific location, the pull and push commands let you copy arbitrary directories and files to any location on the board.
  • To copy a file or directory (recursively) from the board, use
    adb pull <remote> <local>
  • To copy a file or directory (recursively) to the board, use
    adb push <local> <remote>

In the commands, <local> and <remote> refer to the paths to the file or directory on your development host (local) and on the target instance (remote).

    Here's an example: 
    adb push foo.txt /sdcard/foo.txt

Adobe Flash 10 Integration

The Android version of Flash10 that runs on Froyo is now available for customer download (by registration) at,

The below steps give the procedure to download the Adobe Flash 10 library for Android FroYo and installing the same in File system.

  • Execute the installer
  #> ./ Flash10.1_Android_Webkit_Plugin-0.4-Linux-x86-Install.bin
  Will result in following instruction, press "Y" 

  This will install Flash10.1 Android Webkit Plugin on your computer.  Continue? [n/Y] Y
  Select the source install location
  Where do you want to install Flash10.1 Android Webkit Plugin? 
  [/home/user/flash10_androidplugin] /home/user/flash10_androidplugin

  Installing Flash10.1 Android Webkit Plugin...
  Installing Program
  Installation complete.
  After Installation the following directory structure is resulted
  • Change to Flash installed directory on Host PC
  #> cd flash10_androidplugin 
  #> ls
  install_flash_player.apk  uninstall
  • Install flash player plug in on target via adb
 #> adb install install_flash_player.apk
  • Do the browser configuration
    • Explained in the below section

Compatibility Test Suite (CTS)

This section describe the procedure to run CTS on any platform.

  • Pre-requisites
  • Setup an ADB connection between Host and platform as mentioned in ADB section above.
  • Setup your platform to run the accessibility tests:
    • adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk
    • On the device enable Settings > Accessibility > Accessibility > Delegating Accessibility Service
  • Launch the CTS.
    • Edit android-cts/tools/startcts to point SDK_ROOT to android sdk installation location.
    • Run ./tools/startcts
    • On CTS prompt check the available plans
  cts_host > ls –plan
    • Start a specific Test Plan
  cts_host > start --plan <plan name>

Once all the tests are executed, the results can be browsed in an browser by opening [android-cts/repository/results/session-name/testResult.xml] and use the results to adjust your design.

  • NOTE: Sometimes when CTS is restarting the board, adb connection to CTS, may not happen automatically. In that case, execute the following command on the console, soon after the board has restarted.
  #> stop adbd;sleep 1;start adbd;

Configuring Android Applications

Browser Configuration

To browse web pages user should configure the Internet connection as given below.

    #> netcfg eth0 dhcp
    #> getprop net.eth0.dns1

This prints the dns for the ethernet port, do the following to configure the DNS entries on board.

    #> setprop net.dns1 <your_dns_server_ip>

If the platform is behind proxy, then following command should be executed to set the proxy settings

    #> setprop net.gprs.http-proxy http://proxyurl:80

NOTE: If network is behind a proxy, in this DevKit release, we have NOT found a method to set the proxy server. We tried using “setprop net.eth0.http-proxy hostname:port” and “setprop net.gprs.http-proxy hostname:port”, but neither could get us through the proxy. Also, the option of adding an entry of (99,’http_proxy’,’hostname:port”) to the ‘system’ and ‘secure’ tables in the /data/data/ database has also been tried, but failed.

USB Mass Storage

The Android FroYo 2.2 supports USB Mass storage functionality, however the external storage can be mounted either on SD Card or a USB mass storage device. The user is allowed to choose one of the two options.

By default the TI Android DevKit chooses SD card as the external storage device.

If a user is interested to use storage over USB (USB mass storage) then following changes have to be done in the default root filesystem

1)Create some directory on Android Filesystem via adb shell or console

   # mkdir /partition

2) Insert the usb mass storage device, Assume the device node created at /dev/block/sda1 and the device has fat partition.

   #mount –t vfat /dev/block/sda1 /partition

3) Now usb mass storage device is mounted at /partition. You can careate browse the filr

Limitation 1) Auto mounting usb mass storage device not supported 2) The gallery app/Android Settings doesn’t recognize the mass storage mounted


SD Card Recommendations

Some brands or models of SD cards are observed with poor performance on DM37x EVMs and other platforms. The symptom could be one or some of the followings.

  • the boot-up time is much longer than normal (3x of normal or even longer);
  • the reaction of UI operations is unacceptably delayed;
  • the Gallery app cannot find the media files to create the albums;
  • the video playback is sluggish.

The table below lists the SD cards tested which have no issue on performance.

Brand/Model Type Class Capacity
Sandisk-C4-4GB.jpg SanDisk SDHC 4 4GB
Sandisk-ultra-C4-16GB.jpg SanDisk Ultra SDHC 4 4GB
Sandisk-ultra-C4-16GB.jpg SanDisk Ultra SD 4 2GB
SONY-C4-4GB.jpg Sony SDHC 4 4GB
SONY-C4-2GB.jpg Sony SD 4 2GB
SONY-micro-C4-4GB.jpg Sony micro SDHC 4 4GB

The table below lists the SD cards tested which have poor performance.

Brand/Model Type Class Capacity
HP Invent SDHC 4 4GB
Kingston SDHC 4 4GB
Kingston-C4-4GB.jpg Kingston micro SDHC 4 4GB
Lexar-Multi-Use-C4-4GB.jpeg Lexar MULTI-USE SDHC 4 4GB
Lexar-PlatinumII-C6-4GB.jpeg Lexar PLANTINUM II SDHC 6 4GB
PNY-Optima-C4-4GB.jpg PNY Optima SDHC 4 4GB



This is Release DevKit-V2.2 The release is available from
The release notes is available at

Technical Support and Product Updates

For further information or to report any problems, contact or
For community support join
For IRC #rowboat on




Development Boards Android

Posted: February 25, 2011 in Android, Embedded System

Mini6410/S3C6410 Embed System processor board Android/WinCE/Linux OS + 7 inch touch screen (800*480)

mini6410 7inch 2

FriendlyARM Mini 6410 SBC (Single-Board Computer) with 533 MHz S3C6410 CPU board ARM11 processor. The board measures 11 cm x 11 cm, ideal for learning about ARM systems.



  • Dimension: 110 x 110 mm
  • CPU: 533 MHz S3C6410A ARM1176JZF-S (max freq. 667 MHz)
  • RAM: 128 MB DDR RAM, 32 bit Bus
  • Flash: 256 MB / 1GB NAND Flash
  • EEPROM: 1024 Byte (I2C)
  • Ext. Memory: SD-Card socket
  • Serial Ports: 1x DB9 connector (RS232), total: 4x serial port connectors
  • IR: Infrared Receiver
  • USB: 1x USB-A Host, 1x miniUSB Slave-OTG 2.0
  • Audio Output: 3.5 mm stereo jack
  • Audio Input: Condenser microphone
  • Ethernet: RJ-45 10/100M (DM9000)
  • RTC: Real Time Clock with battery
  • Beeper: PWM buzzer
  • Camera: 20 pin Camera interface (2.0 mm)
  • TV Output: CVBS
  • LCD Interface
    • STN Displays:
      • Monochrome, 4 gray levels, 16 gray levels, 256 colors, 4096 colors
      • Max: 1024×768
    • TFT Displays:
      • Monochrome, 4 gray levels, 16 gray levels, 256 colors, 64k colors, true color
      • Max: 1024×768
    • 40 pin (2.0 mm) and 41 pin connector for FriendlyARM Displays (4.3″ and 7″)
  • Touch Panel: 4 wire resistive
  • User Inputs: 8x push buttons and 1x A/D pot
  • User Outputs: 4x LEDs
  • Expansion: 40 pin System Bus, 30 pin GPIO, 20 pin SDIO (SD, SPI, I2C), 10 pin Buttons (2.0 mm)
  • Debug: 10 pin JTAG (2.0 mm)
  • Power: 5V connector, power switch and LED
  • Power Supply: regulated 5V (Mini6410: 0.25 A, Mini6410 + 4.3″ LCD: 0.5 A)
  • OS Support
    • Windows CE 6
    • Linux 2.6
    • Android
    • Ubuntu

Mini6410 7inch TFT

Mini6410/S3C6410 Embed System processor board Android/WinCE/Linux OS + 7 inch touch screenMini6410/S3C6410 Embed System processor board Android/WinCE/Linux OS + 7 inch touch screen

DevKit8000 OMAP3530 Evaluation Kit

– TI OMAP3530 Processor based on 600MHz ARM Cortex-A8 core
– Memory supporting up to 256MByte DDR SDRAM and 256MByte NAND Flash
– UART, USB OTG, Ethernet, Audio, SD/MMC, Keyboard, Jtag,…
– Supports 24-bit TFT LCD, DVI-D and TV S-Video Output Display
– Supports VGA, Camera, WiFi, GPS, GPRS, 3G Functions through Modules
– Ready-to-Run Linux2.6 and WinCE 6.0


DevKit8000 Evaluation Board

The Texas Instruments’ OMAP3530 is a high-performance processor based on the enhanced OMAP™ 3 architecture. It includes many internal subsystems designed to support high-speed, multi-thread processing applications. The OMAP3530 includes an integrated advanced Superscalar ARM Cortex-A8 core, an IVA2.2 subsystem with a C64x+ digital signal processor (DSP) core, 2D/3D graphics accelerator, display subsystem, a camera ISP (Image Signal Processor), and high-performance system interconnects and industry-standard peripherals. The device includes state-of-the-art power-management techniques required for high-performance mobile products and supports high-level operating systems such as Windows CE, Linux, Symbian OS and Palm OS.

Embest DevKit8000 Evaluation Board is a compact board using OMAP3530 microprocessor. It takes full features of this processor and supports up to 256MByte DDR SDRAM and 256MByte NAND Flash as well as high-speed USB2.0 OTG function. The board has exposed many other hardware interfaces including RS232 serial port, LCD/TSP, DVI-D, S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C and JTAG. The board has two methods to boot the system from either SD card or NAND flash. It is able to support WinCE and Linux OS and provided with WinCE6.0 BSP and Linux2.6.28 BSP. Embest also provides demos of Google Android OS,Angstrom (GPE) and DVSDK for user experience.

Embest DevKit8000 Evaluation Kit includes the DevKit8000 evaluation board and all necessary accessories to help users start their design of multimedia applications. The board is preloaded with Linux OS in NAND flash and WinCE OS in SD card. User can display the subsystem using a 4.3″ TFT LCD and Touch screen or using a DVI-D monitor through an HDMI to DVI-D calbe, or using TV for NTSC/PAL video out. The USB OTG interface can also be used as USB Host function with a Mini-A to Standard-A cable, or used as USB Device function with a Mini-B to Standard-A cable. The board has audio and video codecs, with the help of DSP, H.264, MPEG4, CIF, and D1 media formats all can be supported. Along with the kit, Embest provides user manual, schematic drawing and datasheet documents to help customers better understand and use the kit.

Additionally, Embest offers various modules for Devkit8000 including VGA (VGA8000), WiFi (WF8000-U), Analog Camera (CAM8000-A), GPS (GPS8000-S), GPRS (GPRS8000-S), 3G (CDMA8000-UWCDMA8000-U) and Digital Camera (CAM8100-U) modules which greatly extends the functions of the board and would be flexible for customer selection to meet their own needs.

Hardware Features

  • Dimensions: 110mm x 95mm
  • Working temperature: 0°C to 70°C
  • Processor: TI OMAP3530 microprocessor with 600MHz ARM Cortex-A8 RISC Core
  • Power supply: +5V
  • 256MB DDR SDRAM, 166MHz
  • 256MB NAND Flash, 16bit
  • LCD/Touch Screen interface (50-pin FPC connector, support resolution up to 2048*2048)
  • DVI high-resolution image output port (HDMI interface, support 720p, 30fps signal)
  • S-Video display interface
  • One audio input interface (3.5mm audio jack)
  • One 2-channel audio output interface (3.5mm audio jack)
  • One 10/100M Ethernet interface (RJ45)
  • One High-speed USB2.0 OTG port (Mini USB type interface)
  • One High-speed USB2.0 Host port (USB A type interface)
  • Two serial ports (one 3-wire RS232 serial port led out from 2.54mm 10-pin connector and one 5-wire TTL serial port led out from expansion connector)
  • SD/MMC interface (supports 3.3V and 1.8V logic voltage)
  • One camera interface (30-pin FPC connector, support CCD or CMOS camera)
  • 6*6 keyboard interface
  • One 14-pin Jtag interface
  • Four buttons (Reset, Boot, User defined, On/Off)
  • One expansion connector (2.0mm 40-pin SMT Female Pin Header, McSPI, McBSP, I2C, HDQ, GPIO are led out from this connector)

Add-on Hardware Options

Item Description Interface to Devkit8000 Linux WinCE
VGA8000 VGA Module LCD Support Support
CAM8000-A Analog Camera Module Camera Support Not Support
WF8000-U WiFi Module USB Host Support Support
GPS8000-S GPS Module UART Support Support
GPRS8000-S GPRS Module UART Support Support
CDMA8000-U 3G Module
(CDMA2000 standard)
USB Host Support Support
WCDMA8000-U 3G Module
(WCDMA standard)
USB Host Support Support
CAM8100-U Digital Camera Module USB Host Support Support
XDS100v2 Emulator for debugging JTAG
TDS560 Emulator for debugging JTAG

Software Features

OS Item Feature Description
Linux Boot Version X-loader-1.41 U-boot 1.3.3
Boot Mode Boot Linux from SD card, NAND Flash or Ethernet
Image update Support updating image from SD card or Ethernet
Kernel and drivers Version Linux 2.6.28
Driver Serial, RTC, NET, Nand, LCD, Touch Screen, MMD/SD, USB OTG, DVI, Keypad, LED, Audio
File System File System Format Ramdisk File System, UBI File System
Function Provided Lib (ALSA -lib, tslib, glibc), udev support
Demo Angstrom Audio (XMMS), network (firefox), graphics editor (gimp) and document processing software (Abiword)
Android Google developed a platform based on Linux open-source mobile phone operating system.
DVSDK Support MPEG4, MPEG2, H264, mp3, aac audio/video formats and Codecs
WinCE Boot Version x-load-1.41, eboot
Boot Mode Boot WinCE from SD card, NAND Flash or Ethernet
Image update Support updating image from SD card or Ethernet
System Characteristic KITL kernel debug, Reboot, Watchdog, RTC
Driver display driver(DVI, TFT LCD)
SD card, Keyboard, McSPI, McBSP, Audio, NET, NLED, USB OTG, WiFi, GPS, GPRS, CDMA
Function Power Management (backlight drive, battery-driven, sleep/wake-up function)
Hive registry support
ROM file system support
Software features Mediaplayer 9.0, Word and Internet Explorer 6.0
.NET Compact Framework 3.5

Onboard Interfaces and Connectors

Relative Documentation and Links

DevKit8000 Evaluation Kit Overview

TI OMAP3530 datasheet

Dimension drawing of Devkit8000 board

Devkit8000 FAQ

XDS100v2 USB JTAG Emulator

TDS560 USB-Plus JTAG Emulator

Customer Design Service

Embest also offers customer design service based on the Devkit8000 board according to customer’s requirement. Whether you need to reduce, add or modify to existing hardware, Embest will help customers with expert competence and rich experience.

Order Information

Order No. T6010074
Item Embest DevKit8000 Evaluation Kit (Standard Configuration)
  • One DevKit8000 Evaluation board
  • One 512MB SD card
  • One Serial cable (IDC10-to-DB9)
  • One 5V@2A Power adapter
Software and Documents
  • Documents (user manual, schematic drawing, Datasheet)
  • 6.0 BSP
  • Linux 2.6.28 BSP
Price US$169 (256MB+256MB memory)
Order No. T6010075
Item Embest Devkit8000 Evaluation Kit (Complete Configuration)
  • One DevKit8000 Evaluation board
  • One 4.3” LCD (With Touch panel, we provide 7″LCD for options, please add US$20 for choosing 7″LCD)
  • One 512MB SD card
  • One Serial cable (IDC10-to-DB9)
  • One 5V@2A Power adapter
  • One Touch Pen
  • One USB cable (Type A Male to Type Mini-B Male)
  • One USB cable (Type A Female to Type Mini-A Male)
  • One USB HUB
  • One Cross Ethernet cable
  • One HDMI to DVI-D cable
  • One S-Video cable
    Remark: 4.3”LCD (resolution: 480*272), 7″LCD (resolution: 800*480)
  • Documents (user manual, schematic drawing, Datasheet)
  • 6.0 BSP
  • Linux 2.6.28 BSP
Price US$279 (256MB+256MB memory)
Order online Buy Now
P.O Print the order form, complete and fax to us. Also fax your T/T receipt. We will deal with your order once we receive your orderform and T/T receipt.
Order form in pdf Order form in MS word
Other TI Series Products

Instruction Pipeline

Posted: February 13, 2011 in Embedded System


An instruction pipeline is a technique used in the design of computers to increase their instruction throughput (the number of instructions that can be executed in a unit of time). The main reason for pipelining instructions is that it allows some operations to be carried out in parallel. We haven’t increased the execution speed at which one instruction is executed, what we have done is increased the throughput by allowing a number of tasks to execute simultaneously. Since computers execute billions of instructions it’s throughput that matters.

These are the steps that need to be carried out when a microprocessor executes an instruction:

  1. Fetch the instruction (instruction fetch phase)
  2. Decode the instruction (decode phase)
  3. Where necessary, fetch the operands (operand fetch phase)
  4. Execute the instruction (execute phase)
  5. Write back the result (write-back phase)


  • Now to understand the pipelining process more easily, combine the stages 3 and 4.

  1. The instruction Fetch (IF) stage is responsible for obtaining the requested instruction from memory and is stored it in buffer as temporary storage.
  2. The Instruction Decode (ID) stage is responsible for decoding the instruction and sending out the various control lines to the other parts of the processor.
  3. The Execution (EX) stage is where any calculations are performed. The main component in this stage is the ALU.
  4. The Write Back (WB) stage is responsible for writing the result of a calculation, memory access or input into the register file.

The top gray box is the list of instructions waiting to be executed; the bottom gray box is the list of instructions that have been completed; and the middle white box is the pipeline.

Execution is as follows:

Time Execution
0 Four instructions are awaiting to be executed
  • the green instruction is fetched from memory
  • the green instruction is decoded
  • the purple instruction is fetched from memory
  • the green instruction is executed (actual operation is performed)
  • the purple instruction is decoded
  • the blue instruction is fetched
  • the green instruction’s results are written back to the register file or memory
  • the purple instruction is executed
  • the blue instruction is decoded
  • the red instruction is fetched
  • the green instruction is completed
  • the purple instruction is written back
  • the blue instruction is executed
  • the red instruction is decoded
  • The purple instruction is completed
  • the blue instruction is written back
  • the red instruction is executed
  • the blue instruction is completed
  • the red instruction is written back
  • the red instruction is completed
9 All instructions are executed

 BUBBLE: Occurred due to delay in instruction fetching. Bubbles are like stalls, in which nothing useful will happen for the fetch, decode, execute and writeback.

In cycle 2, the fetching of the purple instruction is delayed and the decoding stage in cycle 3 now contains a bubble. Everything “behind” the purple instruction is delayed as well but everything “ahead” of the purple instruction continues with execution.

Clearly, when compared to the execution above, the bubble yields a total execution time of 8 clock ticks instead of 7.


n  Inability to continuously run the pipeline at full speed because of pipeline hazards which disrupt the smooth execution of the pipeline.

Pipeline Hazards

Pipeline hazards are situations that prevent the next instruction in the instruction stream from executing during its designated clock cycle.

Types of hazards:

  1. Structural hazards
  2. Data hazards
  3. Control hazards

Structural Hazards:  Two instructions need to access the same resource.

Control Hazards: The location of an instruction depends on previous instruction

Data Hazards: An instruction uses the result of the previous instruction.


Posted: February 11, 2011 in Embedded System

A hard disk drive (HDD) is a non-volatile, random access device for digital data. Hard disk drives have been the dominant device for secondary storage.

  1. Introduced by IBM in 1956
  2. Hard disk drives have fallen in cost and physical size over the years while dramatically increasing in capacity.
  3. Average access time decreasing from greater than 0.1 second to a few thousandths of a second

Seek time is a measure of the speed with which the drive can position its read/write heads over any particular data track.

Access time is simply the sum of the seek time and the latency.

Once over the data track, the heads must not write the data until the selected free sectors on that track pass beneath the head. This time is related to the rotation speed of the disk: the faster the speed, the shorter this “latency” period.

A HDD design consists of a spindle which holds one or more flat circular disks called platters, onto which the data is recorded. The platters are made from a non-magnetic material, usually aluminum alloy or glass, and are coated with a thin layer of magnetic material. The platters are spun at very high speeds. The platters rotate at up to 10,000 revolutions per minute (rpm) so the read-write heads can access any part of them. Information is written to a platter as it rotates past devices called read-and-write heads that operate very close (tens of nanometers in new drives) over the magnetic surface. The read-and-write head is used to detect and modify the magnetization of the material immediately under it. The head is mounted on an arm. An actuator arm (or access arm) moves the heads on an arc across the platters as they spin, allowing head to access almost the entire surface of the platter as it spins. The arm is moved using a stepper motor.


The data is stored digitally as tiny magnetized regions, called bits, on the disk. A magnetic orientation in one direction on the disk could represent a “1”; an orientation in the opposite direction could represent a “0”. Magnetism is used in computer storage because it goes on storing information even when the power is switched off.

The science of magnetism is complex. But if you’ve ever fooled around with a magnet and some nails, you’ll know that the technology. Iron nails start off unmagnetized but, if you rub a magnet back and forth over them, you can make them magnetic so they stick to one another.

If your computer has a 20 gigabyte (GB) hard drive, it’s a bit like a box containing 1.6 million microscopically small irons nails, each of which can store one tiny piece of information called a bit. Suppose you want to store the number 1000001 in your computer in that big box of iron nails. You need to find a row of seven unused nails. You magnetize the first one (to store a 1), the next five demagnetized (to store five zeros), and magnetize the last one (to store a 1).

In your computer’s hard drive, there aren’t really any iron nails. There’s just a circular “plate called a platter. The data is stored in a very orderly pattern on each platter. Bits of data are arranged in concentric, circular paths called tracks. Each track is broken up into smaller areas called sectors. Part of the hard drive stores a map of sectors that have already been used up and others that are still free. (In Windows, this map is called the File Allocation Table or FAT)

All magnetic storage devices read and write data by using electromagnetism. This basic principle of physics states that as electric current flows through a conductor (wire), a magnetic field is generated around the conductor. The magnetic field generated by a wire conductor can exert an influence on magnetic material in that field. When the direction of the flow of electric current or polarity is reversed, the magnetic field’s polarity also reversed. Another effect of electromagnetism was that if a conductor is passed through a moving magnetic field, an electrical current is generated. As the polarity of the magnetic field changes, so does the direction of the electric current’s flow.

Each of the individual magnetic particles on the storage medium has its own magnetic field. When the medium is blank, the polarities of those magnetic fields are normally in a state of random disarray. Because the fields of the individual particles point in random directions, each tiny magnetic field is canceled out by one that points in the opposite direction; the cumulative effect of this is a surface with no observable field polarity. With many randomly oriented fields, the net effect is no observable unified field or polarity.

The read/write heads in a magnetic storage device are conductors, with the ends directly above the surface of the actual data storage medium (Platter). The head is wrapped with coils or windings of conductive wire, through which an electric current can flow. When a current flows through these coils, it generates a magnetic field in the drive head. As this field passes through the medium directly under the head, it polarizes the magnetic particles it passes through so they are aligned with the field. When the individual magnetic domains of the particles are in alignment, they no longer cancel out one another, and an observable magnetic field exists in that region of the medium. Reversing the polarity of the electric current causes the polarity of the generated field to change also. So the field of the magnetic medium also changes.

The polarity or direction of the field induced in the magnetic medium is based on the direction of the flow of electric current through the coils.

When a command is made to read some data on a disk, a similar process occurs in reverse. After consulting the table of stored data locations in the drive’s electronics, the actuator moves the head over the track where the chosen data is located. When the correct sectors pass beneath the head, the magnetic fields from the bits (domain) cause currents to flow through the head. The current variations are then detected and decoded to reveal the data that had been stored on the disk.

ARM9 Processor Family

Posted: January 20, 2011 in Embedded System

ARM9 Processor Family

ARM9 Processor Family Image
The ARM9™ processor family enables single processor solutions for microcontroller, DSP and Java applications, offering savings in chip area and complexity, power consumption, and time-to-market.The ARM9 DSP-enhanced processors are well suited for applications requiring a mix of DSP and microcontroller performance.

The ARM9 processor family includes ARM926EJ-S™ARM946E-S™ and ARM968E-S™ processors.



The ARM9 family includes the ARM968E-S, the ARM946E-S and the ARM26EJ-S processors.


Smallest footprint ARM9 processor with DSP enhancements, for low power, data intensive, embedded real-time applications

The smallest and lowest power ARM9 processor is ideal for many real time type applications. The processor operates efficiently from the Tightly Coupled Memory that can easily be integrated through standard interfaces.


DSP enhanced cached processor with an MPU for real-time applications running an RTOS

A real time orientated processor with optional caches interfaces plus a full Memory Protection Unit. This processor is useful in applications where the majority of code exists in main memory, and is loaded into cache on demand, while key exception handing code and data can be maintained locally in Tightly Coupled Memory.


Application processor with Java acceleration, DSP extensions and an MMU, for OS based applications

The ARM926EJ-S is the entrypoint processor capable of supporting full Operating System including Linux, WindowsCE, and Symbian. As such this processor is ideal for many applications requiring a full Graphical User Interface.

ARM9 family processor naming – ARM9xxE(J)-S

  • E – DSP extensions
    • Enhanced instructions for efficient fractional saturating arithmetic
    • Single cycle 32×16 multiplier implementation
    • 32×16 and 16×16 multiply instructions
    • Count leading zeros instruction
  • J  – Java acceleration through Jazelle
    • Embedded Jazelle hardware acceleration Java performance of ~1300CM @ 220MHz
    • Reduced complexity & power consumption over a typical Java hardware coprocessor solution
    • Available on the ARM926EJ-S processor only
  • S  – Fully synthesizable  

ARM9 family processor comparison of key features

 ARM9 Family Comparison

For more details on the comparative features of ARM9 family processors, you can also use the Processor Selector.

Migrating to Cortex

The ARM9 family has a robust roadmap linking to the latest ARM Cortex processors. The Cortex-A and Cortex-R families provide powerful, feature-rich options for easy migration of ARM9 designs to the next generation.

ARM9 Family Processor ARM Cortex Family Alternative  Processor Comparison
 ARM968E-S  Cortex-R4 Compare ARM968E-S with Cortex-R4
 ARM946E-S  Cortex-R4 Compare ARM926EJ-S with Cortex-R4
 ARM926EJ-S  Cortex-A5 Compare ARM926EJ-S with Cortex-A5 using the Processor Selector


Latest Forum Posts
Go Left
(34/58) Konica Minolta Magicolor 5440 Printer