User Tools

Site Tools


gumstix_overo_with_android

Gumstix Overo - OMAP35xx with Android

The geek in me got the better of me, once a ham friend pointed me to Gumstix and its amazingly tiny SOC, I had to buy a Overo Air with a Palo35 board & LCD. It ships with an microSD and a prebuilt embedded Linux, but once I got tired of playing with the precanned software, the moment came: now what? How about running Android on this hardware and gain a nice platform for future radio projects?

Setting up for Android platform development

The AOSP (Android Open Source Project) page has a decent writeup on how to get a basic development environment setup and how to get the public Android source repository. AOSP - Setting up your machine or my own steps of setting up Debian.

Most available tool chains and sources assume to be hosted on Linux, including the Android source tree. The Android platform source tree is being developed on Ubuntu, but I prefer its foundation, Debian 6.0. Note that the Android folks recommend a 32bit host OS for now. Also, since this was one of my first experiments with Linux/Unix in more than a decade, I chose to stick with a Desktop edition as well (at work, I prefer to run my dev box on a WS2008R2 x64 OS).

Please also familiarize yourself with the concept of an Android Repository: it is essentially a collection of Git repositories (called “projects”). It is described in a manifest and can be managed by a repo shell script.

Existing OMAP3 specific sources

The ASOP tree has general support for OMAP processors but has no specifics for the Overo board hardware.

There are several projects that pursue running Android on OMAP-based boards, most notably OMAPedia.org. It offers binary releases and nicely detailed notes on how to build & install, see http://omappedia.org/wiki/L27.INC1.5.2_Froyo_ES2_Release_Notes. But that project doesn't target the Overo boards yet, instead the source has configurations for the omapZOOM.

The general process on how to adapt Android to a OMAP board can be found here:

More Linux to OMAP3 platforms:

MentorGraphics drives also an adaption of OMAP3x to Android, called rowboat. Note that its tree is mainly focused on Eclair, with some work underway for Froyo: Its Git repository is: http://gitorious.org/rowboat

The project/repo manifest for that Git repo is here, it has variants for Eclair and Froyo: http://gitorious.org/rowboat/manifest

That repo also contains a set of OMAP3 specific support projects, e.g.:

Setting up an Overo OMAP3 dev tree

TODO

Toolchains and dev environment

To cross-compile for the Overo board, a ARM Gnu CC toolchain is necessary. The http://omappedia.org project is using the gcc release from CodeSourcery: http://codesourcery.com/sgpp/lite/arm/portal/release858. In principle one could compile the gcc toolchain from the gcc source code, but this is not really for the faint of heart. I “fondly” remember the labor to bring up a 1.x gcc toolchain for Interactive Unix that we needed at a previous employer's project more than 15 years ago… So I leave this exercise to a later time.

Download the arm-none-linux-gnueabi version and untar it to e.g. /opt/arm-2009q1.

I like having a shell script that creates the necessary environment variables I need to compile & debug, e.g. a file ~/myenv that I can easily source. Add the following 2 lines to that script to have the toolchain available from the different source projects:

export CROSS_COMPILE=arm-none-linux-gnueabi-
export PATH=/opt/arm-2009q1/bin:${PATH}

Bootloaders

To boot the Android OS, bootloaders are necessary. The Overo comes with a microSD drive which can be used to boot. The Android repo manifest does not include bootloader images for the Overo board. There is general info on how to build the bootloaders on OMAPpedia.org. Since Android is based on Linux, Overo bootloaders can be used. Gumstix does provide a source of bootloaders with the proper board configuration for its embedded Linux:

More info:

Bootsequence

reset vector –> X-Loader –> u-boot –> kernel –> Android system

The X-loader is called from the reset code in the OMAP3 ROM. The x-loader's purpose in life is to initialize and configure just enough of the CPU and board to be able to load the universal boot loader (aka u-boot or Das U-Boot.

Once the the u-boot is loaded, the board becomes interactive to the developer. u-boot has a simple prompt & command line that a dev can connect to via USB and execute simple scripts (e.g. setting boot command arguments, loading file images and copying to the local flash memory etc.) The u-boot will then load and uncompress the kernel and call into it. Once the kernel is started, u-boot (and x-loader) disappear, their job is done.

TODO: startup of Android system

Build boot loaders for Overo

get source code for x-loader and u-boot

create a bootloader project directory, add a ./out directory for the build results and clone the two git remote repositories:

mkdir ~/prj/overo-bootloader
cd ~/prj/overo-bootloader
mkdir out
git clone git://www.sakoman.com/git/x-loader.git x-loader
git clone git://www.sakoman.com/git/u-boot.git u-boot

Tool to sign x-load.bin

The OMAP ROM code has fairly strict expectations on the 1st boot program and expects the actual program code to be “signed” with a informational header: the raw binary needs a header with the image size and the load address before the actual image. Commonly that file is named x-load.bin.ift. A utility achieves this:

mkdir ~/overo-bootloader/signGP
cd ~/overo-bootloader/signGP
wget http://beagleboard.googlecode.com/files/signGP.c
gcc signGP.c -o signGP

