Android Porting on Devices

Android Tools

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 10:11:00 +0000

http://www.kernel.org/

Kernel Patch work Project List -
http://www.kernel.org/pub/software/scm/git/

Android Glossary -
http://elinux.org/Android_Glossary

Android Kernel Download From eLinux.orgJump to: navigation, search

[edit] Main Google Android Kernels

The main Google repository with Android source code is at: http://android.git.kernel.org/
There are (as of September 2009) 4 main separate kernel repositories at that site:

common
experimental
msm
omap

To download one of these and use it directly, you can use git. For example:

git clone git://android.git.kernel.org/kernel/common.git kernel

To preserve your sanity, it's probably worth downloading this into a 'kernel' directory in your overall Android source directory scheme
You can use repo, following the instructions at http://source.android.com/download, to pull down the entire Android source. However, when you download the rest of the Android source code, using the 'repo' command, you do NOT automatically get a kernel tree included. That is, a kernel git tree is not referenced in the default Android manifest file,
To add projects, such as the kernel, to your overall Android repository scheme, you add the appropriate kernel repository to your local manifest.xml file. This file is located in the .repo directory.
To include the kernel/common tree, include a line like this in .repo/manifest.xml:

<project path="kernel/common" name="kernel/common" />

The complete list of projects (including other kernel options besides kernel/common) is listed on http://android.git.kernel.org/.
Note that the default revision for git repositories is specified in the <default> tag in manifest.xml as "revision=master" but the kernel/common repository may not have a head called "master". In that case if you just type "repo sync kernel/common" you may see the message:

error: revision master in kernel/common not found

Typically the heads in the kernel/common repository will be called android-2.6.x (where x is the kernel number); specifying this number in the manifest should allow repo to sync properly, i.e.:

<project path="kernel/common" name="kernel/common" revision="android-2.6.27"/>

You can view the heads by clicking on the project link from http://android.git.kernel.org/.
For more about repo, see http://source.android.com/download/using-repo

[edit] Other Repositories with Android-specific changes

Linux kernel for omap and beagle-board, by Embinux: http://labs.embinux.org/git/cgit.cgi/repo/kernel.git
- clone with: git clone git://labs.embinux.org/repo/kernel.git kernel

[edit] 'Raw' Android kernel patches

I do not know of any freely available patches for the Linux kernel with the Android fixes, as of November 2009. I have, however, heard of multiple efforts to extract the patches to make it easier to port the Android kernel features onto newer Linux kernels.
Here is a way of extracting raw Android patches at a certain point in time, though this may be dated:

git clone git://android.git.kernel.org/kernel/common.git android-kernel
cd android-kernel
git checkout --track -b android-2.6.32 origin/android-2.6.32
git fetch --tags git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git
git shortlog v2.6.32.9..HEAD
git format-patch v2.6.32.9..HEAD

Sum total 173 patches for the 2.6.32.9 kernel as of writing.
If anyone knows where raw android kernel patches are available, please add a link here. See also the Android Kernel Features page for more information about individual kernel features.

Android Kernel Build

From eLinux.org

Jump to: navigation, search

How to build an Android kernel.
The Android build system may or may not automatically rebuild a kernel for you.
This page documents how to build an Android kernel, independent of the regular Android "distribution" build system.
[FIXTHIS - nothing here yet.]

[edit] Building an Individual application

Steps required to compile individual application package in Android SDK.

Go to build directory under Android sdk directory
Execute source source envsetup.sh
Go to corresponding application directory
Issue mm command to build the application only

Here are some development tools useful for working with Android

[edit] Android SDK

[edit] host-side tools

[edit] adb

adb is the android debugger - it also doubles as file transfer agent. The setup consists of an adbd on the target in the /sbin directory. On the host two programs are run: the adb application (in the SDK's tools directory) and an adb server, started by the adb application.
For emulators, adb will usually run automagically.
For real boards - with debugging over USB, you might need to do work, as is documented here: http://developer.android.com/guide/developing/device.html#setting-up .
For real boards that do not have a USB connection but have Ethernet instead, you might need to do a few tricks.

make sure that adbd runs on the board. If it doesn't run, you might want to check the init.rc file.
make sure that the network connection between host and the board is working - test pinging both ways.
on the host, type the following (and yes, you need to specify the board's IP address on the host):

ADBHOST=<target-ip> tools/adb kill-server
  ADBHOST=<target-ip> tools/adb shell

you should now get a prompt on the board, you can exit the prompt if you want.
tools/adb devices should now list the device.

[edit] aapt

The Android Asset Packaging Tool is used to create, inspect and manage Android packages.
You can use this to see details about a package, it's resources, and xml information.
The Android developer page on aapt is somewhat meager.
See Android aapt for substantially more information.

[edit] ddms

The Dalvik Debug Monitor Server is a host-based tool which interacts with and Android target system and can show numerous bits of information, including the log, cpu and memory utilization, and lots of details about individual processes.
See the DDMS developer guide

[edit] Fastboot

Android Fastboot is a tool to boot and manipulate the partitions on an Android development phone.

[edit] Toolchains

Android provides pre-built toolchains (C/C++ compilers and linkers), but requires the installation of a java compiler (JDK) from an external source.
As of NDK version r5 (December 2010), the toolchains can now be used in standalone cross-compiler mode. See docs/STANDALONE-TOOLCHAIN.html in the NDK for information about this. Previously, the toolchains could be used within the build system, but it was difficult and error prone to compile native programs outside the Android build system with them.

[edit] Emulator

Emulator - See http://developer.android.com/guide/developing/tools/emulator.html

The emulator is a version of QEMU, which mimics the instruction set of an ARM processor, and the hardware that one might find on a mobile phone. The emulator runs on an x86 system, but executes an ARM linux kernel and programs. The flow of control is:

- application ->
- dalvik VM ->
- C/C++ libraries ->
- ARM linux kernel ->
- emulated instructions and hardware (QEMU)->
- C libraries->
- x86 kernel ->
- real hardware

[edit] traceview

Google's main page describing traceview: http://developer.android.com/guide/developing/tools/traceview.html
http://www.bottomlesspit.org/file_download/2/Android_SDK_Traceview_tool.pdf - good overview presentation by Olivier Bilodeau
- presentation with speaker notes: http://www.bottomlesspit.org/file_download/3/Android_SDK_Traceview_tool_w_speakernotes.pdf
Performance Tuning Android Applications - straightforward article discussing traceview use to find an application bottleneck. April 2009.

[edit] target-side tools

[edit] am

Activity Manager - can be used to start applications at the command line, or send intents to running applications.

[edit] dumpstate

[edit] logcat

This is the user tool for accessing the Android system log. This is implemented at a special option in adb (I'm not sure what the difference is between "adb logcat" and "adb shell logcat")
You can find lots of information about logcat on the Android logger page, and at http://developer.android.com/guide/developing/tools/adb.html#logcat

[edit] monkey

[edit] procrank

procrank shows a listing of processes on the system, sorted by one of the memory utilization metrics. See Android Memory Usage#procrank

[edit] service

Can be used to send an individual service message.

Usage: service [-h|-?]
       service list
       service check SERVICE
       service call SERVICE CODE [i32 INT | s16 STR] ...
Options:
   i32: Write the integer INT into the send parcel.
   s16: Write the UTF-16 string STR into the send parcel.

On one forum, I saw that you could switch between portrait and landscape with:

$ service call window 18 i32 1 # to set to landscape on the emulator
$ service call window 18 i32 0 # to set to portrait on the emulator

service list will show a list of different services that can be communicated with.

[edit] toolbox

stop, start - commands to stop and start services on an Android system

[edit] other tools

[edit] agcc

agcc - A wrapper tool for compiling native Android apps (linked directly to bionic)
- See http://android-tricks.blogspot.com/2009/02/hello-world-c-program-on-using-android.html

[edit] bootchart

See Using Bootchart on Android

[edit] busybox

Android ships with a utility suite (called 'toolbox') that is not busybox.
You can get a binary busybox for Android here The site includes instructions for easy installation on your device.

[edit] smem

smem - smem is a tools for analyzing the memory usage on a system
- See Using smem on Android for more information

[edit] strace

strace
- Statically linked binary available at: http://benno.id.au/blog/2007/11/18/android-runtime-strace
- Instructions for building Android strace - http://discuz-android.blogspot.com/2008/01/create-google-android-strace-tool.html

[edit] Eclipse

The officially supported integrated development environment (IDE) is Eclipse (currently 3.4 or 3.5) using the Android Development Tools (ADT) Plugin, though developers may use any text editor to edit Java and XML files then use command line tools (Java Development Kit and Apache Ant are required) to create, build and debug Android applications as well as control attached Android devices (e.g., triggering a reboot, installing software package(s) remotely).

[edit] Hardware

[edit] Serial Cable for G1

You can build a serial cable to use with the G1, which is helpful to see kernel boot messages on the serial console.
See http://www.instructables.com/id/Android_G1_Serial_Cable
Back to Android Portal

Dalvik Porting Guide

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 09:24:00 +0000

Dalvik Porting Guide

The Dalvik virtual machine is intended to run on a variety of platforms. The baseline system is expected to be a variant of UNIX (Linux, BSD, Mac OS X) running the GNU C compiler. Little-endian CPUs have been exercised the most heavily, but big-endian systems are explicitly supported.
There are two general categories of work: porting to a Linux system with a previously unseen CPU architecture, and porting to a different operating system. This document covers the former.
Basic familiarity with the Android platform, source code structure, and build system is assumed.

Core Libraries

The native code in the core libraries (chiefly libcore, but also dalvik/vm/native) is written in C/C++ and is expected to work without modification in a Linux environment. Much of the code comes directly from the Apache Harmony project.
The core libraries pull in code from many other projects, including OpenSSL, zlib, and ICU. These will also need to be ported before the VM can be used.

JNI Call Bridge

Most of the Dalvik VM runtime is written in portable C. The one non-portable component of the runtime is the JNI call bridge. Simply put, this converts an array of integers into function arguments of various types, and calls a function. This must be done according to the C calling conventions for the platform. The task could be as simple as pushing all of the arguments onto the stack, or involve complex rules for register assignment and stack alignment.
To ease porting to new platforms, the open-source FFI library (Foreign Function Interface) is used when a custom bridge is unavailable. FFI is not as fast as a native implementation, and the optional performance improvements it does offer are not used, so writing a replacement is a good first step.
The code lives in dalvik/vm/arch/*, with the FFI-based version in the "generic" directory. There are two source files for each architecture. One defines the call bridge itself:

void dvmPlatformInvoke(void* pEnv, ClassObject* clazz, int argInfo, int argc, const u4* argv, const char* signature, void* func, JValue* pReturn)

This will invoke a C/C++ function declared:

return_type func(JNIEnv* pEnv, Object* this [, args])

or (for a "static" method):

return_type func(JNIEnv* pEnv, ClassObject* clazz [, args])

The role of dvmPlatformInvoke is to convert the values in argv into C-style calling conventions, call the method, and then place the return type into pReturn (a union that holds all of the basic JNI types). The code may use the method signature (a DEX "shorty" signature, with one character for the return type and one per argument) to determine how to handle the values.
The other source file involved here defines a 32-bit "hint". The hint is computed when the method's class is loaded, and passed in as the "argInfo" argument. The hint can be used to avoid scanning the ASCII method signature for things like the return value, total argument size, or inter-argument 64-bit alignment restrictions.

Interpreter

The Dalvik runtime includes two interpreters, labeled "portable" and "fast". The portable interpreter is largely contained within a single C function, and should compile on any system that supports gcc. (If you don't have gcc, you may need to disable the "threaded" execution model, which relies on gcc's "goto table" implementation; look for the THREADED_INTERP define.)
The fast interpreter uses hand-coded assembly fragments. If none are available for the current architecture, the build system will create an interpreter out of C "stubs". The resulting "all stubs" interpreter is quite a bit slower than the portable interpreter, making "fast" something of a misnomer.
The fast interpreter is enabled by default. On platforms without native support, you may want to switch to the portable interpreter. This can be controlled with the dalvik.vm.execution-mode system property. For example, if you:

adb shell "echo dalvik.vm.execution-mode = int:portable >> /data/local.prop"

and reboot, the Android app framework will start the VM with the portable interpreter enabled.

Mterp Interpreter Structure

There may be significant performance advantages to rewriting the interpreter core in assembly language, using architecture-specific optimizations. In Dalvik this can be done one instruction at a time.
The simplest way to implement an interpreter is to have a large "switch" statement. After each instruction is handled, the interpreter returns to the top of the loop, fetches the next instruction, and jumps to the appropriate label.
An improvement on this is called "threaded" execution. The instruction fetch and dispatch are included at the end of every instruction handler. This makes the interpreter a little larger overall, but you get to avoid the (potentially expensive) branch back to the top of the switch statement.
Dalvik mterp goes one step further, using a computed goto instead of a goto table. Instead of looking up the address in a table, which requires an extra memory fetch on every instruction, mterp multiplies the opcode number by a fixed value. By default, each handler is allowed 64 bytes of space.
Not all handlers fit in 64 bytes. Those that don't can have subroutines or simply continue on to additional code outside the basic space. Some of this is handled automatically by Dalvik, but there's no portable way to detect overflow of a 64-byte handler until the VM starts executing.
The choice of 64 bytes is somewhat arbitrary, but has worked out well for ARM and x86.
In the course of development it's useful to have C and assembly implementations of each handler, and be able to flip back and forth between them when hunting problems down. In mterp this is relatively straightforward. You can always see the files being fed to the compiler and assembler for your platform by looking in the dalvik/vm/mterp/out directory.
The interpreter sources live in dalvik/vm/mterp. If you haven't yet, you should read dalvik/vm/mterp/README.txt now.

Getting Started With Mterp

Getting started:

Decide on the name of your architecture. For the sake of discussion, let's call it myarch.
Make a copy of dalvik/vm/mterp/config-allstubs to dalvik/vm/mterp/config-myarch.
Create a dalvik/vm/mterp/myarch directory to hold your source files.
Add myarch to the list in dalvik/vm/mterp/rebuild.sh.
Make sure dalvik/vm/Android.mk will find the files for your architecture. If $(TARGET_ARCH) is configured this will happen automatically.

You now have the basic framework in place. Whenever you make a change, you need to perform two steps: regenerate the mterp output, and build the core VM library. (It's two steps because we didn't want the build system to require Python 2.5. Which, incidentally, you need to have.)

In the dalvik/vm/mterp directory, regenerate the contents of the files in dalvik/vm/mterp/out by executing ./rebuild.sh. Note there are two files, one in C and one in assembly.
In the dalvik directory, regenerate the libdvm.so library with mm. You can also use make libdvm from the top of the tree.

This will leave you with an updated libdvm.so, which can be pushed out to a device with adb sync or adb push. If you're using the emulator, you need to add make snod (System image, NO Dependency check) to rebuild the system image file. You should not need to do a top-level "make" and rebuild the dependent binaries.
At this point you have an "all stubs" interpreter. You can see how it works by examining dalvik/vm/mterp/cstubs/entry.c. The code runs in a loop, pulling out the next opcode, and invoking the handler through a function pointer. Each handler takes a "glue" argument that contains all of the useful state.
Your goal is to replace the entry method, exit method, and each individual instruction with custom implementations. The first thing you need to do is create an entry function that calls the handler for the first instruction. After that, the instructions chain together, so you don't need a loop. (Look at the ARM or x86 implementation to see how they work.)
Once you have that, you need something to jump to. You can't branch directly to the C stub because it's expecting to be called with a "glue" argument and then return. We need a C stub "wrapper" that does the setup and jumps directly to the next handler. We write this in assembly and then add it to the config file definition.
To see how this works, create a file called dalvik/vm/mterp/myarch/stub.S that contains one line:

/* stub for ${opcode} */

Then, in dalvik/vm/mterp/config-myarch, add this below the handler-size directive:

# source for the instruction table stub
asm-stub myarch/stub.S

Regenerate the sources with ./rebuild.sh, and take a look inside dalvik/vm/mterp/out/InterpAsm-myarch.S. You should see 256 copies of the stub function in a single large block after the dvmAsmInstructionStart label. The stub.S code will be used anywhere you don't provide an assembly implementation.
Note that each block begins with a .balign 64 directive. This is what pads each handler out to 64 bytes. Note also that the ${opcode} text changed into an opcode name, which should be used to call the C implementation (dvmMterp_${opcode}).
The actual contents of stub.S are up to you to define. See entry.S and stub.S in the armv5te or x86 directories for working examples.
If you're working on a variation of an existing architecture, you may be able to use most of the existing code and just provide replacements for a few instructions. Look at the armv4t implementation as an example.

Replacing Stubs

There are roughly 230 Dalvik opcodes, including some that are inserted by dexopt and aren't described in the Dalvik bytecode documentation. Each one must perform the appropriate actions, fetch the next opcode, and branch to the next handler. The actions performed by the assembly version must exactly match those performed by the C version (in dalvik/vm/mterp/c/OP_*).
It is possible to customize the set of "optimized" instructions for your platform. This is possible because optimized DEX files are not expected to work on multiple devices. Adding, removing, or redefining instructions is beyond the scope of this document, and for simplicity it's best to stick with the basic set defined by the portable interpreter.
Once you have written a handler that looks like it should work, add it to the config file. For example, suppose we have a working version of OP_NOP. For demonstration purposes, fake it for now by putting this into dalvik/vm/mterp/myarch/OP_NOP.S:

/* This is my NOP handler */

Then, in the op-start section of config-myarch, add:

op OP_NOP myarch

This tells the generation script to use the assembly version from the myarch directory instead of the C version from the c directory.
Execute ./rebuild.sh. Look at InterpAsm-myarch.S and InterpC-myarch.c in the out directory. You will see that the OP_NOP stub wrapper has been replaced with our new code in the assembly file, and the C stub implementation is no longer included.
As you implement instructions, the C version and corresponding stub wrapper will disappear from the output files. Eventually you will have a 100% assembly interpreter. You may find it saves a little time to examine the output of your compiler for some of the operations. The porting-proto.c sample code can be helpful here.

Interpreter Switching

The Dalvik VM actually includes a third interpreter implementation: the debug interpreter. This is a variation of the portable interpreter that includes support for debugging and profiling.
When a debugger attaches, or a profiling feature is enabled, the VM will switch interpreters at a convenient point. This is done at the same time as the GC safe point check: on a backward branch, a method return, or an exception throw. Similarly, when the debugger detaches or profiling is discontinued, execution transfers back to the "fast" or "portable" interpreter.
Your entry function needs to test the "entryPoint" value in the "glue" pointer to determine where execution should begin. Your exit function will need to return a boolean that indicates whether the interpreter is exiting (because we reached the "bottom" of a thread stack) or wants to switch to the other implementation.
See the entry.S file in x86 or armv5te for examples.

Testing

A number of VM tests can be found in dalvik/tests. The most useful during interpreter development is 003-omnibus-opcodes, which tests many different instructions.
The basic invocation is:

$ cd dalvik/tests
$ ./run-test 003

This will run test 003 on an attached device or emulator. You can run the test against your desktop VM by specifying --reference if you suspect the test may be faulty. You can also use --portable and --fast to explictly specify one Dalvik interpreter or the other.
Some instructions are replaced by dexopt, notably when "quickening" field accesses and method invocations. To ensure that you are testing the basic form of the instruction, add the --no-optimize option.
There is no in-built instruction tracing mechanism. If you want to know for sure that your implementation of an opcode handler is being used, the easiest approach is to insert a "printf" call. For an example, look at common_squeak in dalvik/vm/mterp/armv5te/footer.S.
At some point you need to ensure that debuggers and profiling work with your interpreter. The easiest way to do this is to simply connect a debugger or toggle profiling. (A future test suite may include some tests for this.)

Android's git Repository

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 09:23:00 +0000

***

a public git repository put together with the 
various android-specific kernel patches (binder, logger, alarm drivers,
goldflish platform support, etc) soon.

Which HW support

[Anil S <anils@mistralsolutions.com>]
> Hello Brian,
> 
>  It would be really great if you could share thoughts on the
> questions given here on Android:
> 
> I was able to add support for the keypad, touch and network in Android,
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D
> acceleration, battery etc. are not integrated with Android right now. I
> would appreciate if you could throw some light on these open issues. How
> exactly can these interfaces be integrated with Android? 

We're trying to use the standard kernel/driver interfaces when possible,
but for things that may have a good deal of variation in implementation,
we're looking to provide a very thin "hardware interface library" layer
to adapt between the bottom of the userspace stack and the drivers or
whatnot for specific hardware platforms.  

We'll continue to adopt standardized kernel solutions as they become
available -- We're now using the power supply framework in 2.6.24 for
monitoring battery/charge state (post M5 SDK -- it'll be in the next 
release), for example.

List:       linux-omap
Subject:    Re: Android on OMAP
From:       Dirk Behme <dirk.behme () googlemail ! com>
Date:       2008-02-26 8:46:05
Message-ID: 47C3D1CD.9060204 () googlemail ! com
[Download message RAW]

skyflame wrote:
>>> Hi
>>>
>>> I move to m5-r14 with both kernel driver and filesystem grabed from 
>>> the sdk.
>>> Now, I can enter the homescreen , and the keyboard is also working 8 )
>>>
>>> I don't do anything extra than what I am doing on the m3-r14 release.
>>
>>
>> Great! Congratulations! :)
>>
>> Do you think you can make the kernel patch (against 2.6.23-omap1?) and 
>> the filesystem available somewhere? Then we can link wiki page to it.
>>
>> Dirk
>>
>>
> 
> Hi Dirk
> 
> I was working on a 2.6.21 kernel. For I don't got a working 2.6.23 
> kernel on hand.
> The git tree kernel don't work fine with my omap2430SDP V5.0
> The PMIC seems not working in the right way, thus the LCD don't run up.
> So I can not make the diff over 2.6.23 omap1  : (

Okay. I sent my 2.6.23 omap1 Android patch yesterday (seems that it 
didn't reach the list cause of > 100k). If you didn't get it I can 
send it again in private mail. Would be quite nice if you could check 
if there are the same files in it you used.

Anything like

cat my_patch | grep +++ > file1
cat your_patch | grep +++ > file2
kdiff3 file1 file2

> The whole Filesystem is about 28MBytes in bz2 format.
> I don't know where can I upload it. I can not find some place where can 
> hold such big file for a long time.
> I am glad to upload it , if someone has the network storage resources.

As already mentioned yesterday: Same to me ;)

Anybody with ~30-40 MB permanent public storage?

> I'm hoping to get a public git repository put together with the 
> various android-specific kernel patches (binder, logger, alarm drivers,
> goldflish platform support, etc) soon.  This should at least make
> it easier for folks to merge various drivers 'n things into their
> working trees, rather than having to extract them from the kernel
> source tarball provided with emulator/sdk releases.

The core android kernel patches are now available from git.android.com.
Please be aware that these are *newer* than the M5 SDK, and I think
the binder driver in particular may not be compatible with M5.  When
the next SDK release happens, we should be able to point at a sha1
hash of the git change the kernel came from.

http://git.android.com/?p=kernel.git;a=shortlog;h=android
git://git.android.com/kernel.git

Please note that for legacy reasons the default branch is the
msm-2.6.24 branch -- you'll want to check out the "android"
branch if you're looking for the generic patches useful for
all platforms.

Android Porting On Real Target [Realtime Project]

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 08:49:00 +0000

1 Introduction

2 Copyright and Acknowledgements

3 The brief analysis of the Android architecture

3.1 Android Kernel

3.1.1 ARM EABI
3.1.2 OpenBinder
3.1.3 Frame Buffer
3.1.4 Input Devices
3.1.5 Low Memory Killer
3.1.6 Android Logger
3.1.7 Android Power
3.1.8 Panic Timeout

3.2 Android Root File system

3.3 Licenses of the Android Packages

4 Toolchain supporting ARM EABI

4.1 Building toolchain
4.2 Other toolchain

5 Kernel

5.1 Patch kernel
5.2 .config

6 Root file system

6.1 Get ramdisk image from emulator
6.2 Get data and system directory from emulator
6.3 Integrate the Android system with a existing ramdisk image.
6.4 System and Data directories
6.5 Run and Debug
6.6 Screenshots

7 Application Development

7.1 Install Eclipse IDE
7.2 Build and Run Sample Applications
7.3 Screenshots

8 Epilogue

9 Links and References

[edit]

1 Introduction ¶

Google explains that Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This document explains the Android architecture by Google and porting procedure on the real hardware. The explanation is based on the m3 sdk version of the Android emulator.

If you have enough knowledge about patching the kernel, resolving rejections from a patch, making an ramdisk image, and the Linux kernel itself, reading this article will be easier.

[edit]

2 Copyright and Acknowledgements ¶

This document is copyright (c) Kwangwoo Lee (kwangwoo.lee at gmail dot com). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

AndroidPortingOnRealTarget/ko - Korean translation by dasomoli (dasomoli at gmail dot com).

[edit]

3 The brief analysis of the Android architecture ¶

[edit]

3.1 Android Kernel ¶

The most different things are the Android kernel uses ARM EABI(Embedded Application Binary Interface) and OpenBinder IPC(Inter Process Communication). If you want to compile the kernel supporting ARM EABI, you should rebuild toolchains to support ARM EABI.

The Android sdk emulates goldfish architecture using qemu. The alsa may be used for audio on Android. See the audio.c file in the goldfish architecture directory and the driver uses /dev/eac for audio on the Android system. RTC(Real Time Clock) device is also used through /dev/rtc0.

The following parts explain the main differences:

[edit]

3.1.1 ARM EABI ¶

EABI is the new "Embedded" ABI by ARM Ltd. The changes are listed on Debian wiki. (http://wiki.debian.org/ArmEabiPort)

Faster floating point performance, with or without FPU.
Mixing soft and hardfloat code is possible.
Structure packing is not as painful as it used to be.
More compatibility with various tools.
A more efficient syscall convention. (http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4)

Example with long ftruncate64(unsigned int fd, loff_t length):

legacy ABI:
- put fd into r0
- put length into r1-r2
- use "swi #(0x900000 + 194)" to call the kernel

new ARM EABI:
- put fd into r0
- put length into r2-r3 (skipping over r1)
- put 194 into r7
- use "swi 0" to call the kernel

The Android uses EABI kernel feature. Enable kernel options of the CONFIG_AEABI and CONFIG_OABI_COMPAT. You can see the differences of the executable binary as follows :

Legacy ABI

$ arm-softfloat-linux-gnu-objdump -x t7-demo | grep private
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

$ file t7-demo
t7-demo: ELF 32-bit LSB executable, ARM, version 1 (ARM), 
for GNU/Linux 2.4.3, dynamically linked (uses shared libs), 
for GNU/Linux 2.4.3, stripped

ARM EABI

$ arm-softfloat-linux-gnueabi-objdump -x t7-demo  | grep private
private flags = 4000002: [Version4 EABI] [has entry point]

$ file t7-demo
t7-demo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), 
for GNU/Linux 2.6.14, dynamically linked (uses shared libs), 
for GNU/Linux 2.6.14, stripped

The FAQs from codesourcery explains ABI and EABI :

What is the ABI for the ARM Architecture? Is it the same as the ARM EABI?

The ABI for the ARM Architecture is a standard developed by ARM and its partners (including CodeSourcery) that explains how compilers, assemblers, linkers, and other similar tools should generate object files and executable files. Tools that correctly implement the ABI for the ARM Architecture can interoperate; i.e., objects files built with one toolchain can be combined with object files built with another toolchain if both compilers use the ABI for the ARM Architecture. The "ARM EABI" is an informal name for the ABI for the ARM Architecture.

[edit]

3.1.2 OpenBinder ¶

The OpenBinder provides a object-oriented operating system environment. It is designed to be hosted by traditional kernels. This project is started at Be. Inc. as the part of the next generation BeOS, and finished implementing at PalmSource as a core part at the Cobalt system.

It is a system oriented component architecture rather than application oriented, and It provides IPC between processes, threadpool, memory management and clean up feature at the end of reference of an binder object.

The vanilla kernel do not have OpenBinder IPC mechanism you should patch the kernel. The OpenBinder offers thread management for the system through /dev/binder. It is the reason that Android system do not offer thread libraries.

Dianne Hackborn worked for the BeOS explains briefly at osnews.com.
http://osnews.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/
Documentation
http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html
Source code
http://www.angryredplanet.com/~hackbod/openbinder/openbinder-12-28-2005.tar.gz

After patching the kernel, you can see the files for binder at drivers/binder/.

[edit]

3.1.3 Frame Buffer ¶

The basic frame buffer driver should be implemented already. After that you need to implement the differences between your architecture driver and the goldfish driver.

The frame buffer driver of the goldfish architecture supports the fb_pan_display function of the struct fb_ops. It means you should allocate memory twice rather than the actual frame size.

Initialize frame buffer information

struct fb_info *fbinfo;
...
fbinfo->fix.ypanstep = 1;
fbinfo->var.yres_virtual    = gm->lcd.yres * 2;
fbinfo->fix.smem_len        = (gm->lcd.xres *
                                gm->lcd.yres *
                                gm->lcd.bpp / 8) * 2;

Allocate frame buffer memory

struct mvfb_info *fbi;
...
fbi->map_size = PAGE_ALIGN(fbi->fb->fix.smem_len + PAGE_SIZE);
fbi->map_cpu  = dma_alloc_writecombine(fbi->dev, fbi->map_size,
                                       &fbi->map_dma, GFP_KERNEL);

Implement fb_pan_display fuction hook

static int mvfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *fb)
{
...
}

static struct fb_ops mvfb_ops = {
        .owner  = THIS_MODULE,

        .fb_check_var = mvfb_check_var,
        .fb_set_par = mvfb_set_par, 
        .fb_setcolreg = mvfb_setcolreg,
        .fb_blank = mvfb_blank,
        .fb_pan_display = mvfb_pan_display,

        .fb_fillrect = cfb_fillrect,
        .fb_copyarea = cfb_copyarea,
        .fb_imageblit = cfb_imageblit,

        .fb_mmap = mvfb_mmap, 
};

The device file is located at /dev/graphics/fb0.

[edit]

3.1.4 Input Devices ¶

Android uses event device for user input. There are three devices such as keypad, qwerty2 keyboard and mouse. The qwerty2 keyboard and mouse are normal devices. So I just explain the keypad and touchscreen which mouse device is replaced with.

On the Android shell, Cat the /proc/bus/input/{devices,handlers} and then you will see the devices used for the Android.

$ adb shell

# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="goldfish-events-keyboard"
P: Phys=
S: Sysfs=/class/inut/input0
U: Uniq=
H: Handlers=kbd mouse0 event0
...
#
# cat /proc/bus/input/handlers
N: Number=0 Name=kbd
N: Number=1 Name=mousedev Minor=32
N: Number=2 Name=evdev Minor=64
#

Keypad

Qemu emulates goldfish-events-keyboard. It is a keypad using event device(/dev/input/event0). So you should know which key event and values come from the event device to activate Android applications. To do that, read event0 device with cat and redirect the output to a file. If you push and release the key button on emulator, the output values will be saved.

The output format is struct input_event. So the output on each event is 16 bytes like 8 bytes for time, 2 bytes for type, 2 bytes for code, 4 bytes for value. Read input.txt and input-programming.txt about input event devices in the Documentation/input directory of the Linux kernel source code.

struct input_event {
        struct timeval time;
        unsigned short type;
        unsigned short code;
        unsigned int value;
};

The Tiger7 evaluation board has it's own scancode table. The following shows the key layout on evaluation board, scancode table, and Android keycodes:

/*
 *  Key Layout       Scancode Table
 *
 *   1  2  3        0x1  0x10  0x100
 *   4  5  6        0x2  0x20  0x200
 *   7  8  9        0x4  0x40  0x400
 *   *  0  #        0x8  0x80  0x800
 */

static unsigned short android_keycode[] = {
        /*
         *  0x66 0x67 0x9e Home  Up   Back
         *  0x69 0xe8 0x6a Left  Ok   Right
         *  0xe7 0x6c 0x6b Send  Down Hangup
         *  0xe5  Menu       just_distinction_for_private
         */
        KEY_HOME,         KEY_UP,       KEY_BACK,
        KEY_LEFT,         KEY_REPLY,    KEY_RIGHT,
        KEY_SEND,         KEY_DOWN,     KEY_END,
        KEY_KBDILLUMDOWN, KEY_RESERVED, KEY_PLAY
};

There is a power button on emulator, but I skipped it to get output value.

If an interrupt of the keypad is caught, translate the scancode with the keycode of the Android on the above table and send event to user space application.

...
keycode = translate_keycode(scancode);
...
input_event(keydev->input, EV_KEY, keycode, KEY_PRESSED);
or
input_event(keydev->input, EV_KEY, keycode, KEY_RELEASED);
...

The high resolution timer - hrtimer is used for reduce keypad debounce.

Touchscreen

If you have a touchscreen driver supporting the event interface for a pointing device, it'll work well. If you do not have it, you may implement it or use other pointing devices. Fortunately the evaluation board has already implemented touchscreen driver - drivers/input/touchscreen/tsc2007.c - which is made just before beginning to porting Android. Refer the drivers on drivers/input/touchscreen/ to implement your own driver and the text files on Documentation/input/.

Here is the output of the /proc/bus/input/{devices,handlers} on evaluation board.

# cat /proc/bus/input/devices
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="MVT7 KEYPAD"
P: Phys=
S: Sysfs=/class/input/input0
U: Uniq=
H: Handlers=kbd event0 evbug
B: EV=f
...

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="TSC2007 Touchscreen"
P: Phys=0-0090/input0
S: Sysfs=/class/input/input1
U: Uniq=
H: Handlers=event1 evbug
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=1000003

# cat /proc/bus/input/handlers
N: Number=0 Name=kbd
N: Number=1 Name=evdev Minor=64
N: Number=2 Name=evbug

As a result, the keypad uses /dev/input/event0 and the touchscreen interface uses /dev/input/event1 on application layer.

[edit]

3.1.5 Low Memory Killer ¶

The Linux Kernel has an OOM(Out of Memory) killer for the situation that no memory is left to allocate for a request of a process. It examines all processes and keeps score with some restrictions. The process with highest score will be killed except init.

The Low Memory Killer of the Android behaves a bit different against OOM killer. It classifies processes according to the importance with groups and kills the process in the lowest group. It will make the system to be stable at the view of the end users. For example, the UI Process - foreground process - is the most important process for the end users. So to keep the process live looks more stable than keeping other background processes live.

Enable CONFIG_LOW_MEMORY_KILLER after patching the kernel.

[edit]

3.1.6 Android Logger ¶

If you enable this feature, you can see some useful information about Android through /dev/log/main. There are three device files on /dev/log such as main, events, radio. The /dev/log/radio file seems to be related with a modem device and ril daemon - rild - on Android system.

When this logger is enabled, the system performance is a bit slower on the system. To use this feature, enable CONFIG_ANDROID_LOGGER.

[edit]

3.1.7 Android Power ¶

The Android power is for the battery management on devices and some subsystem related with power management like inotify feature on file system. It is not necessary to start up Android through the init(ShellScript) of the Android system. But the runtime binary looks up some files regarding Android power - /sys/android_power/acruire_partial_wake_lock - on starting up Android manually and failed to start up. Enable CONFIG_ANDROID_POWER to use.

- 예전 버전의 문서에서 init은 바이너리로 되어있었는데 쉘스크립트로 바뀌어 있네요. 이전 문서에서 말한 init은 안드로이드 램디스크의 루트 디렉토리 밑에 있는 init 바이너리를 말씀하신 것 같은데, 그 것이 아니고 다른 init인건가요? 아니면 그 init이 쉘 스크립트인 것인가요? -- dasomoli

- 문서를 작성한 m3 버전에서는 binary 였습니다. 다른 분이 shell script로 바꾼 것 같네요. 번역해 주셔서 감사합니다. -- 이광우

- m5 버전에서도 바이너리인 것 같아서요. 그리고 별 말씀을요.^^; -- dasomoli

[edit]

3.1.8 Panic Timeout ¶

It is not necessary to start up Android on evaluation board. Set CONFIG_PANIC_TIMEOUT with a desired value.

[edit]

3.2 Android Root File system ¶

Android emulator has 3 basic images on tools/lib/images directory.

ramdisk.img
system.img
userdata.img

ramdisk.img is gziped cpio archive. ramdisk image is very small and contains configuration files, and some executable files such as init and recovery. The init file is not a regular system V init. It is made just for the Android and do special things to start up the Android system.

system.img and userdata.img are VMS Alpha executable. system.img and userdata.img have the contents of /system and /data directory on root file system. They are mapped on NAND devices with yaffs2 file system. /dev/block/mtdblock0 for /system and /dev/block/mtdblock1 for /data.

/system directory has libraries and default system packages (*.apk). /data directory has timezone, cache, and ApiDemos.apk package.

The main services are zygote(/system/bin/app_process), runtime(/system/bin/runtime), and dbus(/system/bin/dbus-daemon). You can see the /etc/init.rc file on the Android ramdisk image.

...
zygote {
    exec /system/bin/app_process
    args {
        0 -Xzygote
        1 /system/bin
        2 --zygote
    }
    autostart 1
}
runtime {
    exec /system/bin/runtime
    autostart 1
}
...
dbus {
    exec /system/bin/dbus-daemon
    args.0 --system
    args.1 --nofork
    autostart 1
}
...

[edit]

3.3 Licenses of the Android Packages ¶

tools/lib/images/NOTICE contains package lists and licenses for each libraries. The table of the licenses is cited from the presentation by Lim,GeunSik at 2008 Korea Android Summit.

Open Source	License
Linux Kernel	GPL
NetBSD C Library	BSD
DBUS	GPL2
OpenBinder (core)	GPL2
YAFFS2	GPL
SQLite	GPL2
Webkit	BSD (including LGPL)
WebCore	LGPL
SDL	LGPL
SGL	Google(Skia)
OpenGL	SGI OpenGL (BSD/MPL)

[edit]

4 Toolchain supporting ARM EABI ¶

The toolchain represents the tools to be used for the system development. It contains C/C++ compiler, linker, libraries, binutils, and etc. The Android kernel and system requires EABI support. So legacy toolchain is not compatible to make the Android system.

[edit]

4.1 Building toolchain ¶

To make life easier, I used the crosstool-0.43 script (http://www.kegel.com/crosstool/) by Dan Kegel. Unfortunately it is not support to build eabi toolchain, so I applied a glibc 2.5+ nptl build for arm softfloat eabi patch (http://sources.redhat.com/ml/crossgcc/2006-12/msg00076.html) by Khem Raj.

$./arm-softfloat-eabi.sh

If the network is connected, the script will download and build toolchain using gcc 4.1.1 and glibc 2.5.

[edit]

4.2 Other toolchain ¶

I did not use the codesourcery toolchain, but they said it will work for the building Android system.

* http://www.codesourcery.com

[edit]

5 Kernel ¶

To port the Android on a real hardware is started by Benno (http://benno.id.au), you can see some useful information on his blog. On his blog some pre-compiled static binaries are linked. It is very helpful for debugging Android system. You can also build static build busybox and strace binaries, but it's better to get them and use.

You can get patch file including the differences between the Android kernel and the vanilla kernel with 2.6.23 version. It has all differences between them. So you need to extract parts of them, and make your own patch for your system architecture.

For example, the Android kernel has it's own yaffs file system patch. If you have your own yaffs or some other file systems like jffs2 on your architecture, then you need to remove the yaffs parts of the patch. The goldfish architecture which the Android kernel emulate an ARM architecture on qemu is not necessary part for your architecture. It can be removed.

The Android kernel emulates ARMv5 instructions. So ARM926EJ-S (ARMv5TEJ) will be good to work.

[edit]

5.1 Patch kernel ¶

Benno played with a NEO1973 device by openmoko. So he made patch files for it. Get the original patch file from http://benno.id.au/blog/2007/11/21/android-neo1973, I used android.diff. It has whole things about goldfish, qemu, yaffs, and Android specific parts.

You can edit and remove the patch file directly. After making patch including binder, android power, android logger, low memory killer except goldfish and qemu specific parts, get vanilla 2.6.23 version Linux kernel and patch it.

If you use a 2.6.24.1 version Linux kernel, some part regarding android power should be fixed accordingly or disabled to work.

[edit]

5.2 .config ¶

Necessary

...
CONFIG_PANIC_TIMEOUT=0
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_BINDER=y
CONFIG_LOW_MEMORY_KILLER=y
...

Optional

...
# CONFIG_ANDROID_GADGET is not set
# CONFIG_ANDROID_RAM_CONSOLE is not set
# CONFIG_ANDROID_POWER is not set
# CONFIG_ANDROID_LOGGER is not set
...

[edit]

6 Root file system ¶

The root file system is composed of three parts such as a primary ramdisk image on ram, a system image on nand dev0 (/dev/block/mtdblock0), and a data image on nand dev1 (/dev/block/mtdblock1). The mtd devices has a yaffs2 file system and each of them has 64 MiB capacity on the Android emulator.

The extracted system and data directories are copied to the real existing NAND device and they are mounted with --bind option to work on a real hardware.

[edit]

6.1 Get ramdisk image from emulator ¶

1. unpack ramdisk image from tools/lib/images/ramdisk.img

$ gzip -cd ramdisk.img > ramdisk
$ cpio -iv -F ramdisk

cpio will extract files and directories on current working directory.

2. the contents list of the ramdisk

data
dev
etc
etc/default.prop
etc/firmware
etc/firmware/brf6150.bin
etc/firmware/brf6300.bin
etc/hcid.conf
etc/hosts
etc/init.gprs-pppd
etc/init.rc
etc/init.ril
etc/init.testmenu
etc/ppp
etc/ppp/chap-secrets
etc/ppp/ip-down
etc/ppp/ip-up
etc/qemu-init.sh
etc/system.conf
etc/system.d
etc/system.d/bluez-hcid.conf
etc/usbd.conf
init
proc
sbin
sbin/recovery
sys
system
tmp
var
var/run

[edit]

6.2 Get data and system directory from emulator ¶

To get data and system directory you need a static compiled busybox binary. The compiled binary can be obtained from http://benno.id.au/blog/2007/11/14/android-busybox , or make your own binary.

1. launch the Android emulator

2. push static compiled busybox into emulator

# adb push busybox .

3. launch the Android shell

# adb shell

4. make tarball with busybox

# chmod +x /busybox
# busybox tar -c /data.tar /data
# busybox tar -c /system.tar /system
# exit

5. extract tarball from the emulator

# adb pull /data.tar .
# adb pull /system.tar .

Extract command often failed. So you may repeat it again until it has done successfully.

[edit]

6.3 Integrate the Android system with a existing ramdisk image. ¶

The ramdisk for your architecture can make your work a bit easier. Copy the contents of the Android ramdisk to your own ramdisk except system and data directory. And make just mount point for system and data directory. The mount points will be used later with a bind option. The init binary of the Android ramdisk image is the key binary to start the system and It read a configuration file on /etc/init.rc.

Edit /etc/init.rc and comment out qemu part.

...
startup {
        ...
#       qemu-init {
#           exec /etc/qemu-init.sh
#       }
}
...

Make run.sh script. /dev/block/mtdblock5 is a mtd partition on a real NAND device, and it is mounted on /mnt. data and system directories are already copied on mtdblock5. So the script below just shows bind mounting each directory on /. Fix your script according to your board configuration.

#!/bin/sh
mount -t yaffs /dev/block/mtdblock5 /mnt
mount --bind /mnt/data   /data
mount --bind /mnt/system /system

# data folder is owned by system user on emulator. Fix 777 to other.
chmod 777 /data
#chmod 777 /system

export PATH=/system/sbin:/system/bin:/sbin/usr/local/bin
export LD_LIBRARY_PATH=/system/lib

export ANDROID_BOOTLOGO=1
export ANDROID_ROOT=/system
export ANDROID_ASSETS=/system/app
export EXTERNAL_STORAGE=/sdcard
export ANDROID_DATA=/data
export DRM_CONTENT=/data/drm/content

/init &

An optional configuration for touchscreen - TSLib.

...
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event1
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/lib/ts

export LD_PRELOAD=/lib/libts.so:/lib/ts/pthres.so
...

[edit]

6.4 System and Data directories ¶

The contents of the system and data directories are copied to mtdblock5 already. You should copy your own method. To use it, I chose bind mounting on root directory. Bind mounting is a technique to mount an existing directory with a new mount point.

[edit]

6.5 Run and Debug ¶

Now the kernel, ramdisk, and data directories - data and system - are ready. It's time to see the red cylon eye. After boot up your integrated system, run the run.sh on root directory.

# cd /
# . /android/run.sh
yaffs: dev is 32505861 name is "mtdblock5"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.5, "mtdblock5"
yaffs: auto selecting yaffs2
# init: HOW ARE YOU GENTLEMEN
init: reading config file
init: device init
init: mtd partition -1,
init: mtd partition 0, "l1boot"
init: mtd partition 1, "u-boot"
init: mtd partition 2, "params"
init: mtd partition 3, "kernel"
init: mtd partition 4, "ramdisk"
init: mtd partition 5, "rootfs"
sh: can't access tty; job control turned off
# binder_open(c394bcc8 c3c731a0) (pid 1577) got c3e48000
binder_open(c394bcc8 c3cd8dc0) (pid 1616) got c319f000
binder_open(c394bcc8 c3cd8ac0) (pid 1673) got c3d10000
binder_open(c394bcc8 c3cd8940) (pid 1680) got c0e19000
binder_open(c394bcc8 c3cd88c0) (pid 1691) got c2fa0000
binder_open(c394bcc8 c3d174a0) (pid 1592) got c25b8000
binder_release(c394bcc8 c3cd88c0) (pid 1691) pd c2fa0000
#

Do not make eac device file on /dev. It is for the audio on qemu. If it exists, the start up sequence will wait forever to finish writing some data to the sound device.
Use the Android init binary instead of manual startup. The manual start up will require the android power patch. In that case the start up sequence will access /sys/android_power/acquire_partial_wake_lock and wait.

To debug the Android system, use static compiled strace binary from http://benno.id.au/blog/2007/11/18/android-runtime-strace and run the Android manually.

#!/bin/sh
# set environment variables above example
...
/system/bin/app_process -Xzygote /system/bin --zygote &
/system/bin/dbus-daemon --system &
/system/bin/runtime

The above example shows manual startup sequence, use strace on run /system/bin/runtime binary.

./strace -ff -F -tt -s 200 -o /tmp/strace runtime

[edit]

6.6 Screenshots ¶

Skipped

[edit]

7 Application Development ¶

The Android applications use Java syntax and xml layouts, but it is not a Java. Because they use their own virtual machine - dalvik - and compiler for dex file format. And use package named apk such as Home.apk, Phone.apk, ApiDemos.apk and etc.

The apk file is a Zip archive and it has four parts.

AndroidManifest.xml
classes.dex
resources.arsc
res directory

The Dex file format is explained on http://www.retrodev.com/android/dexformat.html. And the contents of the files and directories are explained some day by Google. It is not explained currently. We can just guess about it.

The Android SDK will create an *.apk file.

[edit]

7.1 Install Eclipse IDE ¶

Install procedure from http://code.google.com/android/intro/installing.html

1. Eclipse IDE for Java developer (JDT and WST plugins are included) from http://www.eclipse.org/downloads/

2. JDK (Java SE) from http://java.sun.com/javase/downloads/index.jsp

3. ADT (Android Development Tools) with a eclipse plugin including Apache Ant

[edit]

7.2 Build and Run Sample Applications ¶

1. Open sample projects and build

2. Run sample applications on emulator

[edit]

7.3 Screenshots ¶

Android Platform on Nokia's N810 Product(arm1136jf-s)
Android Platform on arm1136jf-S for another CE Product.

이광우

[edit]

8 Epilogue ¶

The Android system seems to be a new kind of a Linux based distribution for a mobile environment like Debian, RedHat, SuSE, and etc. They just use the Linux kernel and a lot of different libraries in the open source world. They offer a software based OpenGL-ES library on a 3D acceleration currently, but they are developing on a hardware accelerated baseband processor for it. The hardware acceleration is necessary for fast UI rendering effects later.

The Android system on the sdk is not a completed one to port on a real hardware, because some device - for example, camera - related libraries and classes are not implemented yet and not opened for users. It seems to be under the development stage. So we would better to wait the Google announces the whole porting kit.

Until then, we should look for the business model with the Android system. It requires a bit high cpu performance, so the carrier vendors will require a cheap baseband processor (RF part) and a multimedia co-processor, because the baseband processor including multimedia features will be very expensive.

[edit]

9 Links and References ¶

Android Main Page : http://code.google.com/android/
Debian ARM EABI wiki : http://wiki.debian.org/ArmEabiPort
System Call Convention : http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4
The FAQs from Codesourcery : https://support.codesourcery.com/GNUToolchain/kbentry32
Dianne Hackborn interview for OpenBinder : http://osnews.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/
OpenBinder Documentation : http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html
OpenBinder Source : http://www.angryredplanet.com/~hackbod/openbinder/openbinder-12-28-2005.tar.gz
Crosstool : http://www.kegel.com/crosstol/
Crosstool EABI patch : http://sources.redhat.com/ml/crossgcc/2006-12/msg00076.html
Codesourcery : http://www.codesourcery.com
Benno's blog : http://benno.id.au
Android patch : http://benno.id.au/blog/2007/11/21/android-neo1973
Static Busybox : http://benno.id.au/blog/2007/11/14/android-busybox
Static Strace : http://benno.id.au/blog/2007/11/18/android-runtime-strace
Dex File Format : http://www.retrodev.com/android/dexformat.html
Android SDK Install : http://code.google.com/android/intro/installing.html
Eclipse IDE : http://www.eclipse.org/downloads/
JDK SE : http://java.sun.com/javase/downloads/index.jsp
Presentation from the 2008 Korea Android Summit (http://www.kandroid.org )

Android on OMAP

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 08:42:00 +0000

This page collects information about and guides you through the installation of Google's Android on TI's ARM based OMAP SoCs.
Note: Only small parts of this page should be TI OMAP specific. The basic tasks should also apply to all other ARM926 or higher based SoCs at least able to run a 2.6.23 Linux kernel.
Note: If you like this page, please see the Android Portal on this site for much more information about Android systems programming. See Android Porting for more links to porting information, articles and tutorials.
Note: This article assumes that your are familiar with some basics of embedded ARM Linux. E.g. you should know how to use diff & patch, how to boot your embedded ARM SoC with a recent non-Android Linux, how to use a cross compiler etc.

[hide]

[edit] Android

[edit] What is Android (not)

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. See Google's What is Android? page and Benno's What is Android? and What Android isn't page for more details about Android.

[edit] Versions

From time to time Google updates their Android releases. At time of writing this article version m5-rc14 was the recent one. You should always use the latest available version. And make sure you use an Android kernel (patch) for your hardware that matches the file system version (see below).

[edit] Hardware

[edit] Goldfish

Android SDK isn't targeted for a special (ARM) SoC. Instead, they use QEMU to create a virtual ARM SoC called Goldfish. The virtual ARM SoC boots an (currently 2.6.23, m5-rc14) ARM Linux kernel with Goldfish platform support on your (x86) Windows, MacOS X or Linux host.
This virtual ARM SoC comprises:

ARM926ej-S CPU
Thumb support
MMC
RTC
Keyboard
USB Gadget
Framebuffer
TTY driver
NAND
Software compiled for ARMv5TEJ instruction set (!) with EABI
no TLS yet

[edit] Real hardware

Running Android on real hardware, some prerequisites should be fulfilled:

SoC with ARM926 or higher (e.g. ARM11) (check ARM MPCore or ARM Cortex regarding TLS issue)
- Note: ARM920T with ARMv4 instruction set will not work
You have already a recent (~2.6.23) Linux kernel with Thumb & MMU & EABI etc support running on your target
Soc/HW has and Linux kernel supports
- Display/frame buffer (touchscreen would be good but optional). Frame buffer has to support double buffer/page flipping.
- Keyboard
- USB (optional)
- RTC (optional?)
- Serial console
- Some storage, sufficient for ~64MB, e.g. NFS or USB stick or NAND or NOR or MMC/SDcard etc. NFS would be easiest for development
- Sufficient main memory (SDRAM) >=32MB. While 32MB seems to be enough to start, system will be really slow then. Therefore 32MB is sufficient for proof of concept, but not for a usable system.

Known to work HW

OMAP1 based boards (ARM v5 ARM926)
OMAP2 based boards (ARM v6 ARM11)
omap2530evm 2430OSK is renamed as 2530EVM based on TI's recommendation (ARM v6 ARM1136jf-s)
Sharp Zaurus SL-C760(PXA255)
Sharp Zaurus SL-C1000(PXA270)
Sharp Zaurus SL-C3000(PXA270)
Armadillo-500 and Armadillo Panel Computer (Freescale i.MX31L ARM11)
OMAP1 based OSK (OMAP5912 ARM926 with only 32MB SDRAM). Really slow, mainly usable as proof of concept.
AM/DM 37x based Hardware AM/DM37xEVM from Mistral

Android internals ML, OMAP ML and Android on N810 page. Working Android port for Nokia Internet Tablets can be found here.

OMAP3430 based Hardware OMAP3430 based Zoom2 from LogicPD. DSP acceleration for multimedia use cases as well as WLAN is also supported.
OMAP3530 based Hardware OMAP3EVM from Mistral (Android runs on ARM Cortex™-A8 Core)
OMAP3530 based BeagleBoard using code from Rupesh Gujare.
OMAP3530 based Hardware TAO-3530 from TechNexion (Android runs on ARM Cortex™-A8 Core)
OMAP3530 based Hardware DevKit8000 from Embest and Timll (Android runs on ARM Cortex™-A8 Core)
OMAP3530 Open-source MID Solution K7 from OpenSourceMID.orgsupports for both WinCE and Android OS

Known to not work HW

Neo 1973 (ARM920T)

[edit] Compiler

Getting Android working on real hardware, you need an ARM EABI (good EABI description, ignore the Debian specific stuff) compatible development environment. I.e., your tool chain, your kernel and user space must be compatible to ARM EABI. If you don't like to create your own ARM EABI compatible compiler, linker, library etc. you should use CodeSourcery's ARM GNU/Linux tool chain.
Note: The naming in the CodeSourcery download section is slightly confusing. You need the ARM GNU/Linux named tool chain which is indeed an ARM GNU/Linux EABI tool chain with glibc. The ARM EABI named tool chain there is something normally known as arm-elf tool chain without any Linux support and without glibc.

[edit] Code

As mentioned above, the Android SDK contains an emulator where a virtual ARM device runs the Android SW on your host PC. The Linux kernel used in this emulator is available in source code. In contrast, the user space file system (applications) is currently only available as binary as part of the SDK.
To get Android running on real HW, currently you need both, matching SDK and kernel source. You need kernel source to extract Android specific patches to add them to your SoC specific kernel. And SDK to get Android user space file system binaries. While getting Android kernel patches is somehow straight forward, extracting user space file system with Android applications in it is a little bit tricky.

[edit] Kernel

On Android project page the source code of the kernel is available. From full kernel tree with Android modifications included you can extract patches. With this, you have to extract the Android specific patches yourself from the complete kernel tree, use already extracted patches or get kernel patches by git.

[edit] Patch extraction

See third paragraph of Benno's Android on NEO 1973 article.

Download matching version (e.g. m5-rc14) of Android kernel source. Besides complete kernel source this will contain Android specific changes.
Download matching (e.g. 2.6.23) stock Linux kernel (or use e.g. git to check out stock kernel version) and diff both kernels to get Android related changes.
As we want to run Android on real hardware, you can throw away all QEMU and Goldfish related changes. If you don't want to use yaffs2 file system (e.g. cause you don't have NAND or have it already in your tree), throw away yaffs2 related changes as well. If you use m5-rc14 (or higher?) you can remove OpenBinder related files (/driver/binder) as well. Result should be a generic, no ARM or OMAP specific Android patch you can apply to your (e.g. 2.6.23) kernel for your ARM based SoC.

Note: There seems to be some effort to make Android kernel patches available in a easier usable format.

[edit] Extracted patches

At some locations there are ready made patches available. The advantage of this is that you don't have to extract the patches yourself. The disadvantage is that you can't always be sure that they contain everything you need and that they match your SDK/user space file system (see below) version.

Benno's no Qemu no goldfish no yaffs2 patch, as of date of Benno's article most probably based on m3-rc20.

Note: Some guys on OMAP mailing list have Android patches extracted (currently from m5-rc14) and are willing to share them. Unfortunately they don't have any permanent web storage yet. If you have and like to help community with providing some web space, contact OMAP list.

[edit] Git patches

There are Android kernel patches available using Android's git repository. But have a look to Brian's notes regarding this.

[edit] File System

Getting user space file system binaries running in emulator extracted is slightly tricky. We have to extract the binaries as currently access to source code have only Google itself and eventually WindRiver.
Again, there are two ways to get user space binaries: Extracting them your self or taking already extracted ones.

[edit] Binary extraction

The user space applications compiled for ARMv5 EABI are part of the Android SDK in system.img and userdata.img in tools/lib/images directory of SDK.

Download SDK and unzip it
system.img and userdata.img are yaffs2 images. There is no way yet to mount them directly on a host to extract their content. An unyaffs tool is missing, so the only way to get the content is to start the emulator and extract the contents from running emulator.

Recently there is an unyaffs available [1]

As file system in emulator as no cp or tar command, we use a statically linked BusyBox cross compiled for ARM and use it inside emulator (get it from Benno or build it your own with above tool chain).
Set path to emulator tools

export PATH=${PATH}:<path_to>/android-sdk_m5-rc14_linux-x86/tools

Create an empty SDcard (image)

mksdcard -l card 100M card.img

Start emulator

emulator -sdcard card.img -console -debug-kernel

You should now see the SDK kernel booting and emulator starting. Wait until the emulator is ready, then send the ARM busybox from the host into the simulated environment:

adb -d 1 push busybox /data/busybox

Inside emulation, set tar (and bzip2) links to busybox, tar /system and /data directories to sdcard.
Shutdown emulator, mount card.img

mount -o loop card.img mnt/

and get the images of system and user data.

If you look at the extracted size of the userdata image, the extracted one is bigger than the original userdata.img. So by the runtime extraction we get some temporary junk in it. For this, untar extracted userdata and remove a least some of the unnecessary stuff:
- Remove all content of data/dalvik-cache/. It holds the decompressed files from the apk packages.
- Remove the static busybox image. We only needed it for extraction and don't need it any more.

Note: Anybody likes to hack this unyaffs tool? Then the system.img and userdata.img extraction would be a lot easier.
Note: A user reports that he doesn't use the extracted data directory at all. He simply mounts a tempfs to /data as it seems that Android runtime creates most (all?) of the necessary files in /data itself at runtime.

[edit] Extracted binaries

At some locations there are ready made binaries available. The advantage of this is that you don't have to extract the binaries yourself. The disadvantage is that you can't always be sure that the images contain everything you need and that the images match your kernel patch (see above) version.

Android file system images, as of date of Benno's article most probably based on m3-rc20.

Note: Some guys on OMAP mailing list have Android binaries extracted (currently from m5-rc14) and are willing to share them. Unfortunately they don't have any permanent web storage yet (~30MB). If you have and like to help community with providing some web space, contact OMAP list.

[edit] Target

This section describes how to configure the software (kernel, file system) to run Android on real hardware target. Before you do this Android specific steps, you should make sure that everything works without any Android specifics. I.e. make sure that the (EABI) kernel boots, you can access all file systems (e.g. NFS or MMC or NOR or NAND etc.) and necessary drivers (e.g. keyboard, touchscreen etc.). Do this with booting into your normal (EABI) file system you always use. We later switch to Android file system then.

[edit] Kernel configuration

Make sure your kernel boots normally on your board. Then enable some Android specific configuration (needs kernel patch extracted above) and make sure that your kernel still boots (with your standard file system).
Note: Some of these settings are valid only for m5-rc14 and newer (?) (Binder config, /sys/android_power output) as it changed from older versions to m5-rc14.
EABI

CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set

THUMB

CONFIG_ARM_THUMB=y

Android drivers

#
# Android
#
# CONFIG_ANDROID_GADGET is not set
# CONFIG_ANDROID_RAM_CONSOLE is not set
CONFIG_ANDROID_POWER=y
CONFIG_ANDROID_POWER_STAT=y
CONFIG_ANDROID_LOGGER=y
# CONFIG_ANDROID_TIMED_GPIO is not set
CONFIG_ANDROID_BINDER_IPC=y
#AshMem 
CONFIG_ASHMEM=y

After you successfully booted the kernel with configuration above (and m5-rc14 kernel patch), make sure you have following /sys files:

/sys/android_power/acquire_partial_wake_lock
/sys/android_power/acquire_full_wake_lock
/sys/android_power/last_user_activity
/sys/android_power/request_sleep
/sys/android_power/acquire_full_wake_lock
/sys/android_power/acquire_partial_wake_lock
/sys/android_power/battery_level
/sys/android_power/battery_level_low
/sys/android_power/battery_level_raw
/sys/android_power/battery_level_scale
/sys/android_power/battery_low_level
/sys/android_power/battery_shutdown_level
/sys/android_power/charging_state
/sys/android_power/release_wake_lock
/sys/android_power/request_state
/sys/android_power/state

[edit] File system configuration

We now switch to Android file system extracted above. This should be established on a device with enough space (> ~64MB) and which is accessible on your target. Options are e.g. NFS, NOR or NAND file system, hard disk or USB storage. In a first step it is sufficient if you are able to manually mount it from your (temporary) standard root file system. In a second step it is an option to use it directly as root fs.
The Android file system we establish here on one of the the storage from above is built from four parts:

Content of system data image extracted above
Content of user data image extracted above (make sure temporary files are removed)
Content of Android ram disk image
Device file system

To create Android file system, take (empty) storage you selected and start with ram disk:
Android ram disk image can be found as ramdisk.img in tools/lib/images of Android SDK. This is a gziped cpio archive:

cp ramdisk.img ramdisk.gz
gunzip ramdisk.gz
cd target_fs
cpio -iv < ../ramdisk

Result of this should be an root file system tree with:

data
dev
etc
init
proc
sbin
sys
system
tmp
var

Directories data, dev and system are empty. Extract content of extracted user data image to /data and system image to /system directories. E.g.

tar xvfj ../system_m5_rc14.tar.bz2 system/
tar xvfj ../userdata_m5_rc14.tar.bz2 data/

Note: This depends on how you named and stored extracted user data and system image above.
Last step is to create some device nodes in /dev you need for running from this Android file system. There are several options how to establish this. One option is to extract device file system from running Android emulator as well. Second option is to use the same device file system you normally use in your standard file system. Choose the easiest way. If you did this, make sure you have Android specific device nodes with correct major/minor numbers as well.
Note: Copying device nodes the best way is to tar them at source and untar them then at target. For device nodes, cp command isn't the best option due to special device node format.

[edit] Start up

Starting Android using the file system and kernel created above, there are three ways:

Directly boot from Android kernel into the Android file system. I.e. let the Android kernel directly start init etc. from Android file system.
First boot from Android kernel into your standard file system. Then "manually" switch over to Android file system and start Android. This "manual" switch can be done using some scripts.
The third way is a mix of the first two ways: Boot into a standard non-Android file system, then switch over to Android but there directly execute init as it would be done by root file system.

[edit] Android root file system

There are several ways to directly start Android from (root) file system created above:

Directly point your kernel to /init in Android file system. Then kernel will use Android's init as init program and execute it without any manual interaction
Use Android's shell and give kernel /system/bin/sh as init program. Then start Android's init manually (/init&) .

[edit] Start via scripts

This section describes the second way to start Android. First boot into your normal file system and then switch to Android file system and start Android "manually", i.e. with help of some scripts. From the initial description of this method, this way is also known as the a.sh way (search for a.sh). The scripts used for this depend on your local configuration. You can take below scripts as example and adapt them for your local use.
These example scripts are used to first boot into standard root file system (e.g. JFFS2 in NOR) and then to mount (/mnt/usb) and start Android located on an ext2 formatted USB stick.
start_android.sh in standard root file system:

#!/bin/sh -x
echo "Starting Android..."
fsck.ext2 -pv /dev/sda1
mount /dev/sda1 /mnt/usb
rm -f /mnt/usb/tmp/*
umount /proc
umount /sys
mount -t proc proc /mnt/usb/proc
mount -t sysfs sysfs /mnt/usb/sys
umask 000
chroot /mnt/usb/a.sh

a.sh to start Android at Android file system:

#!/system/bin/sh -x

export PATH=/sbin:/system/sbin:/system/bin:$PATH
export LD_LIBRARY_PATH=/system/lib
export ANDROID_ROOT=/system
export ANDROID_ASSETS=/system/app
export ANDROID_DATA=/data
export EXTERNAL_STORAGE=/sdcard
export DRM_CONTENT=/data/drm/content

/system/bin/app_process -Xzygote /system/bin --zygote &
/system/bin/dbus-daemon --system &
runtime &
/system/bin/sh

Notes:

fsck.ext2 -pv /dev/sda1: Make sure ext2 file system is clean. ext2 doesn't like unclean switch off while debugging Android start up ;)
rm -f /mnt/usb/tmp/*: Remove Android temporary files before starting Android.
mount proc and mount sys: This has to be done somewhere. Depending on your scripts, you can do it in a.sh as well.
runtime: For debugging use here /system/bin/strace -f -ff -tt -s 200 runtime&.
Starting runtime in background (&) and calling /system/bin/sh afterwards is optional. It gives you the option to have a shell at Android startup to e.g. observe /proc/meminfo, top or ps. Only useful if strace isn't enabled or not so noisy ;)

[edit] Start init via scripts

This third way is a mixture of the first two ways: Boot into a standard non-Android file system, then switch over to Android but there directly execute init as it would be done by root file system.
From standard non-Android file system this switch can look like:

mount /dev/sda1 /mnt/usb
rm -f /mnt/usb/tmp/*
umask 000
chroot /mnt/usb /init

[edit] Debugging

Strace: The main debugging help currently known is strace. Again, a statically linked one is used.
- You should invoke strace with -f -ff -tt -s 200 options, e.g.

strace -f -ff -tt -s 200 /system/bin/runtime

[edit] FAQ

[edit] Kernel patch

Q: Above section about kernel patch extraction mentioned that not all changes in Android kernel compared to stock kernel are needed for Android on real HW (e.g. Goldfish, QEMU and YAFFS2 related changes). What exactly do I need?
A: Regarding m5-rc14 and kernel 2.6.23 the (changed) files below seem to be sufficient to run Android on real HW:

arch/arm/Kconfig
arch/arm/kernel/process.c
arch/arm/kernel/signal.c
drivers/android/alarm.c
drivers/android/android_gadget.c
drivers/android/android_kernel_debug.c
drivers/android/android_kernel_debug.h
drivers/android/binder.c
drivers/android/Kconfig
drivers/android/logger.c
drivers/android/Makefile
drivers/android/power.c
drivers/android/ram_console.c
drivers/android/timed_gpio.c
drivers/input/evdev.c
drivers/Kconfig
drivers/misc/Kconfig
drivers/misc/lowmemorykiller/lowmemorykiller.c
drivers/misc/lowmemorykiller/Makefile
drivers/misc/Makefile
fs/inotify_user.c
include/linux/android_alarm.h
include/linux/android_gadget.h
include/linux/android_power.h
include/linux/android_timed_gpio.h
include/linux/binder_module.h
include/linux/binder_type_constants.h
include/linux/logger.h
kernel/power/process.c
drivers/Makefile

Kernel patches to run android on n8x0 here.

[edit] OpenBinder

Q: When I extract the kernel patch, I additionally get a drivers/binder/ directory. Why isn't it listed/needed above?
A: The drivers/binder/ directory seems to contain OpenBinder. In Android m5-rc14 this seems to be replaced by drivers/android/binder.c. Therefore we don't need drivers/binder/ with m5-rc14 any more. Note that new binder.c in drivers/android is configured with CONFIG_ANDROID_BINDER_IPC, while drivers/binder was configured by (obsolete) CONFIG_BINDER.

[edit] Devices nodes

Q: Do I need special devices nodes? Which?
A: Above we only extracted system and userdata image. If you like, you can extract /dev entries as well. However, starting Android's runtime under strace control should give you a list which devices will be opened. Besides the standard ones you will need (incomplete?):

crw-rw-rw- 1 root root 10,  x Jan  1 00:00 binder
crw-rw-rw- 1 root root 10,  x Jan  1 00:00 log/radio
crw-rw-rw- 1 root root 10,  x Jan  1 00:00 log/events
crw-rw-rw- 1 root root 10,  x Jan  1 00:00 log/main
crw-rw-rw- 1 root root 10,  x Jan  1 00:00 alarm
crw-rw-rw- 1 root root 10,  x Jan  1 00:00 eac
crw-rw-rw- 1 root root 29,  0 Jan  1 00:00 graphics/fb0
more ?

[edit] /dev/xxx minor numbers

Q: Which minor number will I need for /dev/xxx entries above? E.g. for /dev/binder?
A: The major number 10 (major number for "misc" devices) above are for new drivers of m5-rc14. The minor numbers would be as given by cat /proc/misc. They are somehow board dependent and may change.
E.g. in m5-rc14 emulator you may get:

# cat /proc/misc
58 binder
59 log_radio
60 log_events
61 log_main
62 alarm
 1 psaux
63 eac

With kernel patch on real HW you may get:

# cat /proc/misc
59 binder
60 log_radio
61 log_events
62 log_main
63 alarm

[edit] /dev/fb0

Q: I have /dev/fb0, is this correct?
A: With m5-rc14 Google switched frame buffer interface to /dev/graphics/fb0. So you need:

crw-rw-rw- 1 root root 29,  0 Jan  1 00:00 /dev/graphics/fb0

[edit] Blank screen

Q: I did all steps like above, strace output doesn't show any obvious errors, but if I start Android calling runtime I simply get a blank screen. No output (no ANDROID string, no red cycle eye, nothing), just blank screen. As when the frame buffer screen saver starts after ~10min. I use m5-rc14.
A: With m5-rc14 the frame buffer handling changed. You now need a frame buffer driver which supports double buffer/page flipping. Observe the output of strace. If you get:

...
writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38
open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21
ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0
ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0
writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, {"page flipping not supported (yres_virtual=640,  requested=1280)\", 63}], 3) = 82
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0
...

your frame buffer driver doesn't support page flipping.
Note: For above output, strace has to be invoked with -f -ff -tt -s 200 options, else you wouldn't see this.

[edit] Page flipping frame buffer

Q: Okay, I get this page flipping not supported message above and have a blank screen. So my frame buffer driver doesn't support double buffer/page flipping. What do I have to change in frame buffer driver to support double buffer/page flipping?
A: This depends on frame buffer driver.

For OMAP you can try following hack:

Index: linux-omap-2_6_23/drivers/video/omap/omapfb_main.c
===================================================================
--- linux-omap-2_6_23.orig/drivers/video/omap/omapfb_main.c
+++ linux-omap-2_6_23/drivers/video/omap/omapfb_main.c
@@ -168,7 +168,7 @@ static int ctrl_init(struct omapfb_devic
                /* 12 bpp is packed in 16 bits */
                if (bpp == 12)
                       bpp = 16;
-               def_size = def_vxres * def_vyres * bpp / 8;
+               def_size = def_vxres * def_vyres * 2 * bpp / 8;
                fbdev->mem_desc.region_cnt = 1;
                fbdev->mem_desc.region[0].size = PAGE_ALIGN(def_size);
        }
@@ -415,6 +415,7 @@ static void set_fb_fix(struct fb_info *f
        }
        fix->accel              = FB_ACCEL_OMAP1610;
        fix->line_length        = var->xres_virtual * bpp / 8;
+       fix->ypanstep           = 1;
 }

 static int set_color_mode(struct omapfb_plane_struct *plane,
@@ -1471,7 +1472,7 @@ static int fbinfo_init(struct omapfb_dev
        var->xres = def_vxres;
        var->yres = def_vyres;
        var->xres_virtual = def_vxres;
-       var->yres_virtual = def_vyres;
+       var->yres_virtual = def_vyres * 2;
        var->rotate       = def_rotate;
        var->bits_per_pixel = fbdev->panel->bpp;

(anybody with clean patch? ->contact)

For the new omap2 dss driver (based on 2.6.29), please try following hack:

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 1042c3b..8f87b78 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1315,7 +1315,7 @@ static int omapfb_alloc_fbmem_display(struct fb_info *fbi, unsigned long size,
       oldw, oldh, w, h);
    }

-  size = w * h * bytespp;
+  size = w * h * bytespp * 2;
  }
 
  if (!size)
@@ -1648,7 +1648,7 @@ int omapfb_fb_init(struct omapfb2_device *fbdev, struct fb_info *fbi)
   }

    var->xres_virtual = var->xres;