build x-loader

This source tree has a configuration for the gumstix overo, verify the following directory exists and has the Overo specific sources:

cd ~/overo-bootloader/x-loader
ls board/overo/

Also, make sure you have $PATH and $CROSS_COMPILE setup correctly for make to find the ARM toolchain. Now configure and build:

make distclean
make overo_config
make

This produced a file x-load.bin in the ~/overo-bootloader/x-loader directory. The x-load.bin is a raw binary of the ELF 32bit x-load executable (see objdump -o binary). The next steps will sign and copy it to the out directory:

../signGP/signGP x-load.bin
cp x-load.bin.ift ../out

build u-boot

Switch to the u-boot source directory and confirm the overo board specific code is present:

cd ~/overo-bootloader/u-boot
ls board/overo/

create the configuration and build u-boot:

make distclean
make -O=../out omap3_overo_config
make -O=../out

The directory cd ~/overo-bootloader/out now holds the 3 binaries we're interested in:

~/overo-bootloader/out/x-load.bin.ift the first loader raw binary of ELF 32bit, ARM, static linked
~/overo-bootloader/out/u-boot.bin actual bootloader console raw binary of ELF 32bit, ARM, static linked
~/overo-bootloader/out/tools/mkimage tool needed to create Linux kernel ELF 32bit, i386, dyn. linked

The first 2 binaries will get copied onto the boot microSD, the last tool, mkimage, will be needed to further process the actual Linux kernel

Prepare microSD

Partition the SD card

The microSD needs to be configured with a geometry and disk partition scheme that can be understood by the OMAP ROM code.

Insert microSD into USB card reader and plug in. Usually (at least on Ubuntu desktop), the SD card drive gets auto-mounted. A typical mount point is under /media/… Determine the device by running mount to list all mounted devices, look for /media and check its device designation, e.g. /dev/sdd1 This means that /dev/sdd is the raw device that needs to be configured with fdisk:

sudo umount /dev/sdd1
sudo fdisk /dev/sdd

Start out by clearing any previous partition data: execute command 'o' Print the device data with command 'p' Pick the card's size in bytes and calculate the new geometry, based on fixed values for 255 heads and 63 sectors per track:

parameter new value
Heads 255
Sectors 63
Cylinder (size) % (255 * 63 * 512)

note that '%' means modulo divison, i.e. divide and round to next lower integer.

Enter expert mode in fdisk ('x') and set the values for heads, sectors/track and cylinders per above table.

Return to main menu with 'r' and verify the geometry by running command 'p' again.

Time to create 2 new primary partitions, using command 'n'. Change the partition type of partition 1.

partition # size partition type
1 +64M c (W95 FAT32)
2 (default) 83 (Linux)

Also mark partition 1 as bootable, using command 'a'. List all partitions again and if it's correct and complete, write the new partition data to the SD card with command 'w'

Disk /dev/sdd: 4072 MB, 4072669184 bytes
255 heads, 63 sectors/track, 495 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xef4f0bb5

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *           1           9       72261    c  W95 FAT32 (LBA)
/dev/sdd2              10         495     3903795   83  Linux

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

This is described in more detail under Gumstix.net: Create a bootable SD card.

Create file systems on SD card

The SD card needs a FAT and ext2 on the first and second partition, respectively. Be extra careful to double check you have the correct device designation of the SD card and *NOT* e.g. of your host Linux!

sudo mkfs.vfat -n boot -F 32 /dev/sdd1
sudo mkfs.ext2 /dev/sdd2

Copy bootloaders to SD card

Create a mount point, mount the newly created first boot partition and copy the x-loader and u-boot. Note that the x-loader is copied under a different name to the SD card: MLO. Also make sure to copy the MLO file to the fresh card first.

cd ~/overo-bootloader
mkdir /tmp/boot
sudo mount /dev/sdd1  /tmp/boot
sudo cp out/x-load /tmp/boot/MLO
sudo cp out/u-boot.bin /tmp/boot
ls /tmp/boot
sudo umount /tmp/boot

There should be now 2 files on the FAT partition, “MLO” and “u-boot.bin”. Once we have built a kernel, it will be the third file on that partition.

Board bring up

Prerequisites

Install a terminal program on your host Linux, e.g. kermit or minicom:

sudo apt-get install ckermit
sudo apt-get install minicom

In the case of minicom, preconfigure its settings as follows and save as defaults, see also configure minicom:

A Serial Device /dev/ttyUSB0
E Bps/Par/Bits 115200 8N1
F Hardware Flow No

With kermit, on every new session, you'll have to set the following config settings:

set baud 115200
set carrier-watch off
set flow-control none

Boot to u-boot

Insert the SD card into the SD drive on the Overo board and plug in a USB (micro B) to the console USB plug of your gumstix extension board. On your host system, determine the proper device name of the console connection:

ls /dev

. Typically, it is named like: /dev/ttyUSB0

Launch your terminal program and now plugin the 5V board supply

Alternate boot: tftp

gumstix_overo_with_android.txt · Last modified: 2014/11/01 14:14 (external edit)