-   var->yres_virtual = var->yres;
+   var->yres_virtual = var->yres * 2;

   if (!var->bits_per_pixel) {
    switch (display->get_recommended_bpp(display)) {
@@ -1669,7 +1669,7 @@ int omapfb_fb_init(struct omapfb2_device *fbdev, struct fb_info *fbi)
   var->xres = 320;
   var->yres = 240;
   var->xres_virtual = var->xres;
-   var->yres_virtual = var->yres;
+   var->yres_virtual = var->yres * 2;
   if (!var->bits_per_pixel)
    var->bits_per_pixel = 16;
  }

For Zaurus/pxafb have a look to following solution. See OESF as well.

[edit] Android start crashes

Q: When I start Android like described above, xxx strangely crashes and/or I get strange error messages. I don't use recent (m5-rc14) Android.
A: Make sure that you use kernel patch and file system from most recent Android release (currently m5-rc14). Don't mix kernel patch and file system from different versions.

[edit] Power management

Q: I did anything like described above. Systems starts properly, I get Android home screen. But then, system goes to suspend mode and never wakes up. Even if I only use fake Android power management.
A: unknown yet :( There is some guessing and some workaround.

Some guess from androidzaurus.

Workaround reported from Anil:

Adding keypad support (e.g. on Mistral's OSK2530EVM, OMAP2430 based platform) and "waking" Android while it switches to suspend wakes it again. When Android goes into power saving mode, it prints the following messages

android_power_suspend: enter suspend
android_power_suspend: exit suspend, ret = -38
android_power_suspend: pm_suspend returned with no event

And then, if the UP or DOWN key is pressed on the HW keypad, the system comes back to normal mode and resumes activity with the below given console messages

android_power_wakeup 2->0 at 447592867845
active wake lock PowerManagerService
active wake lock KeyEvents
android_power_suspend: done

[edit] TLS issue

Q: What is this TLS issue?
A: Some newer ARM processors support TLS in hardware. With current (m5-rc14) Android release this isn't supported yet.

[edit] TLS issue and processors

Q: Which processors have this TLS issue?
A: ARMv6K (MPCORE) and ARMv7 (Cortex). Regarding OMAP, this is OMAP3 (Cortex). OMAP1 (ARM9) and OMAP2 (ARM11) don't have this issue.

[edit] TLS issue workaround

Q: I'd like to use (m5-rc14) Android on processors with TLS issue, what can I do?
A: On older ARM's the TLS register is emulated (trapped by the kernel) and on newer ARM's the register actually exists. Android (at least the version for Goldfish) is compiled with the assumption that the TLS register is emulated and thus expects the kernel to trap it. A non-user defined config option called HAS_TLS_REG is set based on the processor version that is configured which controls if the trap code gets added to the kernel. So to get around the TLS issue, you will need to force the option ON even if the processor supports the TLS register. You can force it on for e.g. OMAP3 by doing the following. However, once source is available, you really don't want to do this as it does cause a performance hit.

diff -Naur 2.6_kernel-orig/arch/arm/mm/Kconfig 2.6_kernel-android/arch/arm/mm/Kconfig
--- 2.6_kernel-orig/arch/arm/mm/Kconfig   2007-11-20 12:09:42.000000000-0600
+++ 2.6_kernel-new/arch/arm/mm/Kconfig   2007-12-08 22:23:04.000000000-0600
@@ -675,7 +675,7 @@
 config HAS_TLS_REG
   bool
   depends on !TLS_REG_EMUL
-  default y if SMP || CPU_32v7
+  default y if SMP || CPU_32v7 && !ARCH_OMAP
   help
     This selects support for the CP15 thread register.
     It is defined to be available on some ARMv6 processors (including

(Thanks to Keith Deacon!)
Note: A user report wasn't quite successful regarding this.

[edit] Red cycle eye runtime speed

Q: The red cycle eye runs very fast on my board, and the system_server take almost 100% CPU
A: This is usually indicative of lack of vsync/pageflip in the fb driver. The surfaceflinger believes it will be limited by the vsync rate and the startup animation depends on that.

[edit] File not found

Q: At Android start up I get some File not found ... error messages like:

Prepping: /system/app/AlarmClock.apk:/system/app/AlarmProvider.apk:...
File not found: /system/app/AlarmClock.apk
File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Anagrams.apk
...
File not found: /system/app/Vending.apk
File not found: /system/app/VoiceDialer.apk
File not found: /system/app/Voicemail.apk
File not found: /system/app/YouTube.apk
Prep complete

Do I have to care about these?
A: No, it doesn't seem so. See Benno's blog, section Manual startup.

[edit] Limited main memory

Q: I have only limited main memory (SDRAM, e.g. 32MB). The system basically starts, but it is really sssllllooooowwww, slightly unusable. More or less only a proof of concept. Can I do anything to use Android even on systems with limited main memory?
A: Try to enable lowmemorykiller:

drivers/misc/lowmemorykiller/lowmemorykiller.c

For this, in kernel enable

CONFIG_LOW_MEMORY_KILLER=y

in Device drivers -> Misc devices. At Android startup this then results in messages like

...
send sigkill to 920 (app_process), adj 1, size 1838
...

[edit] Some buttons work, some not

Q: Some buttons work, some buttons don't work ... wrong mapping. How to see what key codes certain buttons are bound? And how to edit the mapping in Android?
A: From Brian at OMAP ML:
There's a brute force approach to sorting out input events: run getevent on the emulator and on the target hardware and compare the results. It's in /system/bin. Keylayouts live in /system/usr/keylayout/*.kl and are used to translate from the raw input event codes to android keycodes. Keymaps live in /system/user/keychars/*.kcm.bin (undocumented binary format right now, sorry) and are used to describe how the key events and modifiers and such are related.

[edit] Filesystem, JFFS2 and SIGSEGV

Q: Which file system should I use to store Android user files? Is JFFS2 okay? I use JFFS2 and get SIGSEGVs. What can I do?
A: Don't use JFFS2 as file system for Android. Android does not support JFFS. Use an ext2/3 formatted medium. Or use YAFFS2 if you use a NAND device (as emulator does).

[edit] Using JFFS2

Q: Okay, I understand from above that Android doesn't support JFFS2. But, maybe there is a hack to try?
A: You could try what Brian reports:
Using JFFS2, what you're might seeing here is the property service in init failing to create and mmap it's arena, which it tries to do in /, which in emulator world is initramfs. The android init/boot model is a little different in that android don't pivot over to a root filesystem, android mounts the system, data, etc partitions under the ramfs on /.
You might be able to hack around this by editing the string "/system_properties" to "/tmp/em_properties" or something like that, assuming you have tmpfs mounted on /tmp.

[edit] Nokia N8x0 and Android SDK

Q: I'd like to run Android on Nokia N8x0 (link 1, link 2). Which Android SDK should I use? Can I use m5-rc14/15 SDK?
A: You have to use m3 user space. This works well with m5-rc14/15 kernel patches. So best combination is to use m3 user space with m5 kernel.
m5 user space will not work, because it needs page flipping frame buffer and N8x0 fb driver doesn't support this.
For working android port: "Nitdroid"

[edit] N8x0 and recent OMAP git kernel

Q: I'd like to use recent OMAP git kernel on N8x0. What do I need to run git kernel on N8x0?
A: Have a look to Tony's booting nokia N8x0 with current OMAP git kernel.

[edit] N810 keys

Q: How do I get the N810 keyboard to work with Android?
A: Try the following changes to get most of N810 keys working with Android, except Fn and the numbers:

Just update one file: /system/usr/keylayout/qwerty.kl

-key 158   BACK              WAKE_DROPPED
+key 1     BACK              WAKE_DROPPED
 key 230   SOFT_RIGHT        WAKE
 key 60    SOFT_RIGHT        WAKE
 key 107   ENDCALL           WAKE_DROPPED
 key 62    ENDCALL           WAKE_DROPPED
-key 229   SOFT_LEFT         WAKE_DROPPED
+key 62    SOFT_LEFT         WAKE_DROPPED
 key 59    SOFT_LEFT         WAKE_DROPPED
 key 139   SOFT_LEFT         WAKE_DROPPED
 key 228   POUND
 key 227   STAR
 key 231   CALL              WAKE_DROPPED
 key 61    CALL              WAKE_DROPPED
-key 232   DPAD_CENTER       WAKE_DROPPED
+key 96    DPAD_CENTER       WAKE_DROPPED
 key 108   DPAD_DOWN         WAKE_DROPPED
 key 103   DPAD_UP           WAKE_DROPPED
-key 102   HOME              WAKE
+key 63    HOME              WAKE
 key 105   DPAD_LEFT         WAKE_DROPPED
 key 106   DPAD_RIGHT        WAKE_DROPPED
-key 115   VOLUME_UP
-key 114   VOLUME_DOWN
+key 65    VOLUME_UP
+key 66    VOLUME_DOWN

[edit] N8x0 touchscreen

Q: Is there any way to get N8x0 touchscreen working with Android?
A: Yes. There is a patch you can apply to a nokia+android patched 2.6.21 kernel and you should have a working touchscreen.

[edit] Nokia770 support

NITdroid project provide some images to flash on your n700, see tutorial and demo at :
http://www.newlc.com/en/nitdroid-demo-gnulinux-android-nokia-n770-0

[edit] HW interfaces support

Q: Which hardware interfaces or kernel drivers does current Android support?
A: See discussion on OMAP ML:

> I was able to add support for the keypad, touch and network in Android,
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D
> acceleration, battery etc. are not integrated with Android right now. I
> would appreciate if you could throw some light on these open issues. How
> exactly can these interfaces be integrated with Android? 

We're trying to use the standard kernel/driver interfaces when possible,
but for things that may have a good deal of variation in implementation,
we're looking to provide a very thin "hardware interface library" layer
to adapt between the bottom of the userspace stack and the drivers or
whatnot for specific hardware platforms.  

We'll continue to adopt standardized kernel solutions as they become
available -- We're now using the power supply framework in 2.6.24 for
monitoring battery/charge state (post M5 SDK -- it'll be in the next 
release), for example.

[edit] Links

"Nitdroid" -project. Sources and precompiled (ready to use) binaries for Nokia Internet Tablets.
Mistrals' Android Competency Center
Android on the OMAP34x Zoom Mobile Development Kit
Android homepage
Android Camera Application using V4L2 APIs, on OMAP EVM board
Bennos blog with lot of reverse engineering info about Android
Android on Zaurus
Korea Android Community

Note:Connect this site using http://www.google.com/translate website.

Linux devices about Penguinistas hack Android onto real hardware
Google Android on Working Target
Android discussion groups. These concentrate more on Android application programming. Not really HW and processor related.
Open Embedded Software Foundation Android forum. Discussion, support and general information about running Android on a handheld.
Porting Android to real HW at Android internals list
Android Porting to Real Target HW
Android on Nokia 8xx
Tony's booting nokia N8x0 with current OMAP git kernel
Robert Love talks about Google Android. Recorded at LUG Radio Live USA 2008 at the Metreon Theatre, San Francisco.
Rupesh Gujare announces availability of an Android file system image for the BeagleBoard and provides a video and kernel + root file system.

Note: Some of the infos in above links are from the first versions of Android. Seems that with newer versions (e.g. m5-rc14) some parts changed, e.g. binder interface and /sys/android_power interface.

[edit] Contact

See OMAP mailing list for more information.
This page is distilled by Dirk Behme and information added by Lim,GeunSik.

[edit] Videos

Nitdroid (Android for Nokia Internet Tablets) on Nokia n810:

(Videos above are outdated and from very early stage)
NITdroid on nokia770 :

[edit] Screenshots

Android m5-rc14 home screen with kernel 2.6.23 on OMAP5912 OSK:

Android m5-rc14 kernel + m3 image, on a Nokia N810:

Android m5-rc15 home screen with kernel 2.6.18 on armadillo-500 1136 (YouTube Movie)

Android m5-rc14 home screen with kernel 2.6.19 on OMAP2430 OSK:

-If you have unstable sdcard, You will meet for Looping of "Red Eye" Status.

Android camera application using V4L2 APIs, on TI OMAP EVM board:

[[2]]

Android m5-rc14(2.6.23) on Nokia's n810 Tablet

Android Cupcake Ver 1.0(2.6.27) on OMAP3EVM(ARM Cortex-A8)

NITdroid on nokia770 :

[[3]] (larger images in tutorial above)

Retrieved from "http://elinux.org/Android_on_OMAP"

Categories: Linux | OMAP | Android

Porting Android to a new device

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 08:33:00 +0000

The paper was written by Peter McDermott, an American expatriate who lives in Beijing and serves as CEO of NthCode. NthCode is a consulting firm specializing in Linux device development, in markets that include mobile phones, set-top boxes, and "converged" multimedia devices. Enjoy . . . !

Porting Android to a new device

by Peter McDermott

Executive summary

If you're having trouble estimating the time and complexity of porting Google's Android mobile platform to your embedded device, our experience porting Android to a Nokia N810 Internet Tablet may provide you with useful information.

Android overview

Android is a mobile phone software platform created by Google. It is based on the Linux kernel, a number of software libraries written in 'C,' a Java-like virtual machine for running application code, and a full suite of mobile phone applications.

Android costs nothing and the source code is freely available. Its license terms (see the Apache license link at the end) are commercial-friendly, saying, in essence, "Do what you like with it, just don't sue us if something goes wrong." The one exception to this rule is the Linux kernel, which is licensed under the GNU Public License. Because of this, manufacturers must release their device's Linux kernel source code after product shipment.

Taiwan's HTC shipped the first Android phone, the G1, in October 2008. Other mobile manufacturers, including Motorola, LG, and Samsung are all reportedly creating Android-based phones. Additionally, from NthCode's home base in China, we see many startups and smaller manufacturers leveraging Android in an attempt to gain a foothold in the global smartphone market.

T-Mobile G1, the first Android phone

The Android platform provides all the services one would expect in a mobile phone, including phone calling, networking, messaging, and multimedia. Our analysis of the source code so far is that these services are complete and built on top of an excellent architecture, but do not implement every last feature found in modern mobile phones. This is the 1.0 release, after all.

For application developers, Android builds on top of the popular open-source Eclipse integrated development environment. Developers can use Eclipse to write Java applications, which are then compiled to Java bytecode before being translated for running on Android's Dalvik Virtual Machine (VM).

Google claims their Dalvik VM runs more efficiently in terms of speed and memory tradeoffs than Java -- slyly suggesting that Google wrote their own VM for performance reasons. However, while we haven't seen supporting data, we suppose Google really created Dalvik to escape from needing to cede control or pay a license fee to Sun, the creator and steward of the Java platform.

By translating from Java to Dalvik bytecode, Google is able to leverage the mature tools and large existing community of Java developers. The downside is that developers will need to take the additional step of running the Google translation tool on their compiled Java code before their application will run on an Android phone (Google automates this step in their Android Eclipse plug-in, however).

Android emulator screenshot

Google also provides an Android emulator. The emulator is a virtualized ARM microprocessor that runs the same system code -- and almost exactly the same Linux kernel -- that runs on a device. Google provides an Eclipse add-on so that Android programs can be compiled and debugged in Eclipse while running in their emulator. The Android emulator is as complete an emulator as we have ever seen -- just make sure your developers have enough RAM in their PCs to be able to run Eclipse and the emulator together.

So what's in it for Google?

Google has given mobile phone manufacturers everything they want -- a free, open, mobile operating system -- and, in return, only asked that the devices they create can run Android applications. We can only speculate that Google expects to eventually earn more from consumers using Google services on Android devices than it costs Google to develop and maintain Android.

Overview of the Nokia N810

We work with embedded Linux systems at NthCode, so we thought it would be a fun challenge (and would help with a project we're working on) if we could port Android to an existing Linux device.

Luckily, we already had two Nokia N810 Internet Tablets in the office. The N810 is a handheld mobile device that comes with a high-resolution 4.1-inch touch screen and a slide-out QWERTY keyboard. The N810 has a 400 MHz Texas Instruments OMAP 2420 CPU, 128MB RAM, and WiFi networking. The one thing the N810 can't do is make phone calls -- this is why Nokia markets it as an Internet Tablet that can surf the web, rather than a phone. At the time of this writing, the N810 costs about USD $425.

An active community of enthusiasts enjoys hacking the N810's Linux-based software. While some of those enthusiasts had already ported a pre-release version of the Android SDK to the N810, we discovered that no one had yet ported the Android 1.0 release to it. So we decided to see how long it would take us, and what we could learn in the process.

Development steps

As mentioned earlier, the Android system software runs on top of a Linux kernel. This Linux kernel provides services to applications -- such as file access, process scheduling, and inter-process communication.

Google made a number of modifications to the standard Linux kernel for Android. Likewise, Nokia modified the standard Linux kernel to support their hardware, such as the keypad, touch screen, and file system.

We quickly discovered that Nokia's N810 changes are made against an earlier 2.6.21 Linux kernel. And, unlike earlier Android prereleases, the Android 1.0 modifications are made against a later 2.6.25 Linux kernel. We investigated and discovered that between these two versions, a year had elapsed and the Linux community had made thousands of changes to kernel source code.

So, to make both Nokia's and Google's modifications work together on the N810 we either needed to port the N810 changes to work on the newer 2.6.25 Linux kernel, or port the Android changes to the N810's earlier 2.6.21 Linux kernel.

What did Google change in the kernel?

We checked the differences between the Android kernel and the standard Linux kernel and found that Google had changed 75 files and added an additional 88. We have prepared an annotated list of changed files at the end of this document, and a brief summary here.

Goldfish -- 44 Files -- The Android emulator runs a virtual CPU that Google calls Goldfish. Goldfish executes ARM926T instructions and has hooks for input and output -- such as reading key presses from or displaying video output in the emulator.

These interfaces are implemented in files specific to the Goldfish emulator and will not be compiled into a kernel that runs on real devices. So we safely ignored these files in our work.
YAFFS2 -- 35 Files -- Unlike PCs, which store files on disks, mobile phones store files in sold-state flash memory chips. The HTC G1 uses NAND flash, a type of flash memory that is becoming more popular due to its combination of high density and low cost.

YAFFS2 is an acronym for "Yet Another Flash File System, 2nd edition." It provides a high-performance interface between the Linux kernel and NAND flash devices. YAFFS2 was already freely available for Linux. However, it is not part of the standard 2.6.25 Linux kernel, and so Google added it to Android.
Bluetooth -- 10 files -- Google made changes to 10 files in the Bluetooth communications stack. These changes fix apparent bugs related to Bluetooth headsets, and add Bluetooth debugging and access control functions.
Scheduler -- 5 files -- The Android kernel also contains slight changes to the CPU process scheduler and time-keeping algorithms. We don't know the history of these changes, and the impact was not evident based on a cursory examination.
New Android Functionality -- 28 files -- In addition to bug fixes and other small changes, Android contains a number of new subsystems that are worth mentioning here, including the following:
- IPC Binder -- The IPC Binder is an Inter-Process Communication (IPC) mechanism. It allows processes to provide services to other processes via a set of higher-level APIs than are available in standard Linux. An Internet search indicated that the Binder concept originated at Be, Inc., and then made its way into Palm's software, before Google wrote a new Binder for Android.
- Low Memory Killer -- Android adds a low-memory killer that, each time it's called, scans the list of running Linux processes, and kills one. It was not clear in our cursory examination why Android adds a low-memory killer on top of the already existing one in the standard Linux kernel.
- Ashmem -- Ashmem is an Anonymous SHared MEMory system that adds interfaces so processes can share named blocks of memory. As an example, the system could use Ashmem to store icons, which multiple processes could then access when drawing their UI. The advantage of Ashmem over traditional Linux shared memory is that it provides a means for the kernel to reclaim these shared memory blocks if they are not currently in use. If a process then tries to access a shared memory block the kernel has freed, it will receive an error, and will then need to reallocate the block and reload the data.
- RAM Console and Log Device -- To aid in debugging, Android adds the ability to store kernel log messages to a RAM buffer. Additionally, Android adds a separate logging module so that user processes can read and write user log messages.
- Android Debug Bridge -- Debugging embedded devices can best be described as challenging. To make debugging easier, Google created the Android Debug Bridge (ADB), which is a protocol that runs over a USB link between a hardware device running Android and a developer writing applications on a desktop PC.
  
  Android also adds a new real-time clock, switch support, and timed GPIO support. We list the impacted files for these new modules at the end of this document.
Power Management -- 5 files -- Power management is one of the most difficult pieces to get right in mobile devices, so we split it out into a group separate from the other pieces. It's interesting to note that Google added a new power management system to Linux, rather than reuse what already existed. We list the impacted files at the end of this document.
Miscellaneous Changes -- 36 files -- In addition to the above, we found a number of changes that could best be described as, 'Miscellaneous.' Among other things, these changes include additional debugging support, keypad light controls, and management of TCP networking.
NetFilter -- 0 files -- Finally, our change list showed Netfilter as having 22 changed files. However, examination showed the only difference was the capitalization of the filenames (xt_DSCP.c vs. xc_dscp.c). The contents of the files were all identical. So we ignored these files in our port.

Port the N810 changes forward or the Android changes backward?

As you can see from the above, Android makes significant changes to the standard Linux kernel. Additionally, Google's system software checks to make certain the kernel version is 2.6.25 or newer. This led us to wonder if Android requires features in the standard 2.6.25 Linux kernel that are not in earlier releases.

On the other hand, the N810 kernel changes were only to add hardware support. Nokia did not change core operating system services or add new interfaces.

We decided that we would have a higher chance of success by porting the N810 changes forward to the 2.6.25 Linux kernel.

So, without further ado...

Step 1: Port the N810 kernel changes to the 2.6.25 Linux kernel

This work took one developer seven days to complete, and included the following steps:

Downloaded the latest Linux-OMAP-2.6 kernel from Montavista
Selected the 2.6.25 version from the kernel download (used 'git reset --hard v2.6.25-omap1'))
Patched the 2.6.25 kernel with the following patches from the N810's 2.6.21 kernel:
- N810 Multi Media Card (MMC) driver
- N810 I2C serial bus controller chip driver
- N810 touch screen driver
- N810 keyboard mapping
- N810 audio and video DSP driver
- N810 DMA driver
- N810 board revision patch

After a number of software build/flash/test/debug cycles, our new kernel was able to boot the N810's default software and function well.

One issue we did have is that the kernel driver for the CX3110 WiFi chip is provided as a binary-only kernel module, not source code that we could recompile on the new kernel. This meant that we were not able to make our new kernel support WiFi on the N810.

This is an important note for those trying to do similar ports: if you have binary-only drivers, make sure they've been compiled against the kernel baseline that you plan to use.

Step 2: Add the Android kernel patches to the 2.6.25 N810 Linux kernel

With our new N810 Linux kernel up and running, we could now apply the Android patches. This was mostly straightforward and took one developer two and a half days of applying patches, flashing the kernel, and verifying the patches worked.

If you are using a kernel baseline different from the one in the Android SDK, you should plan to spend more time and resources to make it work correctly.

Luckily, the Android and N810 patches do not touch any of the same kernel parts. This made merging these two change sets much easier.

Step 3: Bring-up Android on our new kernel

After two weeks of patching and testing, we were finally ready to try to boot the full Android system. Software development would not be any fun if everything worked the first time, so, luckily, there were issues (that is a joke).

Here is the list of what we worked through:

The N810's jffs2 file system lacked a feature Android needs in the mmap system call
So we switched to using the ext2 file system, but it reported data corruption
So we switched to using the ext3 file system, and the corruption went away
The system hung while booting, and while we were trying to debug, it would reboot
We discovered the watchdog timer was rebooting the system, so we disabled it
After that, the system sometimes successfully booted, but the screen was blank
We could see graphics after we applied a double-buffered video patch to the N810
After this, we could sometimes boot to the home screen, but the system often crashed
We recopied some system libraries to the N810, and the crashes went away
We enabled the touch screen by changing a power setting in the system software
We enabled the keypad by fixing a keymap file in the system software

And, finally, afer 19 days, it worked. The Android robot would show while powering up, and then we could see the main menu and use the applications.

Android 1.0 booting on the N810
(Click to play)

Step 4: Play Around

This, of course was the pay off. If you get this far, we recommend that you take a photo and email it to your nerdiest friends and colleagues to show off your accomplishment.

Android 1.0 running on Nokia's N810 Internet tablet
(Click to enlarge)

Next steps

We want to be able to create our own Android applications and run them on the N810. To do that, we will need to add support for the Android Debug Bridge, fix an intermittent system crash, and see if we can enable battery charging when the power supply is plugged in. Additionally, our application needs Internet access, so we either need to make the WiFi chip work, or enable USB Ethernet to send network data through the USB cable to a host PC, which can then route the N810's data to the Internet.

Finishing up

Before we're done, we will release the changes we made back to the Android and N810 communities so that they can take advantage of the work we have done and have a bit of fun.

Things to consider in your project

If you're porting Android to a new device, we recommend you consider the following points:

First, this is a just a milestone along the way to any kind of shipping product. We still have work to do before the N810 will be good enough for us to develop custom applications. Likewise, the N810 isn't a phone, so we didn't have to spend time debugging the call stack. And then there are the pieces that don't work -- power management, WiFi, etc. -- that could all take more time to make work than we spent on this initial port. So the hard work is ahead, not behind.

Second, the N810 is a shipped commercial product that has gone through Nokia's strenuous quality control processes and is well loved by lots of hackers. We have worked on other projects with flakey hardware and no vendor support (yeah, that was a huge mistake -- and it was made even worse by doing it fixed-bid). If you are porting Android to your own hardware, be sure to factor time and resources into dealing with hardware risks. We highly recommend that you make sure there are software people assigned to making the hardware drivers work.

Third, figure out which baseline kernel version you will use at the start. This way, you can verify or add tasks for making sure your hardware has the kernel drivers developed for that version of the Linux kernel. And since an outside vendor often provides binary drivers, make certain that you will have those drivers compiled against your Linux kernel when you need them.

Fourth, use the right tools and processes -- preferably the same ones that the Linux and Android developers use. We've worked with big companies who import open-source software into closed-source development models. While this makes it easier to get started, these teams later pay a price when they are not able to easily merge new versions of open-source software into their code base. Additionally, if your developers want to use Windows at all, we recommend you push them out of their cocoon and into the Linux world. A highly effective team would be one running Linux on their desktop, git for source control, and vim or emacs to edit 'C' code.

Finally, assemble the right team. While we're new to Android, we've been hacking embedded Linux systems for a long time. So check your teams' experience and plan accordingly.

Saying thanks

First, I'd like to thank Tang Yongjun, the NthCode developer who actually ported Android to the N810. I don't know that I would have been as patient as he was.

He and I would both like to also thank PenguinBait, B-man, and QWERTY-12 (yes, awesome names), who made the original port of the pre-release Android SDK to the N810. We were able to follow many of their steps to make our port of the Android 1.0 release easier.

Finally, this is a living document. If you spotted a mistake, or think others would benefit some piece of piece of information we don't have here, please email me so I can consider the change.

Download

We have placed our kernel patch, a complied kernel image, a compiled userspace image, and a few notes at the following SourceForge.Net page: Android-N810 Downloads.

Appendices

Annotated index of Android kernel source diffs

Resources

Apache Open Source License
GPL License
Montavista's Linux-OMAP Repository
The Original Android N810 port
Elinux.org's Wiki for Android on OMAP
Maemo Wiki About Updating N810 Firmware

This paper was originally published by NthCode, here. It is reproduced with permission.

About the author -- Beijing resident and American expatriate Peter McDermott founded NthCode in 2005 to tap into the talent he saw in his Chinese co-workers while creating some of the world's first Linux-powered mobile phones. Peter enjoys running NthCode to this day and maintains a personal weblog, Beijing Analog to Digital where he discusses technology, business, and life in Beijing. Click the photo at left for an NthCode staff photo.

This overview of porting steps was seen on the android-porting list:

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 07:56:00 +0000

This overview of porting steps was seen on the android-porting list:
See http://www.mail-archive.com/android-porting@googlegroups.com/msg06721.html
This glosses over all the kernel work for a new board, and the android-specific kernel patches, but has some good discussion about the flash partitioning and file system bringup process.

If the linux kernel is up and running with all drivers in.
(particularly touchscreen and display) it shouldn't be too bad.

IHMO, the easiest way to get you running is to aggregate the initial
ramfs built into the kernel with the Android build, the root Android
root filesystem (system), and the user data section (mounted as /data
I believe) into one root filesystem.

You can then take that root filesystem as one tarball.

Modify the NAND partitioning of the kernel to set aside space for the
whole Android rootfs, and of course rebuild the kernel. (Be sure yaffs
support is in the kernel) Also no need for a ramfs at this point, just
have the kernel look to mtd2 for it's root filesystem, which will be
jffs2

Create yourself a busybox root filesystem too. Make that into a jffs2
image.

So your partitioning would look something similar to this (you'll have
to decide on the sizes of course):
mtd0: bootloader
mtd1: kernel
mtd2: rootfs (jffs2)
mtd3: Android rootfs.

Erase everything on the NAND.
Burn the normal Chumby bootloader to mtd0.
Burn the the new kernel into mtd1.
Burn the jffs2 rootfs image to mtd2.

Boot the device. Hopefully you get yourself to a prompt.

Once you have that prompt mount mtd3 to /mnt/android as a yaffs2
partition.
Untar your Android rootfs into /mnt/android.
Chown and chgrp everything under /mnt/android to "root"
chroot to that mount point "chroot /mnt/android /init"

At this point you should see Android trying to run.


I know that's a bit to chomp on, but it's more of an outline of what
you will need to do. Of course it's assuming you have the ability to
erase the whole nand and put down images amongst other assumptions,
but it should help get your mind around a little bit of the
requirements to get Android running on your device.

Regarding your bootloader question, I'd just stick with the current
one. You'll only need to modify that if/when you go into having
everything compatible with the recovery system. Which is a completely
different discussion.

[edit] Porting Tutorials

Porting Android to a new Device - excellent and thorough paper on porting Android to the Nokia N810.
- Has a detailed list of kernel changes and annotated diffs.
http://wiki.kldp.org/wiki.php/AndroidPortingOnRealTarget
Android on OMAP - excellent tutorial covering lots of different issues for porting Android to platforms based on the TI OMAP (ARM) processor
Some cursory notes on a port to a PXA board are at: http://letsgoustc.spaces.live.com/blog/cns!89AD27DFB5E249BA!320.entry

[edit] Porting Issues

Matt Porter (Mentor Graphics) gave a presentation on difficulties encountered while they were porting Android to MIPS and PPC processors at ELC Europe 2009. His talk was called "Mythbusters: Android" and has lots of good information.
- See Mythbusters_Android.pdf

Dalvik porting guide

[edit] Porting to New Processors

Mentor Graphics has ported Android to MIPS and PPC
Power.Org supported the work to port Android to PPC
- Nina Wilner talked about this work, and gave a demo at ELC Europe 2009
- see Android_On_Power.pdf

Android Porting on Devices

Android Tools

Android Kernel Download From eLinux.orgJump to: navigation, search

[edit] Main Google Android Kernels

[edit] Other Repositories with Android-specific changes

[edit] 'Raw' Android kernel patches

Android Kernel Build

From eLinux.org

[edit] Building an Individual application

Contents

[edit] Android SDK

[edit] host-side tools

[edit] adb

[edit] aapt

[edit] ddms

[edit] Fastboot

[edit] Toolchains

[edit] Emulator

[edit] traceview

[edit] target-side tools

[edit] am

[edit] dumpstate

[edit] logcat

[edit] monkey

[edit] procrank

[edit] service

[edit] toolbox

[edit] other tools

[edit] agcc

[edit] bootchart

[edit] busybox

[edit] smem

[edit] strace

[edit] Eclipse

[edit] Hardware

[edit] Serial Cable for G1

Dalvik Porting Guide

Dalvik Porting Guide

Core Libraries

JNI Call Bridge

Interpreter

Mterp Interpreter Structure

Getting Started With Mterp

Replacing Stubs

Interpreter Switching

Testing

Android's git Repository

Android Porting On Real Target [Realtime Project]

Contents

1 Introduction ¶

2 Copyright and Acknowledgements ¶

3 The brief analysis of the Android architecture ¶

3.1 Android Kernel ¶

3.1.1 ARM EABI ¶

3.1.2 OpenBinder ¶

3.1.3 Frame Buffer ¶

3.1.4 Input Devices ¶

3.1.5 Low Memory Killer ¶

3.1.6 Android Logger ¶

3.1.7 Android Power ¶

3.1.8 Panic Timeout ¶

3.2 Android Root File system ¶

3.3 Licenses of the Android Packages ¶

4 Toolchain supporting ARM EABI ¶

4.1 Building toolchain ¶

4.2 Other toolchain ¶

5 Kernel ¶

5.1 Patch kernel ¶

5.2 .config ¶

6 Root file system ¶

6.1 Get ramdisk image from emulator ¶

6.2 Get data and system directory from emulator ¶

6.3 Integrate the Android system with a existing ramdisk image. ¶

6.4 System and Data directories ¶

6.5 Run and Debug ¶

6.6 Screenshots ¶

7 Application Development ¶

7.1 Install Eclipse IDE ¶

7.2 Build and Run Sample Applications ¶

7.3 Screenshots ¶