https://elinux.org/api.php?action=feedcontributions&user=Anil+S&feedformat=atomeLinux.org - User contributions [en]2024-03-29T15:39:08ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=Android_on_OMAP&diff=6684Android on OMAP2008-08-11T04:02:55Z<p>Anil S: /* Real hardware */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This page collects information about and guides you through the installation of [http://www.google.de/ Google's] [http://code.google.com/android/ Android] on [http://www.ti.com/ TI's] [http://www.arm.com/ ARM] based [http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4752 OMAP] [http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638&DCMP=WTBU&HQS=Other+OT+omap SoCs].<br />
<br />
''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.<br />
<br />
''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.<br />
<br />
=Android=<br />
<br />
==What is Android (not)==<br />
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. See [http://code.google.com/android/what-is-android.html Google's ''What is Android?''] page and [http://benno.id.au/blog/2007/11/26/what-is-android Benno's ''What is Android?'' and ''What Android isn't''] page for more details about Android.<br />
<br />
==Versions==<br />
<br />
From time to time Google updates their [http://code.google.com/android/download_previous.html 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).<br />
<br />
=Hardware=<br />
<br />
==Goldfish==<br />
Android SDK isn't targeted for a special (ARM) SoC. Instead, they use [http://fabrice.bellard.free.fr/qemu/ 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.<br />
<br />
This virtual ARM SoC comprises:<br />
<br />
* ARM926ej-S CPU<br />
* Thumb support<br />
* MMC<br />
* RTC<br />
* Keyboard<br />
* USB Gadget<br />
* Framebuffer<br />
* TTY driver<br />
* NAND<br />
* Software compiled for ARMv5TEJ instruction set (!) with EABI<br />
* no [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] [http://marc.info/?l=linux-omap&m=120384694214686&w=2 yet]<br />
<br />
==Real hardware==<br />
<br />
Running Android on real hardware, some prerequisites should be fulfilled:<br />
<br />
* SoC with ARM926 or higher (e.g. ARM11) (check [http://marc.info/?l=linux-omap&m=120394328104000&w=2 ARM MPCore or ARM Cortex] regarding [[Android_on_OMAP#TLS_issue|TLS issue]])<br />
** Note: ARM920T with ARMv4 instruction set [http://benno.id.au/blog/2007/11/21/android-neo1973 will not work]<br />
* You have already a recent (~2.6.23) Linux kernel with Thumb & MMU & EABI etc support running on your target<br />
* Soc/HW has and Linux kernel supports<br />
** Display/frame buffer (touchscreen would be good but optional). Frame buffer ''has'' to support [[Android_on_OMAP#Page_flipping_frame_buffer|double buffer/page flipping]].<br />
** Keyboard<br />
** USB (optional)<br />
** RTC (optional?)<br />
** Serial console<br />
** 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<br />
** 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.<br />
<br />
<br />
'''Known to work HW'''<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP1 based boards] (ARM v5 ARM926)<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP2 based boards] (ARM v6 ARM11)<br />
* [http://www.mistralsolutions.com/assets/downloads/2530.php omap2530evm] 2430OSK is renamed as 2530EVM based on TI's recommendation (ARM v6 ARM1136jf-s)<br />
* [http://euedge.com/blog/2007/12/06/google-android-runs-on-sharp-zaurus-sl-c760/ Sharp Zaurus SL-C760(PXA255)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C1000(PXA270)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C3000](PXA270)<br />
* [http://www.atmark-techno.com/en/products/armadillo/a500 Armadillo-500] and [http://youtube.com/watch?v=eFxnCaEwL_U Armadillo Panel Computer] (Freescale i.MX31L ARM11)<br />
* OMAP1 based [[OSK]] (OMAP5912 ARM926 with only 32MB SDRAM). Really slow, mainly usable as ''proof of concept''.<br />
* OMAP2430 based Hardware [http://www.mistralsolutions.com/business_divisons/omap_2evm.php OMAP2EVM from Mistral] [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57?hl=en& Android internals ML], [http://marc.info/?l=linux-omap&m=120741537025066&w=2 OMAP ML] and [http://code.google.com/p/android-on-n8xx/ Android on N810] page. <br />
* OMAP3430 based Hardware [http://www.mistralsolutions.com/business_divisons/omap_3evm.php OMAP3EVM from Mistral] (Android runs on ARM Cortex™-A8 Core)<br />
<br />
'''Known to not work HW'''<br />
* [http://benno.id.au/blog/2007/11/21/android-neo1973 Neo 1973] (ARM920T)<br />
<br />
=Compiler=<br />
Getting Android working on real hardware, you need an [http://wiki.debian.org/ArmEabiPort 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 [http://www.codesourcery.com/ CodeSourcery's] [http://www.codesourcery.com/gnu_toolchains/arm/download.html '''ARM GNU/Linux''' tool chain].<br />
<br />
''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.<br />
<br />
=Code=<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Kernel==<br />
<br />
On [http://code.google.com/p/android/downloads/list 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.<br />
<br />
===Patch extraction===<br />
<br />
See third paragraph of [http://benno.id.au/blog/2007/11/21/android-neo1973 Benno's Android on NEO 1973 article].<br />
<br />
* Download matching version (e.g. m5-rc14) of [http://code.google.com/p/android/downloads/list Android kernel source]. Besides complete kernel source this will contain Android specific changes.<br />
* 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.<br />
* 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 [http://www.yaffs.net/ 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 [[Android_on_OMAP#OpenBinder|OpenBinder related files]] (/driver/binder) as well. [[Android_on_OMAP#Kernel_patch|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.<br />
<br />
''Note'': There seems to be [http://marc.info/?l=linux-omap&m=120384694214686&w=2 some effort] to make Android kernel patches available in a easier usable format.<br />
<br />
===Extracted patches===<br />
<br />
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 ([[Android_on_OMAP#Extracted_binaries|see below]]) version.<br />
<br />
* [http://benno.id.au/android/android-noqemu-nogoldfish-noyaffs2.diff Benno's no Qemu no goldfish no yaffs2 patch], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android patches extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
===Git patches===<br />
<br />
There are Android kernel patches available using [http://git.android.com/?p=kernel.git;a=shortlog;h=android Android's git] repository. But have a look to [http://marc.info/?l=linux-omap&m=120716474803274&w=2 Brian's notes] regarding this.<br />
<br />
==File System==<br />
<br />
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 [http://marc.info/?l=linux-omap&m=120368832309928&w=2 Google itself and eventually WindRiver].<br />
<br />
Again, there are two ways to get user space binaries: Extracting them your self or taking already extracted ones.<br />
<br />
===Binary extraction===<br />
<br />
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.<br />
<br />
* [http://code.google.com/android/download_list.html Download SDK] and unzip it<br />
* system.img and userdata.img are [http://www.yaffs.net/ yaffs2] images. There is no way yet to mount them directly on a host to extract their content. An [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool is missing, so the only way to get the content is to start the emulator and extract the contents from running emulator.<br />
* As file system in emulator as no ''cp'' or ''tar'' command, we use a statically linked [http://www.busybox.net/ BusyBox] cross compiled for ARM and use it inside emulator (get it from [http://benno.id.au/blog/2007/11/14/android-busybox Benno] or build it your own with above tool chain).<br />
* Set path to emulator tools<br />
<br />
export PATH=${PATH}:<path_to>/android-sdk_m5-rc14_linux-x86/tools<br />
<br />
* Create an empty SDcard (image)<br />
<br />
[http://code.google.com/android/reference/othertools.html#mksdcard mksdcard] -l card 100M card.img<br />
<br />
* Start emulator<br />
<br />
[http://code.google.com/android/reference/emulator.html emulator] -sdcard card.img -console -debug-kernel<br />
<br />
* 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:<br />
<br />
[http://code.google.com/android/reference/adb.html adb] -d 1 push busybox /data/busybox<br />
<br />
* Inside emulation, set tar (and bzip2) links to busybox, tar ''/system'' and ''/data'' directories to sdcard.<br />
* Shutdown emulator, mount card.img<br />
<br />
mount -o loop card.img mnt/<br />
<br />
and get the images of system and user data.<br />
<br />
* 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:<br />
** Remove all content of ''data/dalvik-cache/''. It holds the decompressed files from the apk packages.<br />
** Remove the static busybox image. We only needed it for extraction and don't need it any more.<br />
<br />
''Note'': Anybody likes to hack this [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool? Then the system.img and userdata.img extraction would be a lot easier.<br />
<br />
''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. <br />
<br />
===Extracted binaries===<br />
<br />
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 ([[Android_on_OMAP#Extracted_patches|see above]]) version.<br />
<br />
* [http://benno.id.au/blog/2007/11/14/android-filesystems Android file system images], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android binaries extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
=Target=<br />
<br />
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.<br />
<br />
==Kernel configuration==<br />
<br />
Make sure your kernel boots normally on your board. Then enable some Android specific configuration (needs [[Android_on_OMAP#Kernel|kernel patch extracted above]]) and make sure that your kernel still boots (with your standard file system).<br />
<br />
''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. <br />
<br />
'''EABI'''<br />
<br />
CONFIG_AEABI=y<br />
# CONFIG_OABI_COMPAT is not set<br />
<br />
'''THUMB'''<br />
<br />
CONFIG_ARM_THUMB=y<br />
<br />
'''Android drivers'''<br />
<br />
#<br />
# Android<br />
#<br />
# CONFIG_ANDROID_GADGET is not set<br />
# CONFIG_ANDROID_RAM_CONSOLE is not set<br />
CONFIG_ANDROID_POWER=y<br />
CONFIG_ANDROID_POWER_STAT=y<br />
CONFIG_ANDROID_LOGGER=y<br />
# CONFIG_ANDROID_TIMED_GPIO is not set<br />
CONFIG_ANDROID_BINDER_IPC=y<br />
<br />
After you successfully booted the kernel with configuration above (and m5-rc14 kernel patch), make sure you have following /sys files:<br />
<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/last_user_activity<br />
/sys/android_power/request_sleep<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/battery_level<br />
/sys/android_power/battery_level_low<br />
/sys/android_power/battery_level_raw<br />
/sys/android_power/battery_level_scale<br />
/sys/android_power/battery_low_level<br />
/sys/android_power/battery_shutdown_level<br />
/sys/android_power/charging_state<br />
/sys/android_power/release_wake_lock<br />
/sys/android_power/request_state<br />
/sys/android_power/state<br />
<br />
==File system configuration==<br />
<br />
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.<br />
<br />
The Android file system we establish here on one of the the storage from above is built from four parts:<br />
<br />
* Content of system data image extracted above<br />
* Content of user data image extracted above (make sure temporary files are removed)<br />
* Content of Android ram disk image<br />
* Device file system <br />
<br />
To create Android file system, take (empty) storage you selected and start with ram disk:<br />
<br />
Android ram disk image can be found as ramdisk.img in tools/lib/images of Android SDK. This is a gziped cpio archive:<br />
<br />
cp ramdisk.img ramdisk.gz<br />
gunzip ramdisk.gz<br />
cd target_fs<br />
cpio -iv < ../ramdisk<br />
<br />
Result of this should be an root file system tree with:<br />
<br />
data<br />
dev<br />
etc<br />
init<br />
proc<br />
sbin<br />
sys<br />
system<br />
tmp<br />
var<br />
<br />
Directories data, dev and system are empty. Extract content of extracted user data image to /data and system image to /system directories. E.g.<br />
<br />
tar xvfj ../system_m5_rc14.tar.bz2 system/<br />
tar xvfj ../userdata_m5_rc14.tar.bz2 data/<br />
<br />
Note: This depends on how you named and stored extracted user data and system image above.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Start up==<br />
<br />
Starting Android using the file system and kernel created above, there are three ways:<br />
<br />
* Directly boot from Android kernel into the Android file system. I.e. let the Android kernel directly start init etc. from Android file system.<br />
* 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.<br />
* 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. <br />
<br />
===Android root file system===<br />
<br />
There are several ways to directly start Android from (root) file system created above:<br />
<br />
* 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<br />
* Use Android's shell and give kernel /system/bin/sh as init program. Then start Android's init manually (/init&) . <br />
<br />
===Start via scripts===<br />
<br />
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.<br />
<br />
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.<br />
<br />
start_android.sh in standard root file system:<br />
<br />
#!/bin/sh -x<br />
echo "Starting Android..."<br />
fsck.ext2 -pv /dev/sda1<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umount /proc<br />
umount /sys<br />
mount -t proc proc /mnt/usb/proc<br />
mount -t sysfs sysfs /mnt/usb/sys<br />
umask 000<br />
chroot /mnt/usb/a.sh<br />
<br />
a.sh to start Android at Android file system:<br />
<br />
#!/system/bin/sh -x<br />
<br />
export PATH=/sbin:/system/sbin:/system/bin:$PATH<br />
export LD_LIBRARY_PATH=/system/lib<br />
export ANDROID_ROOT=/system<br />
export ANDROID_ASSETS=/system/app<br />
export ANDROID_DATA=/data<br />
export EXTERNAL_STORAGE=/sdcard<br />
export DRM_CONTENT=/data/drm/content<br />
<br />
/system/bin/app_process -Xzygote /system/bin --zygote &<br />
/system/bin/dbus-daemon --system &<br />
runtime &<br />
/system/bin/sh<br />
<br />
Notes:<br />
<br />
* fsck.ext2 -pv /dev/sda1: Make sure ext2 file system is clean. ext2 doesn't like unclean switch off while debugging Android start up ;)<br />
* rm -f /mnt/usb/tmp/*: Remove Android temporary files before starting Android.<br />
* mount proc and mount sys: This has to be done somewhere. Depending on your scripts, you can do it in a.sh as well.<br />
* runtime: For debugging use here /system/bin/strace -f -ff -tt -s 200 runtime&.<br />
* 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 ;) <br />
<br />
===Start init via scripts===<br />
<br />
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.<br />
<br />
From standard non-Android file system this switch can look like:<br />
<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umask 000<br />
chroot /mnt/usb /init<br />
<br />
==Debugging==<br />
<br />
* Strace: The main debugging help currently known is [http://benno.id.au/blog/2007/11/18/android-runtime-strace strace]. Again, a statically linked one is used.<br />
** You should invoke strace with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, e.g.<br />
<br />
strace -f -ff -tt -s 200 /system/bin/runtime<br />
<br />
=FAQ=<br />
<br />
===Kernel patch===<br />
<br />
'''Q''': Above section about [[Android_on_OMAP#Patch_extraction|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? <br />
<br />
'''A''': Regarding m5-rc14 and kernel 2.6.23 the (changed) files below seem to be sufficient to run Android on real HW:<br />
<br />
arch/arm/Kconfig<br />
arch/arm/kernel/process.c<br />
arch/arm/kernel/signal.c<br />
drivers/android/alarm.c<br />
drivers/android/android_gadget.c<br />
drivers/android/android_kernel_debug.c<br />
drivers/android/android_kernel_debug.h<br />
drivers/android/binder.c<br />
drivers/android/Kconfig<br />
drivers/android/logger.c<br />
drivers/android/Makefile<br />
drivers/android/power.c<br />
drivers/android/ram_console.c<br />
drivers/android/timed_gpio.c<br />
drivers/input/evdev.c<br />
drivers/Kconfig<br />
drivers/misc/Kconfig<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
drivers/misc/lowmemorykiller/Makefile<br />
drivers/misc/Makefile<br />
fs/inotify_user.c<br />
include/linux/android_alarm.h<br />
include/linux/android_gadget.h<br />
include/linux/android_power.h<br />
include/linux/android_timed_gpio.h<br />
include/linux/binder_module.h<br />
include/linux/binder_type_constants.h<br />
include/linux/logger.h<br />
kernel/power/process.c<br />
drivers/Makefile<br />
<br />
===OpenBinder===<br />
<br />
'''Q''': When I extract the kernel patch, I additionally get a ''drivers/binder/'' directory. Why isn't it listed/needed above?<br />
<br />
'''A''': The ''drivers/binder/'' directory seems to contain [http://www.newmobilecomputing.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/ OpenBinder]. In Android m5-rc14 this seems to be [http://marc.info/?l=linux-omap&m=120417098706141&w=2 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.<br />
<br />
===Devices nodes===<br />
<br />
'''Q''': Do I need special devices nodes? Which?<br />
<br />
'''A''': [[Android_on_OMAP#File_System|Above]] we only extracted system and userdata image. If you like, you can extract /dev entries as well. However, starting Android's ''runtime'' under [[Android_on_OMAP#Debugging|strace]] control should give you a list which devices will be opened. Besides the standard ones you will need (incomplete?):<br />
<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 binder<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/radio<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/events<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/main<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 alarm<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 eac<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 graphics/fb0<br />
more ?<br />
<br />
===/dev/xxx minor numbers===<br />
<br />
'''Q''': Which minor number will I need for /dev/xxx entries above? E.g. for /dev/binder?<br />
<br />
'''A''': The major number 10 (major number for "misc" devices) above are for new drivers of m5-rc14. The minor numbers [http://marc.info/?l=linux-omap&m=120417584110733&w=2 would be as given] by cat /proc/misc. They are somehow board dependent and may change.<br />
<br />
E.g. in m5-rc14 emulator you may get:<br />
<br />
# cat /proc/misc<br />
58 binder<br />
59 log_radio<br />
60 log_events<br />
61 log_main<br />
62 alarm<br />
1 psaux<br />
63 eac<br />
<br />
With [[Android_on_OMAP#Patch_extraction|kernel patch on real HW]] you may get:<br />
<br />
# cat /proc/misc<br />
59 binder<br />
60 log_radio<br />
61 log_events<br />
62 log_main<br />
63 alarm<br />
<br />
===/dev/fb0===<br />
<br />
'''Q''': I have /dev/fb0, is this correct?<br />
<br />
'''A''': With m5-rc14 [http://androidzaurus.seesaa.net/article/84934031.html Google switched frame buffer interface] to /dev/graphics/fb0. So you need:<br />
<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 /dev/graphics/fb0<br />
<br />
===Blank screen===<br />
<br />
'''Q''': I did all steps like above, [[Android_on_OMAP#Debugging|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.<br />
<br />
'''A''': With m5-rc14 the frame buffer handling changed. You now need a frame buffer driver which [http://androidzaurus.seesaa.net/article/87808061.html supports double buffer/page flipping]. Observe the output of strace. If you get:<br />
<br />
...<br />
writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38<br />
open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21<br />
ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0<br />
writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, '''{"page flipping not supported (yres_virtual=640, requested=1280)\", 63}], 3)''' = 82<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
...<br />
<br />
your frame buffer driver doesn't support page flipping.<br />
<br />
''Note'': For above output, strace has to be invoked with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, else you wouldn't see this.<br />
<br />
===Page flipping frame buffer===<br />
<br />
'''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?<br />
<br />
'''A''': This depends on frame buffer driver.<br />
* For OMAP you can try following hack:<br />
<br />
Index: linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
===================================================================<br />
--- linux-omap-2_6_23.orig/drivers/video/omap/omapfb_main.c<br />
+++ linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
@@ -168,7 +168,7 @@ static int ctrl_init(struct omapfb_devic<br />
/* 12 bpp is packed in 16 bits */<br />
if (bpp == 12)<br />
bpp = 16;<br />
- def_size = def_vxres * def_vyres * bpp / 8;<br />
+ def_size = def_vxres * def_vyres * 2 * bpp / 8;<br />
fbdev->mem_desc.region_cnt = 1;<br />
fbdev->mem_desc.region[0].size = PAGE_ALIGN(def_size);<br />
}<br />
@@ -415,6 +415,7 @@ static void set_fb_fix(struct fb_info *f<br />
}<br />
fix->accel = FB_ACCEL_OMAP1610;<br />
fix->line_length = var->xres_virtual * bpp / 8;<br />
+ fix->ypanstep = 1;<br />
}<br />
<br />
static int set_color_mode(struct omapfb_plane_struct *plane,<br />
@@ -1471,7 +1472,7 @@ static int fbinfo_init(struct omapfb_dev<br />
var->xres = def_vxres;<br />
var->yres = def_vyres;<br />
var->xres_virtual = def_vxres;<br />
- var->yres_virtual = def_vyres;<br />
+ var->yres_virtual = def_vyres * 2;<br />
var->rotate = def_rotate;<br />
var->bits_per_pixel = fbdev->panel->bpp;<br />
<br />
<br />
(anybody with clean patch? ->[[Android_on_OMAP#Contact|contact]])<br />
<br />
* For Zaurus/pxafb have a look to following [http://androidzaurus.seesaa.net/article/87973048.html solution]. See [http://www.oesf.org/forum/index.php?s=b33968d11c595adb9ac146a6d4c59366&showtopic=25517&st=15&start=15 OESF] as well.<br />
<br />
===Android start crashes===<br />
<br />
'''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.<br />
<br />
'''A''': Make sure that you use kernel patch and file system from most [http://marc.info/?l=linux-omap&m=120392877715554&w=2 recent Android] release (currently m5-rc14). [http://marc.info/?l=linux-omap&m=120400983008672&w=2 Don't mix] kernel patch and file system from different versions.<br />
<br />
===Power management===<br />
<br />
'''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 [http://marc.info/?l=linux-omap&m=120470400929434&w=2 fake Android power management].<br />
<br />
'''A''': unknown yet :( There is some guessing and some workaround.<br />
<br />
* Some [http://androidzaurus.seesaa.net/article/87973048.html#comment guess from androidzaurus]. <br />
<br />
* Workaround reported from [http://marc.info/?l=linux-omap&m=120538179321533&w=2 Anil]: <br />
<br />
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<br />
<br />
android_power_suspend: enter suspend<br />
android_power_suspend: exit suspend, ret = -38<br />
android_power_suspend: pm_suspend returned with no event<br />
<br />
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<br />
<br />
android_power_wakeup 2->0 at 447592867845<br />
active wake lock PowerManagerService<br />
active wake lock KeyEvents<br />
android_power_suspend: done<br />
<br />
===TLS issue===<br />
<br />
'''Q''': What is this TLS issue?<br />
<br />
'''A''': Some newer ARM processors support [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] in hardware. With current (m5-rc14) Android release this [http://marc.info/?l=linux-omap&m=120384694214686&w=2 isn't supported] yet.<br />
<br />
===TLS issue and processors===<br />
<br />
'''Q''': Which processors have this TLS issue?<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120394328804005&w=2 ARMv6K (MPCORE) and ARMv7 (Cortex)]. Regarding OMAP, this is OMAP3 (Cortex). OMAP1 (ARM9) and OMAP2 (ARM11) don't have this issue.<br />
<br />
===TLS issue workaround===<br />
<br />
'''Q''': I'd like to use (m5-rc14) Android on processors with TLS issue, what can I do?<br />
<br />
'''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<br />
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,<br />
you really don't want to do this as it does cause a performance hit.<br />
<br />
diff -Naur 2.6_kernel-orig/arch/arm/mm/Kconfig 2.6_kernel-android/arch/arm/mm/Kconfig<br />
--- 2.6_kernel-orig/arch/arm/mm/Kconfig 2007-11-20 12:09:42.000000000-0600<br />
+++ 2.6_kernel-new/arch/arm/mm/Kconfig 2007-12-08 22:23:04.000000000-0600<br />
@@ -675,7 +675,7 @@<br />
config HAS_TLS_REG<br />
bool<br />
depends on !TLS_REG_EMUL<br />
- default y if SMP || CPU_32v7<br />
+ default y if SMP || CPU_32v7 && !ARCH_OMAP<br />
help<br />
This selects support for the CP15 thread register.<br />
It is defined to be available on some ARMv6 processors (including<br />
<br />
(Thanks to Keith Deacon!)<br />
<br />
''Note'': A [http://marc.info/?l=linux-omap&m=120400327301855&w=2 user report] wasn't quite successful regarding this.<br />
<br />
===Red cycle eye runtime speed===<br />
<br />
'''Q''': The red cycle eye runs very fast on my board, and the system_server take almost 100% CPU<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120399654528241&w=2 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.<br />
<br />
===File not found===<br />
<br />
'''Q''': At Android start up I get some ''File not found ...'' error messages like:<br />
<br />
Prepping: /system/app/AlarmClock.apk:/system/app/AlarmProvider.apk:...<br />
File not found: /system/app/AlarmClock.apk<br />
File not found: /system/app/AlarmProvider.apk<br />
File not found: /system/app/Anagrams.apk<br />
...<br />
File not found: /system/app/Vending.apk<br />
File not found: /system/app/VoiceDialer.apk<br />
File not found: /system/app/Voicemail.apk<br />
File not found: /system/app/YouTube.apk<br />
Prep complete<br />
<br />
Do I have to care about these?<br />
<br />
'''A''': No, it doesn't seem so. See [http://benno.id.au/blog/2007/11/18/android-framework-startup Benno's blog], section Manual startup.<br />
<br />
===Limited main memory===<br />
<br />
'''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?<br />
<br />
'''A''': Try to enable lowmemorykiller:<br />
<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
<br />
For this, in kernel enable<br />
<br />
CONFIG_LOW_MEMORY_KILLER=y<br />
<br />
in Device drivers -> Misc devices. At Android startup this then results in messages like<br />
<br />
...<br />
send sigkill to 920 (app_process), adj 1, size 1838<br />
...<br />
<br />
===Some buttons work, some not===<br />
<br />
'''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?<br />
<br />
'''A''': From [http://marc.info/?l=linux-omap&m=120749091514894&w=2 Brian at OMAP ML]:<br />
<br />
''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.''<br />
<br />
===Filesystem, JFFS2 and SIGSEGV===<br />
<br />
'''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?<br />
<br />
'''A''': Don't use JFFS2 as file system for Android. [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/71709fc4adcb2ddd Android does not support JFFS]. Use an ext2/3 formatted medium. Or use YAFFS2 if you use a NAND device (as emulator does).<br />
<br />
===Using JFFS2===<br />
<br />
'''Q''': Okay, I understand from above that Android doesn't support JFFS2. But, maybe there is a hack to try?<br />
<br />
'''A''': You could try what [http://marc.info/?l=linux-omap&m=120946006920397&w=2 Brian] reports:<br />
<br />
''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 /.''<br />
<br />
''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.''<br />
<br />
===Nokia N8x0 and Android SDK===<br />
<br />
'''Q''': I'd like to run [[Android_on_OMAP#Screenshots|Android on Nokia N8x0]] ([http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57 link 1], [http://code.google.com/p/android-on-n8xx/ link 2]). Which [http://code.google.com/p/android/downloads/list Android SDK] should I use? Can I use m5-rc14/15 SDK?<br />
<br />
'''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.<br />
<br />
m5 user space will '''not''' work, because it needs [[Android_on_OMAP#Page_flipping_frame_buffer|page flipping frame buffer]] and N8x0 fb driver doesn't support this.<br />
<br />
===N8x0 and recent OMAP git kernel===<br />
'''Q''': I'd like to use recent OMAP git kernel on N8x0. What do I need to run git kernel on N8x0?<br />
<br />
'''A''': Have a look to Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel].<br />
<br />
===N810 keys===<br />
<br />
'''Q''': How do I get the N810 keyboard to work with Android?<br />
<br />
'''A''': Try the following [http://groups.google.com/group/android-internals/msg/04f842aa0710932a changes] to get most of N810 keys working with Android, except Fn and the numbers:<br />
<br />
Just update one file: /system/usr/keylayout/qwerty.kl<br />
<br />
-key 158 BACK WAKE_DROPPED<br />
+key 1 BACK WAKE_DROPPED<br />
key 230 SOFT_RIGHT WAKE<br />
key 60 SOFT_RIGHT WAKE<br />
key 107 ENDCALL WAKE_DROPPED<br />
key 62 ENDCALL WAKE_DROPPED<br />
-key 229 SOFT_LEFT WAKE_DROPPED<br />
+key 62 SOFT_LEFT WAKE_DROPPED<br />
key 59 SOFT_LEFT WAKE_DROPPED<br />
key 139 SOFT_LEFT WAKE_DROPPED<br />
key 228 POUND<br />
key 227 STAR<br />
key 231 CALL WAKE_DROPPED<br />
key 61 CALL WAKE_DROPPED<br />
-key 232 DPAD_CENTER WAKE_DROPPED<br />
+key 96 DPAD_CENTER WAKE_DROPPED<br />
key 108 DPAD_DOWN WAKE_DROPPED<br />
key 103 DPAD_UP WAKE_DROPPED<br />
-key 102 HOME WAKE<br />
+key 63 HOME WAKE<br />
key 105 DPAD_LEFT WAKE_DROPPED<br />
key 106 DPAD_RIGHT WAKE_DROPPED<br />
-key 115 VOLUME_UP<br />
-key 114 VOLUME_DOWN<br />
+key 65 VOLUME_UP<br />
+key 66 VOLUME_DOWN<br />
<br />
===N8x0 touchscreen===<br />
<br />
'''Q''': Is there any way to get N8x0 touchscreen working with Android?<br />
<br />
'''A''': Yes. There is a [http://groups.google.com/group/android-internals/msg/7c6ff76e0381e95a patch] you can apply to a nokia+android patched 2.6.21 kernel and you should<br />
have a working touchscreen.<br />
<br />
===HW interfaces support===<br />
<br />
'''Q''': Which hardware interfaces or kernel drivers does current Android support?<br />
<br />
'''A''': See discussion on [http://marc.info/?l=linux-omap&m=120946406828608&w=2 OMAP ML]:<br />
<br />
> I was able to add support for the keypad, touch and network in Android,<br />
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D<br />
> acceleration, battery etc. are not integrated with Android right now. I<br />
> would appreciate if you could throw some light on these open issues. How<br />
> exactly can these interfaces be integrated with Android? <br />
<br />
We're trying to use the standard kernel/driver interfaces when possible,<br />
but for things that may have a good deal of variation in implementation,<br />
we're looking to provide a very thin "hardware interface library" layer<br />
to adapt between the bottom of the userspace stack and the drivers or<br />
whatnot for specific hardware platforms. <br />
<br />
We'll continue to adopt standardized kernel solutions as they become<br />
available -- We're now using the power supply framework in 2.6.24 for<br />
monitoring battery/charge state (post M5 SDK -- it'll be in the next <br />
release), for example.<br />
<br />
=Links=<br />
<br />
* [http://code.google.com/android/ Android] homepage<br />
* [http://benno.id.au/blog/ Bennos blog] with lot of reverse engineering info about Android<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Android on Zaurus]<br />
* [http://www.kandroid.org Korea Android Community] <br />
''Note'':Connect this site using http://www.google.com/translate website.<br />
* Linux devices about [http://www.linuxdevices.com/news/NS4262102607.html Penguinistas hack Android onto real hardware]<br />
* [http://tree.celinuxforum.org/CelfPubWiki/Jamboree18AndroidDemo Google Android on Working Target]<br />
* [http://code.google.com/android/groups.html Android discussion groups]. These concentrate more on Android application programming. Not really HW and processor related.<br />
* [http://www.oesf.org/forum/index.php?showforum=158 Open Embedded Software Foundation Android forum]. Discussion, support and general information about running Android on a handheld.<br />
* [http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en Porting Android to real HW at Android internals list]<br />
* [http://nemustech.blogspot.com/2007/12/android-porting-to-real-target-hw.html Android Porting to Real Target HW]<br />
* [http://code.google.com/p/android-on-n8xx/ Android on Nokia 8xx]<br />
* Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel]<br />
* [http://forums.lugradio.org/viewtopic.php?f=4&t=4094#p41437 Robert Love talks about Google Android]. Recorded at [http://www.lugradio.org/live/USA2008/ LUG Radio Live USA 2008] at the Metreon Theatre, San Francisco.<br />
<br />
''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.<br />
<br />
=Contact=<br />
<br />
See [http://vger.kernel.org/vger-lists.html#linux-omap OMAP mailing list] for more information.<br />
<br />
This page is distilled by [mailto:dirk.behme@gmail.com Dirk Behme] and information added by [mailto:leemgs@gmail.com Lim,GeunSik].<br />
<br />
=Screenshots=<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.23 on OMAP5912 [[OSK|OSK]]: <br />
<br />
[[Image:Android m5 rc14 omap osk kernel 2 6 23.jpg]]<br />
<br />
* Android m5-rc14 kernel + m3 image, on a Nokia N810:<br />
<br />
[[Image:Cimg0608.jpg]]<br />
<br />
<br />
[[Image:Cimg0610.jpg]]<br />
<br />
<br />
[[Image:Cimg0611.jpg]]<br />
<br />
<br />
* Android m5-rc15 home screen with kernel 2.6.18 on armadillo-500 1136 ([http://www.youtube.com/watch?v=jGvGl0nOQNo YouTube Movie])<br />
<br />
[[Image:androidarmadillo200804.jpg]]<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.19 on OMAP2430 [[OSK|OSK]]:<br />
-If you have unstable sdcard, You will meet for Looping of "Red Eye" Status.<br />
[[Image:omap2evm.android.PNG]]<br />
<br />
<br />
* Android m5-rc14 on Nokia's n810 Tablet<br />
[[Image:n810.kandroid200805.PNG]]</div>Anil Shttps://elinux.org/index.php?title=Android_on_OMAP&diff=6499Android on OMAP2008-07-17T04:42:57Z<p>Anil S: /* Real hardware */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This page collects information about and guides you through the installation of [http://www.google.de/ Google's] [http://code.google.com/android/ Android] on [http://www.ti.com/ TI's] [http://www.arm.com/ ARM] based [http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4752 OMAP] [http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638&DCMP=WTBU&HQS=Other+OT+omap SoCs].<br />
<br />
''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.<br />
<br />
''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.<br />
<br />
=Android=<br />
<br />
==What is Android (not)==<br />
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. See [http://code.google.com/android/what-is-android.html Google's ''What is Android?''] page and [http://benno.id.au/blog/2007/11/26/what-is-android Benno's ''What is Android?'' and ''What Android isn't''] page for more details about Android.<br />
<br />
==Versions==<br />
<br />
From time to time Google updates their [http://code.google.com/android/download_previous.html 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).<br />
<br />
=Hardware=<br />
<br />
==Goldfish==<br />
Android SDK isn't targeted for a special (ARM) SoC. Instead, they use [http://fabrice.bellard.free.fr/qemu/ 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.<br />
<br />
This virtual ARM SoC comprises:<br />
<br />
* ARM926ej-S CPU<br />
* Thumb support<br />
* MMC<br />
* RTC<br />
* Keyboard<br />
* USB Gadget<br />
* Framebuffer<br />
* TTY driver<br />
* NAND<br />
* Software compiled for ARMv5TEJ instruction set (!) with EABI<br />
* no [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] [http://marc.info/?l=linux-omap&m=120384694214686&w=2 yet]<br />
<br />
==Real hardware==<br />
<br />
Running Android on real hardware, some prerequisites should be fulfilled:<br />
<br />
* SoC with ARM926 or higher (e.g. ARM11) (check [http://marc.info/?l=linux-omap&m=120394328104000&w=2 ARM MPCore or ARM Cortex] regarding [[Android_on_OMAP#TLS_issue|TLS issue]])<br />
** Note: ARM920T with ARMv4 instruction set [http://benno.id.au/blog/2007/11/21/android-neo1973 will not work]<br />
* You have already a recent (~2.6.23) Linux kernel with Thumb & MMU & EABI etc support running on your target<br />
* Soc/HW has and Linux kernel supports<br />
** Display/frame buffer (touchscreen would be good but optional). Frame buffer ''has'' to support [[Android_on_OMAP#Page_flipping_frame_buffer|double buffer/page flipping]].<br />
** Keyboard<br />
** USB (optional)<br />
** RTC (optional?)<br />
** Serial console<br />
** 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<br />
** 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.<br />
<br />
<br />
'''Known to work HW'''<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP1 based boards] (ARM v5 ARM926)<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP2 based boards] (ARM v6 ARM11)<br />
* [http://www.mistralsolutions.com/assets/downloads/2530.php omap2530evm] 2430OSK is renamed as 2530EVM based on TI's recommendation (ARM v6 ARM1136jf-s)<br />
* [http://euedge.com/blog/2007/12/06/google-android-runs-on-sharp-zaurus-sl-c760/ Sharp Zaurus SL-C760(PXA255)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C1000(PXA270)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C3000](PXA270)<br />
* [http://www.atmark-techno.com/en/products/armadillo/a500 Armadillo-500] and [http://youtube.com/watch?v=eFxnCaEwL_U Armadillo Panel Computer] (Freescale i.MX31L ARM11)<br />
* OMAP1 based [[OSK]] (OMAP5912 ARM926 with only 32MB SDRAM). Really slow, mainly usable as ''proof of concept''.<br />
* OMAP2430 based Hardware [http://www.mistralsolutions.com/business_divisons/omap_2evm.php OMAP2EVM from Mistral] [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57?hl=en& Android internals ML], [http://marc.info/?l=linux-omap&m=120741537025066&w=2 OMAP ML] and [http://code.google.com/p/android-on-n8xx/ Android on N810] page. <br />
* OMAP3430 based Hardware [http://www.mistralsolutions.com/business_divisons/omap_3evm.php OMAP3EVM from Mistral] (Android runs on ARMv7)<br />
<br />
'''Known to not work HW'''<br />
* [http://benno.id.au/blog/2007/11/21/android-neo1973 Neo 1973] (ARM920T)<br />
<br />
=Compiler=<br />
Getting Android working on real hardware, you need an [http://wiki.debian.org/ArmEabiPort 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 [http://www.codesourcery.com/ CodeSourcery's] [http://www.codesourcery.com/gnu_toolchains/arm/download.html '''ARM GNU/Linux''' tool chain].<br />
<br />
''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.<br />
<br />
=Code=<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Kernel==<br />
<br />
On [http://code.google.com/p/android/downloads/list 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.<br />
<br />
===Patch extraction===<br />
<br />
See third paragraph of [http://benno.id.au/blog/2007/11/21/android-neo1973 Benno's Android on NEO 1973 article].<br />
<br />
* Download matching version (e.g. m5-rc14) of [http://code.google.com/p/android/downloads/list Android kernel source]. Besides complete kernel source this will contain Android specific changes.<br />
* 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.<br />
* 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 [http://www.yaffs.net/ 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 [[Android_on_OMAP#OpenBinder|OpenBinder related files]] (/driver/binder) as well. [[Android_on_OMAP#Kernel_patch|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.<br />
<br />
''Note'': There seems to be [http://marc.info/?l=linux-omap&m=120384694214686&w=2 some effort] to make Android kernel patches available in a easier usable format.<br />
<br />
===Extracted patches===<br />
<br />
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 ([[Android_on_OMAP#Extracted_binaries|see below]]) version.<br />
<br />
* [http://benno.id.au/android/android-noqemu-nogoldfish-noyaffs2.diff Benno's no Qemu no goldfish no yaffs2 patch], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android patches extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
===Git patches===<br />
<br />
There are Android kernel patches available using [http://git.android.com/?p=kernel.git;a=shortlog;h=android Android's git] repository. But have a look to [http://marc.info/?l=linux-omap&m=120716474803274&w=2 Brian's notes] regarding this.<br />
<br />
==File System==<br />
<br />
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 [http://marc.info/?l=linux-omap&m=120368832309928&w=2 Google itself and eventually WindRiver].<br />
<br />
Again, there are two ways to get user space binaries: Extracting them your self or taking already extracted ones.<br />
<br />
===Binary extraction===<br />
<br />
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.<br />
<br />
* [http://code.google.com/android/download_list.html Download SDK] and unzip it<br />
* system.img and userdata.img are [http://www.yaffs.net/ yaffs2] images. There is no way yet to mount them directly on a host to extract their content. An [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool is missing, so the only way to get the content is to start the emulator and extract the contents from running emulator.<br />
* As file system in emulator as no ''cp'' or ''tar'' command, we use a statically linked [http://www.busybox.net/ BusyBox] cross compiled for ARM and use it inside emulator (get it from [http://benno.id.au/blog/2007/11/14/android-busybox Benno] or build it your own with above tool chain).<br />
* Set path to emulator tools<br />
<br />
export PATH=${PATH}:<path_to>/android-sdk_m5-rc14_linux-x86/tools<br />
<br />
* Create an empty SDcard (image)<br />
<br />
[http://code.google.com/android/reference/othertools.html#mksdcard mksdcard] -l card 100M card.img<br />
<br />
* Start emulator<br />
<br />
[http://code.google.com/android/reference/emulator.html emulator] -sdcard card.img -console -debug-kernel<br />
<br />
* 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:<br />
<br />
[http://code.google.com/android/reference/adb.html adb] -d 1 push busybox /data/busybox<br />
<br />
* Inside emulation, set tar (and bzip2) links to busybox, tar ''/system'' and ''/data'' directories to sdcard.<br />
* Shutdown emulator, mount card.img<br />
<br />
mount -o loop card.img mnt/<br />
<br />
and get the images of system and user data.<br />
<br />
* 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:<br />
** Remove all content of ''data/dalvik-cache/''. It holds the decompressed files from the apk packages.<br />
** Remove the static busybox image. We only needed it for extraction and don't need it any more.<br />
<br />
''Note'': Anybody likes to hack this [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool? Then the system.img and userdata.img extraction would be a lot easier.<br />
<br />
''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. <br />
<br />
===Extracted binaries===<br />
<br />
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 ([[Android_on_OMAP#Extracted_patches|see above]]) version.<br />
<br />
* [http://benno.id.au/blog/2007/11/14/android-filesystems Android file system images], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android binaries extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
=Target=<br />
<br />
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.<br />
<br />
==Kernel configuration==<br />
<br />
Make sure your kernel boots normally on your board. Then enable some Android specific configuration (needs [[Android_on_OMAP#Kernel|kernel patch extracted above]]) and make sure that your kernel still boots (with your standard file system).<br />
<br />
''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. <br />
<br />
'''EABI'''<br />
<br />
CONFIG_AEABI=y<br />
# CONFIG_OABI_COMPAT is not set<br />
<br />
'''THUMB'''<br />
<br />
CONFIG_ARM_THUMB=y<br />
<br />
'''Android drivers'''<br />
<br />
#<br />
# Android<br />
#<br />
# CONFIG_ANDROID_GADGET is not set<br />
# CONFIG_ANDROID_RAM_CONSOLE is not set<br />
CONFIG_ANDROID_POWER=y<br />
CONFIG_ANDROID_POWER_STAT=y<br />
CONFIG_ANDROID_LOGGER=y<br />
# CONFIG_ANDROID_TIMED_GPIO is not set<br />
CONFIG_ANDROID_BINDER_IPC=y<br />
<br />
After you successfully booted the kernel with configuration above (and m5-rc14 kernel patch), make sure you have following /sys files:<br />
<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/last_user_activity<br />
/sys/android_power/request_sleep<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/battery_level<br />
/sys/android_power/battery_level_low<br />
/sys/android_power/battery_level_raw<br />
/sys/android_power/battery_level_scale<br />
/sys/android_power/battery_low_level<br />
/sys/android_power/battery_shutdown_level<br />
/sys/android_power/charging_state<br />
/sys/android_power/release_wake_lock<br />
/sys/android_power/request_state<br />
/sys/android_power/state<br />
<br />
==File system configuration==<br />
<br />
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.<br />
<br />
The Android file system we establish here on one of the the storage from above is built from four parts:<br />
<br />
* Content of system data image extracted above<br />
* Content of user data image extracted above (make sure temporary files are removed)<br />
* Content of Android ram disk image<br />
* Device file system <br />
<br />
To create Android file system, take (empty) storage you selected and start with ram disk:<br />
<br />
Android ram disk image can be found as ramdisk.img in tools/lib/images of Android SDK. This is a gziped cpio archive:<br />
<br />
cp ramdisk.img ramdisk.gz<br />
gunzip ramdisk.gz<br />
cd target_fs<br />
cpio -iv < ../ramdisk<br />
<br />
Result of this should be an root file system tree with:<br />
<br />
data<br />
dev<br />
etc<br />
init<br />
proc<br />
sbin<br />
sys<br />
system<br />
tmp<br />
var<br />
<br />
Directories data, dev and system are empty. Extract content of extracted user data image to /data and system image to /system directories. E.g.<br />
<br />
tar xvfj ../system_m5_rc14.tar.bz2 system/<br />
tar xvfj ../userdata_m5_rc14.tar.bz2 data/<br />
<br />
Note: This depends on how you named and stored extracted user data and system image above.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Start up==<br />
<br />
Starting Android using the file system and kernel created above, there are three ways:<br />
<br />
* Directly boot from Android kernel into the Android file system. I.e. let the Android kernel directly start init etc. from Android file system.<br />
* 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.<br />
* 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. <br />
<br />
===Android root file system===<br />
<br />
There are several ways to directly start Android from (root) file system created above:<br />
<br />
* 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<br />
* Use Android's shell and give kernel /system/bin/sh as init program. Then start Android's init manually (/init&) . <br />
<br />
===Start via scripts===<br />
<br />
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.<br />
<br />
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.<br />
<br />
start_android.sh in standard root file system:<br />
<br />
#!/bin/sh -x<br />
echo "Starting Android..."<br />
fsck.ext2 -pv /dev/sda1<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umount /proc<br />
umount /sys<br />
mount -t proc proc /mnt/usb/proc<br />
mount -t sysfs sysfs /mnt/usb/sys<br />
umask 000<br />
chroot /mnt/usb/a.sh<br />
<br />
a.sh to start Android at Android file system:<br />
<br />
#!/system/bin/sh -x<br />
<br />
export PATH=/sbin:/system/sbin:/system/bin:$PATH<br />
export LD_LIBRARY_PATH=/system/lib<br />
export ANDROID_ROOT=/system<br />
export ANDROID_ASSETS=/system/app<br />
export ANDROID_DATA=/data<br />
export EXTERNAL_STORAGE=/sdcard<br />
export DRM_CONTENT=/data/drm/content<br />
<br />
/system/bin/app_process -Xzygote /system/bin --zygote &<br />
/system/bin/dbus-daemon --system &<br />
runtime &<br />
/system/bin/sh<br />
<br />
Notes:<br />
<br />
* fsck.ext2 -pv /dev/sda1: Make sure ext2 file system is clean. ext2 doesn't like unclean switch off while debugging Android start up ;)<br />
* rm -f /mnt/usb/tmp/*: Remove Android temporary files before starting Android.<br />
* mount proc and mount sys: This has to be done somewhere. Depending on your scripts, you can do it in a.sh as well.<br />
* runtime: For debugging use here /system/bin/strace -f -ff -tt -s 200 runtime&.<br />
* 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 ;) <br />
<br />
===Start init via scripts===<br />
<br />
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.<br />
<br />
From standard non-Android file system this switch can look like:<br />
<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umask 000<br />
chroot /mnt/usb /init<br />
<br />
==Debugging==<br />
<br />
* Strace: The main debugging help currently known is [http://benno.id.au/blog/2007/11/18/android-runtime-strace strace]. Again, a statically linked one is used.<br />
** You should invoke strace with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, e.g.<br />
<br />
strace -f -ff -tt -s 200 /system/bin/runtime<br />
<br />
=FAQ=<br />
<br />
===Kernel patch===<br />
<br />
'''Q''': Above section about [[Android_on_OMAP#Patch_extraction|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? <br />
<br />
'''A''': Regarding m5-rc14 and kernel 2.6.23 the (changed) files below seem to be sufficient to run Android on real HW:<br />
<br />
arch/arm/Kconfig<br />
arch/arm/kernel/process.c<br />
arch/arm/kernel/signal.c<br />
drivers/android/alarm.c<br />
drivers/android/android_gadget.c<br />
drivers/android/android_kernel_debug.c<br />
drivers/android/android_kernel_debug.h<br />
drivers/android/binder.c<br />
drivers/android/Kconfig<br />
drivers/android/logger.c<br />
drivers/android/Makefile<br />
drivers/android/power.c<br />
drivers/android/ram_console.c<br />
drivers/android/timed_gpio.c<br />
drivers/input/evdev.c<br />
drivers/Kconfig<br />
drivers/misc/Kconfig<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
drivers/misc/lowmemorykiller/Makefile<br />
drivers/misc/Makefile<br />
fs/inotify_user.c<br />
include/linux/android_alarm.h<br />
include/linux/android_gadget.h<br />
include/linux/android_power.h<br />
include/linux/android_timed_gpio.h<br />
include/linux/binder_module.h<br />
include/linux/binder_type_constants.h<br />
include/linux/logger.h<br />
kernel/power/process.c<br />
drivers/Makefile<br />
<br />
===OpenBinder===<br />
<br />
'''Q''': When I extract the kernel patch, I additionally get a ''drivers/binder/'' directory. Why isn't it listed/needed above?<br />
<br />
'''A''': The ''drivers/binder/'' directory seems to contain [http://www.newmobilecomputing.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/ OpenBinder]. In Android m5-rc14 this seems to be [http://marc.info/?l=linux-omap&m=120417098706141&w=2 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.<br />
<br />
===Devices nodes===<br />
<br />
'''Q''': Do I need special devices nodes? Which?<br />
<br />
'''A''': [[Android_on_OMAP#File_System|Above]] we only extracted system and userdata image. If you like, you can extract /dev entries as well. However, starting Android's ''runtime'' under [[Android_on_OMAP#Debugging|strace]] control should give you a list which devices will be opened. Besides the standard ones you will need (incomplete?):<br />
<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 binder<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/radio<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/events<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/main<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 alarm<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 eac<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 graphics/fb0<br />
more ?<br />
<br />
===/dev/xxx minor numbers===<br />
<br />
'''Q''': Which minor number will I need for /dev/xxx entries above? E.g. for /dev/binder?<br />
<br />
'''A''': The major number 10 (major number for "misc" devices) above are for new drivers of m5-rc14. The minor numbers [http://marc.info/?l=linux-omap&m=120417584110733&w=2 would be as given] by cat /proc/misc. They are somehow board dependent and may change.<br />
<br />
E.g. in m5-rc14 emulator you may get:<br />
<br />
# cat /proc/misc<br />
58 binder<br />
59 log_radio<br />
60 log_events<br />
61 log_main<br />
62 alarm<br />
1 psaux<br />
63 eac<br />
<br />
With [[Android_on_OMAP#Patch_extraction|kernel patch on real HW]] you may get:<br />
<br />
# cat /proc/misc<br />
59 binder<br />
60 log_radio<br />
61 log_events<br />
62 log_main<br />
63 alarm<br />
<br />
===/dev/fb0===<br />
<br />
'''Q''': I have /dev/fb0, is this correct?<br />
<br />
'''A''': With m5-rc14 [http://androidzaurus.seesaa.net/article/84934031.html Google switched frame buffer interface] to /dev/graphics/fb0. So you need:<br />
<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 /dev/graphics/fb0<br />
<br />
===Blank screen===<br />
<br />
'''Q''': I did all steps like above, [[Android_on_OMAP#Debugging|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.<br />
<br />
'''A''': With m5-rc14 the frame buffer handling changed. You now need a frame buffer driver which [http://androidzaurus.seesaa.net/article/87808061.html supports double buffer/page flipping]. Observe the output of strace. If you get:<br />
<br />
...<br />
writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38<br />
open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21<br />
ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0<br />
writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, '''{"page flipping not supported (yres_virtual=640, requested=1280)\", 63}], 3)''' = 82<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
...<br />
<br />
your frame buffer driver doesn't support page flipping.<br />
<br />
''Note'': For above output, strace has to be invoked with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, else you wouldn't see this.<br />
<br />
===Page flipping frame buffer===<br />
<br />
'''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?<br />
<br />
'''A''': This depends on frame buffer driver.<br />
* For OMAP you can try following hack:<br />
<br />
Index: linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
===================================================================<br />
--- linux-omap-2_6_23.orig/drivers/video/omap/omapfb_main.c<br />
+++ linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
@@ -168,7 +168,7 @@ static int ctrl_init(struct omapfb_devic<br />
/* 12 bpp is packed in 16 bits */<br />
if (bpp == 12)<br />
bpp = 16;<br />
- def_size = def_vxres * def_vyres * bpp / 8;<br />
+ def_size = def_vxres * def_vyres * 2 * bpp / 8;<br />
fbdev->mem_desc.region_cnt = 1;<br />
fbdev->mem_desc.region[0].size = PAGE_ALIGN(def_size);<br />
}<br />
@@ -415,6 +415,7 @@ static void set_fb_fix(struct fb_info *f<br />
}<br />
fix->accel = FB_ACCEL_OMAP1610;<br />
fix->line_length = var->xres_virtual * bpp / 8;<br />
+ fix->ypanstep = 1;<br />
}<br />
<br />
static int set_color_mode(struct omapfb_plane_struct *plane,<br />
@@ -1471,7 +1472,7 @@ static int fbinfo_init(struct omapfb_dev<br />
var->xres = def_vxres;<br />
var->yres = def_vyres;<br />
var->xres_virtual = def_vxres;<br />
- var->yres_virtual = def_vyres;<br />
+ var->yres_virtual = def_vyres * 2;<br />
var->rotate = def_rotate;<br />
var->bits_per_pixel = fbdev->panel->bpp;<br />
<br />
<br />
(anybody with clean patch? ->[[Android_on_OMAP#Contact|contact]])<br />
<br />
* For Zaurus/pxafb have a look to following [http://androidzaurus.seesaa.net/article/87973048.html solution]. See [http://www.oesf.org/forum/index.php?s=b33968d11c595adb9ac146a6d4c59366&showtopic=25517&st=15&start=15 OESF] as well.<br />
<br />
===Android start crashes===<br />
<br />
'''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.<br />
<br />
'''A''': Make sure that you use kernel patch and file system from most [http://marc.info/?l=linux-omap&m=120392877715554&w=2 recent Android] release (currently m5-rc14). [http://marc.info/?l=linux-omap&m=120400983008672&w=2 Don't mix] kernel patch and file system from different versions.<br />
<br />
===Power management===<br />
<br />
'''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 [http://marc.info/?l=linux-omap&m=120470400929434&w=2 fake Android power management].<br />
<br />
'''A''': unknown yet :( There is some guessing and some workaround.<br />
<br />
* Some [http://androidzaurus.seesaa.net/article/87973048.html#comment guess from androidzaurus]. <br />
<br />
* Workaround reported from [http://marc.info/?l=linux-omap&m=120538179321533&w=2 Anil]: <br />
<br />
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<br />
<br />
android_power_suspend: enter suspend<br />
android_power_suspend: exit suspend, ret = -38<br />
android_power_suspend: pm_suspend returned with no event<br />
<br />
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<br />
<br />
android_power_wakeup 2->0 at 447592867845<br />
active wake lock PowerManagerService<br />
active wake lock KeyEvents<br />
android_power_suspend: done<br />
<br />
===TLS issue===<br />
<br />
'''Q''': What is this TLS issue?<br />
<br />
'''A''': Some newer ARM processors support [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] in hardware. With current (m5-rc14) Android release this [http://marc.info/?l=linux-omap&m=120384694214686&w=2 isn't supported] yet.<br />
<br />
===TLS issue and processors===<br />
<br />
'''Q''': Which processors have this TLS issue?<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120394328804005&w=2 ARMv6K (MPCORE) and ARMv7 (Cortex)]. Regarding OMAP, this is OMAP3 (Cortex). OMAP1 (ARM9) and OMAP2 (ARM11) don't have this issue.<br />
<br />
===TLS issue workaround===<br />
<br />
'''Q''': I'd like to use (m5-rc14) Android on processors with TLS issue, what can I do?<br />
<br />
'''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<br />
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,<br />
you really don't want to do this as it does cause a performance hit.<br />
<br />
diff -Naur 2.6_kernel-orig/arch/arm/mm/Kconfig 2.6_kernel-android/arch/arm/mm/Kconfig<br />
--- 2.6_kernel-orig/arch/arm/mm/Kconfig 2007-11-20 12:09:42.000000000-0600<br />
+++ 2.6_kernel-new/arch/arm/mm/Kconfig 2007-12-08 22:23:04.000000000-0600<br />
@@ -675,7 +675,7 @@<br />
config HAS_TLS_REG<br />
bool<br />
depends on !TLS_REG_EMUL<br />
- default y if SMP || CPU_32v7<br />
+ default y if SMP || CPU_32v7 && !ARCH_OMAP<br />
help<br />
This selects support for the CP15 thread register.<br />
It is defined to be available on some ARMv6 processors (including<br />
<br />
(Thanks to Keith Deacon!)<br />
<br />
''Note'': A [http://marc.info/?l=linux-omap&m=120400327301855&w=2 user report] wasn't quite successful regarding this.<br />
<br />
===Red cycle eye runtime speed===<br />
<br />
'''Q''': The red cycle eye runs very fast on my board, and the system_server take almost 100% CPU<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120399654528241&w=2 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.<br />
<br />
===File not found===<br />
<br />
'''Q''': At Android start up I get some ''File not found ...'' error messages like:<br />
<br />
Prepping: /system/app/AlarmClock.apk:/system/app/AlarmProvider.apk:...<br />
File not found: /system/app/AlarmClock.apk<br />
File not found: /system/app/AlarmProvider.apk<br />
File not found: /system/app/Anagrams.apk<br />
...<br />
File not found: /system/app/Vending.apk<br />
File not found: /system/app/VoiceDialer.apk<br />
File not found: /system/app/Voicemail.apk<br />
File not found: /system/app/YouTube.apk<br />
Prep complete<br />
<br />
Do I have to care about these?<br />
<br />
'''A''': No, it doesn't seem so. See [http://benno.id.au/blog/2007/11/18/android-framework-startup Benno's blog], section Manual startup.<br />
<br />
===Limited main memory===<br />
<br />
'''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?<br />
<br />
'''A''': Try to enable lowmemorykiller:<br />
<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
<br />
For this, in kernel enable<br />
<br />
CONFIG_LOW_MEMORY_KILLER=y<br />
<br />
in Device drivers -> Misc devices. At Android startup this then results in messages like<br />
<br />
...<br />
send sigkill to 920 (app_process), adj 1, size 1838<br />
...<br />
<br />
===Some buttons work, some not===<br />
<br />
'''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?<br />
<br />
'''A''': From [http://marc.info/?l=linux-omap&m=120749091514894&w=2 Brian at OMAP ML]:<br />
<br />
''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.''<br />
<br />
===Filesystem, JFFS2 and SIGSEGV===<br />
<br />
'''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?<br />
<br />
'''A''': Don't use JFFS2 as file system for Android. [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/71709fc4adcb2ddd Android does not support JFFS]. Use an ext2/3 formatted medium. Or use YAFFS2 if you use a NAND device (as emulator does).<br />
<br />
===Using JFFS2===<br />
<br />
'''Q''': Okay, I understand from above that Android doesn't support JFFS2. But, maybe there is a hack to try?<br />
<br />
'''A''': You could try what [http://marc.info/?l=linux-omap&m=120946006920397&w=2 Brian] reports:<br />
<br />
''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 /.''<br />
<br />
''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.''<br />
<br />
===Nokia N8x0 and Android SDK===<br />
<br />
'''Q''': I'd like to run [[Android_on_OMAP#Screenshots|Android on Nokia N8x0]] ([http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57 link 1], [http://code.google.com/p/android-on-n8xx/ link 2]). Which [http://code.google.com/p/android/downloads/list Android SDK] should I use? Can I use m5-rc14/15 SDK?<br />
<br />
'''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.<br />
<br />
m5 user space will '''not''' work, because it needs [[Android_on_OMAP#Page_flipping_frame_buffer|page flipping frame buffer]] and N8x0 fb driver doesn't support this.<br />
<br />
===N8x0 and recent OMAP git kernel===<br />
'''Q''': I'd like to use recent OMAP git kernel on N8x0. What do I need to run git kernel on N8x0?<br />
<br />
'''A''': Have a look to Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel].<br />
<br />
===N810 keys===<br />
<br />
'''Q''': How do I get the N810 keyboard to work with Android?<br />
<br />
'''A''': Try the following [http://groups.google.com/group/android-internals/msg/04f842aa0710932a changes] to get most of N810 keys working with Android, except Fn and the numbers:<br />
<br />
Just update one file: /system/usr/keylayout/qwerty.kl<br />
<br />
-key 158 BACK WAKE_DROPPED<br />
+key 1 BACK WAKE_DROPPED<br />
key 230 SOFT_RIGHT WAKE<br />
key 60 SOFT_RIGHT WAKE<br />
key 107 ENDCALL WAKE_DROPPED<br />
key 62 ENDCALL WAKE_DROPPED<br />
-key 229 SOFT_LEFT WAKE_DROPPED<br />
+key 62 SOFT_LEFT WAKE_DROPPED<br />
key 59 SOFT_LEFT WAKE_DROPPED<br />
key 139 SOFT_LEFT WAKE_DROPPED<br />
key 228 POUND<br />
key 227 STAR<br />
key 231 CALL WAKE_DROPPED<br />
key 61 CALL WAKE_DROPPED<br />
-key 232 DPAD_CENTER WAKE_DROPPED<br />
+key 96 DPAD_CENTER WAKE_DROPPED<br />
key 108 DPAD_DOWN WAKE_DROPPED<br />
key 103 DPAD_UP WAKE_DROPPED<br />
-key 102 HOME WAKE<br />
+key 63 HOME WAKE<br />
key 105 DPAD_LEFT WAKE_DROPPED<br />
key 106 DPAD_RIGHT WAKE_DROPPED<br />
-key 115 VOLUME_UP<br />
-key 114 VOLUME_DOWN<br />
+key 65 VOLUME_UP<br />
+key 66 VOLUME_DOWN<br />
<br />
===N8x0 touchscreen===<br />
<br />
'''Q''': Is there any way to get N8x0 touchscreen working with Android?<br />
<br />
'''A''': Yes. There is a [http://groups.google.com/group/android-internals/msg/7c6ff76e0381e95a patch] you can apply to a nokia+android patched 2.6.21 kernel and you should<br />
have a working touchscreen.<br />
<br />
===HW interfaces support===<br />
<br />
'''Q''': Which hardware interfaces or kernel drivers does current Android support?<br />
<br />
'''A''': See discussion on [http://marc.info/?l=linux-omap&m=120946406828608&w=2 OMAP ML]:<br />
<br />
> I was able to add support for the keypad, touch and network in Android,<br />
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D<br />
> acceleration, battery etc. are not integrated with Android right now. I<br />
> would appreciate if you could throw some light on these open issues. How<br />
> exactly can these interfaces be integrated with Android? <br />
<br />
We're trying to use the standard kernel/driver interfaces when possible,<br />
but for things that may have a good deal of variation in implementation,<br />
we're looking to provide a very thin "hardware interface library" layer<br />
to adapt between the bottom of the userspace stack and the drivers or<br />
whatnot for specific hardware platforms. <br />
<br />
We'll continue to adopt standardized kernel solutions as they become<br />
available -- We're now using the power supply framework in 2.6.24 for<br />
monitoring battery/charge state (post M5 SDK -- it'll be in the next <br />
release), for example.<br />
<br />
=Links=<br />
<br />
* [http://code.google.com/android/ Android] homepage<br />
* [http://benno.id.au/blog/ Bennos blog] with lot of reverse engineering info about Android<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Android on Zaurus]<br />
* [http://www.kandroid.org Korea Android Community] <br />
''Note'':Connect this site using http://www.google.com/translate website.<br />
* Linux devices about [http://www.linuxdevices.com/news/NS4262102607.html Penguinistas hack Android onto real hardware]<br />
* [http://tree.celinuxforum.org/CelfPubWiki/Jamboree18AndroidDemo Google Android on Working Target]<br />
* [http://code.google.com/android/groups.html Android discussion groups]. These concentrate more on Android application programming. Not really HW and processor related.<br />
* [http://www.oesf.org/forum/index.php?showforum=158 Open Embedded Software Foundation Android forum]. Discussion, support and general information about running Android on a handheld.<br />
* [http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en Porting Android to real HW at Android internals list]<br />
* [http://nemustech.blogspot.com/2007/12/android-porting-to-real-target-hw.html Android Porting to Real Target HW]<br />
* [http://code.google.com/p/android-on-n8xx/ Android on Nokia 8xx]<br />
* Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel]<br />
* [http://forums.lugradio.org/viewtopic.php?f=4&t=4094#p41437 Robert Love talks about Google Android]. Recorded at [http://www.lugradio.org/live/USA2008/ LUG Radio Live USA 2008] at the Metreon Theatre, San Francisco.<br />
<br />
''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.<br />
<br />
=Contact=<br />
<br />
See [http://vger.kernel.org/vger-lists.html#linux-omap OMAP mailing list] for more information.<br />
<br />
This page is distilled by [mailto:dirk.behme@gmail.com Dirk Behme] and information added by [mailto:leemgs@gmail.com Lim,GeunSik].<br />
<br />
=Screenshots=<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.23 on OMAP5912 [[OSK|OSK]]: <br />
<br />
[[Image:Android m5 rc14 omap osk kernel 2 6 23.jpg]]<br />
<br />
* Android m5-rc14 kernel + m3 image, on a Nokia N810:<br />
<br />
[[Image:Cimg0608.jpg]]<br />
<br />
<br />
[[Image:Cimg0610.jpg]]<br />
<br />
<br />
[[Image:Cimg0611.jpg]]<br />
<br />
<br />
* Android m5-rc15 home screen with kernel 2.6.18 on armadillo-500 1136 ([http://www.youtube.com/watch?v=jGvGl0nOQNo YouTube Movie])<br />
<br />
[[Image:androidarmadillo200804.jpg]]<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.19 on OMAP2430 [[OSK|OSK]]:<br />
-If you have unstable sdcard, You will meet for Looping of "Red Eye" Status.<br />
[[Image:omap2evm.android.PNG]]<br />
<br />
<br />
* Android m5-rc14 on Nokia's n810 Tablet<br />
[[Image:n810.kandroid200805.PNG]]</div>Anil Shttps://elinux.org/index.php?title=Android_on_OMAP&diff=6495Android on OMAP2008-07-16T12:49:02Z<p>Anil S: /* Real hardware */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This page collects information about and guides you through the installation of [http://www.google.de/ Google's] [http://code.google.com/android/ Android] on [http://www.ti.com/ TI's] [http://www.arm.com/ ARM] based [http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4752 OMAP] [http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638&DCMP=WTBU&HQS=Other+OT+omap SoCs].<br />
<br />
''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.<br />
<br />
''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.<br />
<br />
=Android=<br />
<br />
==What is Android (not)==<br />
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. See [http://code.google.com/android/what-is-android.html Google's ''What is Android?''] page and [http://benno.id.au/blog/2007/11/26/what-is-android Benno's ''What is Android?'' and ''What Android isn't''] page for more details about Android.<br />
<br />
==Versions==<br />
<br />
From time to time Google updates their [http://code.google.com/android/download_previous.html 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).<br />
<br />
=Hardware=<br />
<br />
==Goldfish==<br />
Android SDK isn't targeted for a special (ARM) SoC. Instead, they use [http://fabrice.bellard.free.fr/qemu/ 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.<br />
<br />
This virtual ARM SoC comprises:<br />
<br />
* ARM926ej-S CPU<br />
* Thumb support<br />
* MMC<br />
* RTC<br />
* Keyboard<br />
* USB Gadget<br />
* Framebuffer<br />
* TTY driver<br />
* NAND<br />
* Software compiled for ARMv5TEJ instruction set (!) with EABI<br />
* no [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] [http://marc.info/?l=linux-omap&m=120384694214686&w=2 yet]<br />
<br />
==Real hardware==<br />
<br />
Running Android on real hardware, some prerequisites should be fulfilled:<br />
<br />
* SoC with ARM926 or higher (e.g. ARM11) (check [http://marc.info/?l=linux-omap&m=120394328104000&w=2 ARM MPCore or ARM Cortex] regarding [[Android_on_OMAP#TLS_issue|TLS issue]])<br />
** Note: ARM920T with ARMv4 instruction set [http://benno.id.au/blog/2007/11/21/android-neo1973 will not work]<br />
* You have already a recent (~2.6.23) Linux kernel with Thumb & MMU & EABI etc support running on your target<br />
* Soc/HW has and Linux kernel supports<br />
** Display/frame buffer (touchscreen would be good but optional). Frame buffer ''has'' to support [[Android_on_OMAP#Page_flipping_frame_buffer|double buffer/page flipping]].<br />
** Keyboard<br />
** USB (optional)<br />
** RTC (optional?)<br />
** Serial console<br />
** 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<br />
** 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.<br />
<br />
<br />
'''Known to work HW'''<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP1 based boards] (ARM v5 ARM926)<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP2 based boards] (ARM v6 ARM11)<br />
* [http://www.mistralsolutions.com/assets/downloads/2530.php omap2530evm] 2430OSK is renamed as 2530EVM based on TI's recommendation (ARM v6 ARM1136jf-s)<br />
* [http://euedge.com/blog/2007/12/06/google-android-runs-on-sharp-zaurus-sl-c760/ Sharp Zaurus SL-C760(PXA255)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C1000(PXA270)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C3000](PXA270)<br />
* [http://www.atmark-techno.com/en/products/armadillo/a500 Armadillo-500] and [http://youtube.com/watch?v=eFxnCaEwL_U Armadillo Panel Computer] (Freescale i.MX31L ARM11)<br />
* OMAP1 based [[OSK]] (OMAP5912 ARM926 with only 32MB SDRAM). Really slow, mainly usable as ''proof of concept''.<br />
* OMAP2 based OMAP2420 [http://www.nokiausa.com/A4626058 N810]: [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57?hl=en& Android internals ML], [http://marc.info/?l=linux-omap&m=120741537025066&w=2 OMAP ML] and [http://code.google.com/p/android-on-n8xx/ Android on N810] page. <br />
* OMAP3 based OMAP3EVM from Mistral (Android runs on ARMv7)<br />
<br />
'''Known to not work HW'''<br />
* [http://benno.id.au/blog/2007/11/21/android-neo1973 Neo 1973] (ARM920T)<br />
<br />
=Compiler=<br />
Getting Android working on real hardware, you need an [http://wiki.debian.org/ArmEabiPort 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 [http://www.codesourcery.com/ CodeSourcery's] [http://www.codesourcery.com/gnu_toolchains/arm/download.html '''ARM GNU/Linux''' tool chain].<br />
<br />
''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.<br />
<br />
=Code=<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Kernel==<br />
<br />
On [http://code.google.com/p/android/downloads/list 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.<br />
<br />
===Patch extraction===<br />
<br />
See third paragraph of [http://benno.id.au/blog/2007/11/21/android-neo1973 Benno's Android on NEO 1973 article].<br />
<br />
* Download matching version (e.g. m5-rc14) of [http://code.google.com/p/android/downloads/list Android kernel source]. Besides complete kernel source this will contain Android specific changes.<br />
* 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.<br />
* 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 [http://www.yaffs.net/ 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 [[Android_on_OMAP#OpenBinder|OpenBinder related files]] (/driver/binder) as well. [[Android_on_OMAP#Kernel_patch|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.<br />
<br />
''Note'': There seems to be [http://marc.info/?l=linux-omap&m=120384694214686&w=2 some effort] to make Android kernel patches available in a easier usable format.<br />
<br />
===Extracted patches===<br />
<br />
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 ([[Android_on_OMAP#Extracted_binaries|see below]]) version.<br />
<br />
* [http://benno.id.au/android/android-noqemu-nogoldfish-noyaffs2.diff Benno's no Qemu no goldfish no yaffs2 patch], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android patches extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
===Git patches===<br />
<br />
There are Android kernel patches available using [http://git.android.com/?p=kernel.git;a=shortlog;h=android Android's git] repository. But have a look to [http://marc.info/?l=linux-omap&m=120716474803274&w=2 Brian's notes] regarding this.<br />
<br />
==File System==<br />
<br />
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 [http://marc.info/?l=linux-omap&m=120368832309928&w=2 Google itself and eventually WindRiver].<br />
<br />
Again, there are two ways to get user space binaries: Extracting them your self or taking already extracted ones.<br />
<br />
===Binary extraction===<br />
<br />
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.<br />
<br />
* [http://code.google.com/android/download_list.html Download SDK] and unzip it<br />
* system.img and userdata.img are [http://www.yaffs.net/ yaffs2] images. There is no way yet to mount them directly on a host to extract their content. An [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool is missing, so the only way to get the content is to start the emulator and extract the contents from running emulator.<br />
* As file system in emulator as no ''cp'' or ''tar'' command, we use a statically linked [http://www.busybox.net/ BusyBox] cross compiled for ARM and use it inside emulator (get it from [http://benno.id.au/blog/2007/11/14/android-busybox Benno] or build it your own with above tool chain).<br />
* Set path to emulator tools<br />
<br />
export PATH=${PATH}:<path_to>/android-sdk_m5-rc14_linux-x86/tools<br />
<br />
* Create an empty SDcard (image)<br />
<br />
[http://code.google.com/android/reference/othertools.html#mksdcard mksdcard] -l card 100M card.img<br />
<br />
* Start emulator<br />
<br />
[http://code.google.com/android/reference/emulator.html emulator] -sdcard card.img -console -debug-kernel<br />
<br />
* 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:<br />
<br />
[http://code.google.com/android/reference/adb.html adb] -d 1 push busybox /data/busybox<br />
<br />
* Inside emulation, set tar (and bzip2) links to busybox, tar ''/system'' and ''/data'' directories to sdcard.<br />
* Shutdown emulator, mount card.img<br />
<br />
mount -o loop card.img mnt/<br />
<br />
and get the images of system and user data.<br />
<br />
* 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:<br />
** Remove all content of ''data/dalvik-cache/''. It holds the decompressed files from the apk packages.<br />
** Remove the static busybox image. We only needed it for extraction and don't need it any more.<br />
<br />
''Note'': Anybody likes to hack this [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool? Then the system.img and userdata.img extraction would be a lot easier.<br />
<br />
''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. <br />
<br />
===Extracted binaries===<br />
<br />
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 ([[Android_on_OMAP#Extracted_patches|see above]]) version.<br />
<br />
* [http://benno.id.au/blog/2007/11/14/android-filesystems Android file system images], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android binaries extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
=Target=<br />
<br />
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.<br />
<br />
==Kernel configuration==<br />
<br />
Make sure your kernel boots normally on your board. Then enable some Android specific configuration (needs [[Android_on_OMAP#Kernel|kernel patch extracted above]]) and make sure that your kernel still boots (with your standard file system).<br />
<br />
''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. <br />
<br />
'''EABI'''<br />
<br />
CONFIG_AEABI=y<br />
# CONFIG_OABI_COMPAT is not set<br />
<br />
'''THUMB'''<br />
<br />
CONFIG_ARM_THUMB=y<br />
<br />
'''Android drivers'''<br />
<br />
#<br />
# Android<br />
#<br />
# CONFIG_ANDROID_GADGET is not set<br />
# CONFIG_ANDROID_RAM_CONSOLE is not set<br />
CONFIG_ANDROID_POWER=y<br />
CONFIG_ANDROID_POWER_STAT=y<br />
CONFIG_ANDROID_LOGGER=y<br />
# CONFIG_ANDROID_TIMED_GPIO is not set<br />
CONFIG_ANDROID_BINDER_IPC=y<br />
<br />
After you successfully booted the kernel with configuration above (and m5-rc14 kernel patch), make sure you have following /sys files:<br />
<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/last_user_activity<br />
/sys/android_power/request_sleep<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/battery_level<br />
/sys/android_power/battery_level_low<br />
/sys/android_power/battery_level_raw<br />
/sys/android_power/battery_level_scale<br />
/sys/android_power/battery_low_level<br />
/sys/android_power/battery_shutdown_level<br />
/sys/android_power/charging_state<br />
/sys/android_power/release_wake_lock<br />
/sys/android_power/request_state<br />
/sys/android_power/state<br />
<br />
==File system configuration==<br />
<br />
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.<br />
<br />
The Android file system we establish here on one of the the storage from above is built from four parts:<br />
<br />
* Content of system data image extracted above<br />
* Content of user data image extracted above (make sure temporary files are removed)<br />
* Content of Android ram disk image<br />
* Device file system <br />
<br />
To create Android file system, take (empty) storage you selected and start with ram disk:<br />
<br />
Android ram disk image can be found as ramdisk.img in tools/lib/images of Android SDK. This is a gziped cpio archive:<br />
<br />
cp ramdisk.img ramdisk.gz<br />
gunzip ramdisk.gz<br />
cd target_fs<br />
cpio -iv < ../ramdisk<br />
<br />
Result of this should be an root file system tree with:<br />
<br />
data<br />
dev<br />
etc<br />
init<br />
proc<br />
sbin<br />
sys<br />
system<br />
tmp<br />
var<br />
<br />
Directories data, dev and system are empty. Extract content of extracted user data image to /data and system image to /system directories. E.g.<br />
<br />
tar xvfj ../system_m5_rc14.tar.bz2 system/<br />
tar xvfj ../userdata_m5_rc14.tar.bz2 data/<br />
<br />
Note: This depends on how you named and stored extracted user data and system image above.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Start up==<br />
<br />
Starting Android using the file system and kernel created above, there are three ways:<br />
<br />
* Directly boot from Android kernel into the Android file system. I.e. let the Android kernel directly start init etc. from Android file system.<br />
* 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.<br />
* 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. <br />
<br />
===Android root file system===<br />
<br />
There are several ways to directly start Android from (root) file system created above:<br />
<br />
* 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<br />
* Use Android's shell and give kernel /system/bin/sh as init program. Then start Android's init manually (/init&) . <br />
<br />
===Start via scripts===<br />
<br />
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.<br />
<br />
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.<br />
<br />
start_android.sh in standard root file system:<br />
<br />
#!/bin/sh -x<br />
echo "Starting Android..."<br />
fsck.ext2 -pv /dev/sda1<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umount /proc<br />
umount /sys<br />
mount -t proc proc /mnt/usb/proc<br />
mount -t sysfs sysfs /mnt/usb/sys<br />
umask 000<br />
chroot /mnt/usb/a.sh<br />
<br />
a.sh to start Android at Android file system:<br />
<br />
#!/system/bin/sh -x<br />
<br />
export PATH=/sbin:/system/sbin:/system/bin:$PATH<br />
export LD_LIBRARY_PATH=/system/lib<br />
export ANDROID_ROOT=/system<br />
export ANDROID_ASSETS=/system/app<br />
export ANDROID_DATA=/data<br />
export EXTERNAL_STORAGE=/sdcard<br />
export DRM_CONTENT=/data/drm/content<br />
<br />
/system/bin/app_process -Xzygote /system/bin --zygote &<br />
/system/bin/dbus-daemon --system &<br />
runtime &<br />
/system/bin/sh<br />
<br />
Notes:<br />
<br />
* fsck.ext2 -pv /dev/sda1: Make sure ext2 file system is clean. ext2 doesn't like unclean switch off while debugging Android start up ;)<br />
* rm -f /mnt/usb/tmp/*: Remove Android temporary files before starting Android.<br />
* mount proc and mount sys: This has to be done somewhere. Depending on your scripts, you can do it in a.sh as well.<br />
* runtime: For debugging use here /system/bin/strace -f -ff -tt -s 200 runtime&.<br />
* 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 ;) <br />
<br />
===Start init via scripts===<br />
<br />
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.<br />
<br />
From standard non-Android file system this switch can look like:<br />
<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umask 000<br />
chroot /mnt/usb /init<br />
<br />
==Debugging==<br />
<br />
* Strace: The main debugging help currently known is [http://benno.id.au/blog/2007/11/18/android-runtime-strace strace]. Again, a statically linked one is used.<br />
** You should invoke strace with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, e.g.<br />
<br />
strace -f -ff -tt -s 200 /system/bin/runtime<br />
<br />
=FAQ=<br />
<br />
===Kernel patch===<br />
<br />
'''Q''': Above section about [[Android_on_OMAP#Patch_extraction|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? <br />
<br />
'''A''': Regarding m5-rc14 and kernel 2.6.23 the (changed) files below seem to be sufficient to run Android on real HW:<br />
<br />
arch/arm/Kconfig<br />
arch/arm/kernel/process.c<br />
arch/arm/kernel/signal.c<br />
drivers/android/alarm.c<br />
drivers/android/android_gadget.c<br />
drivers/android/android_kernel_debug.c<br />
drivers/android/android_kernel_debug.h<br />
drivers/android/binder.c<br />
drivers/android/Kconfig<br />
drivers/android/logger.c<br />
drivers/android/Makefile<br />
drivers/android/power.c<br />
drivers/android/ram_console.c<br />
drivers/android/timed_gpio.c<br />
drivers/input/evdev.c<br />
drivers/Kconfig<br />
drivers/misc/Kconfig<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
drivers/misc/lowmemorykiller/Makefile<br />
drivers/misc/Makefile<br />
fs/inotify_user.c<br />
include/linux/android_alarm.h<br />
include/linux/android_gadget.h<br />
include/linux/android_power.h<br />
include/linux/android_timed_gpio.h<br />
include/linux/binder_module.h<br />
include/linux/binder_type_constants.h<br />
include/linux/logger.h<br />
kernel/power/process.c<br />
drivers/Makefile<br />
<br />
===OpenBinder===<br />
<br />
'''Q''': When I extract the kernel patch, I additionally get a ''drivers/binder/'' directory. Why isn't it listed/needed above?<br />
<br />
'''A''': The ''drivers/binder/'' directory seems to contain [http://www.newmobilecomputing.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/ OpenBinder]. In Android m5-rc14 this seems to be [http://marc.info/?l=linux-omap&m=120417098706141&w=2 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.<br />
<br />
===Devices nodes===<br />
<br />
'''Q''': Do I need special devices nodes? Which?<br />
<br />
'''A''': [[Android_on_OMAP#File_System|Above]] we only extracted system and userdata image. If you like, you can extract /dev entries as well. However, starting Android's ''runtime'' under [[Android_on_OMAP#Debugging|strace]] control should give you a list which devices will be opened. Besides the standard ones you will need (incomplete?):<br />
<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 binder<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/radio<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/events<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/main<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 alarm<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 eac<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 graphics/fb0<br />
more ?<br />
<br />
===/dev/xxx minor numbers===<br />
<br />
'''Q''': Which minor number will I need for /dev/xxx entries above? E.g. for /dev/binder?<br />
<br />
'''A''': The major number 10 (major number for "misc" devices) above are for new drivers of m5-rc14. The minor numbers [http://marc.info/?l=linux-omap&m=120417584110733&w=2 would be as given] by cat /proc/misc. They are somehow board dependent and may change.<br />
<br />
E.g. in m5-rc14 emulator you may get:<br />
<br />
# cat /proc/misc<br />
58 binder<br />
59 log_radio<br />
60 log_events<br />
61 log_main<br />
62 alarm<br />
1 psaux<br />
63 eac<br />
<br />
With [[Android_on_OMAP#Patch_extraction|kernel patch on real HW]] you may get:<br />
<br />
# cat /proc/misc<br />
59 binder<br />
60 log_radio<br />
61 log_events<br />
62 log_main<br />
63 alarm<br />
<br />
===/dev/fb0===<br />
<br />
'''Q''': I have /dev/fb0, is this correct?<br />
<br />
'''A''': With m5-rc14 [http://androidzaurus.seesaa.net/article/84934031.html Google switched frame buffer interface] to /dev/graphics/fb0. So you need:<br />
<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 /dev/graphics/fb0<br />
<br />
===Blank screen===<br />
<br />
'''Q''': I did all steps like above, [[Android_on_OMAP#Debugging|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.<br />
<br />
'''A''': With m5-rc14 the frame buffer handling changed. You now need a frame buffer driver which [http://androidzaurus.seesaa.net/article/87808061.html supports double buffer/page flipping]. Observe the output of strace. If you get:<br />
<br />
...<br />
writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38<br />
open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21<br />
ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0<br />
writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, '''{"page flipping not supported (yres_virtual=640, requested=1280)\", 63}], 3)''' = 82<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
...<br />
<br />
your frame buffer driver doesn't support page flipping.<br />
<br />
''Note'': For above output, strace has to be invoked with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, else you wouldn't see this.<br />
<br />
===Page flipping frame buffer===<br />
<br />
'''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?<br />
<br />
'''A''': This depends on frame buffer driver.<br />
* For OMAP you can try following hack:<br />
<br />
Index: linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
===================================================================<br />
--- linux-omap-2_6_23.orig/drivers/video/omap/omapfb_main.c<br />
+++ linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
@@ -168,7 +168,7 @@ static int ctrl_init(struct omapfb_devic<br />
/* 12 bpp is packed in 16 bits */<br />
if (bpp == 12)<br />
bpp = 16;<br />
- def_size = def_vxres * def_vyres * bpp / 8;<br />
+ def_size = def_vxres * def_vyres * 2 * bpp / 8;<br />
fbdev->mem_desc.region_cnt = 1;<br />
fbdev->mem_desc.region[0].size = PAGE_ALIGN(def_size);<br />
}<br />
@@ -415,6 +415,7 @@ static void set_fb_fix(struct fb_info *f<br />
}<br />
fix->accel = FB_ACCEL_OMAP1610;<br />
fix->line_length = var->xres_virtual * bpp / 8;<br />
+ fix->ypanstep = 1;<br />
}<br />
<br />
static int set_color_mode(struct omapfb_plane_struct *plane,<br />
@@ -1471,7 +1472,7 @@ static int fbinfo_init(struct omapfb_dev<br />
var->xres = def_vxres;<br />
var->yres = def_vyres;<br />
var->xres_virtual = def_vxres;<br />
- var->yres_virtual = def_vyres;<br />
+ var->yres_virtual = def_vyres * 2;<br />
var->rotate = def_rotate;<br />
var->bits_per_pixel = fbdev->panel->bpp;<br />
<br />
<br />
(anybody with clean patch? ->[[Android_on_OMAP#Contact|contact]])<br />
<br />
* For Zaurus/pxafb have a look to following [http://androidzaurus.seesaa.net/article/87973048.html solution]. See [http://www.oesf.org/forum/index.php?s=b33968d11c595adb9ac146a6d4c59366&showtopic=25517&st=15&start=15 OESF] as well.<br />
<br />
===Android start crashes===<br />
<br />
'''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.<br />
<br />
'''A''': Make sure that you use kernel patch and file system from most [http://marc.info/?l=linux-omap&m=120392877715554&w=2 recent Android] release (currently m5-rc14). [http://marc.info/?l=linux-omap&m=120400983008672&w=2 Don't mix] kernel patch and file system from different versions.<br />
<br />
===Power management===<br />
<br />
'''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 [http://marc.info/?l=linux-omap&m=120470400929434&w=2 fake Android power management].<br />
<br />
'''A''': unknown yet :( There is some guessing and some workaround.<br />
<br />
* Some [http://androidzaurus.seesaa.net/article/87973048.html#comment guess from androidzaurus]. <br />
<br />
* Workaround reported from [http://marc.info/?l=linux-omap&m=120538179321533&w=2 Anil]: <br />
<br />
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<br />
<br />
android_power_suspend: enter suspend<br />
android_power_suspend: exit suspend, ret = -38<br />
android_power_suspend: pm_suspend returned with no event<br />
<br />
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<br />
<br />
android_power_wakeup 2->0 at 447592867845<br />
active wake lock PowerManagerService<br />
active wake lock KeyEvents<br />
android_power_suspend: done<br />
<br />
===TLS issue===<br />
<br />
'''Q''': What is this TLS issue?<br />
<br />
'''A''': Some newer ARM processors support [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] in hardware. With current (m5-rc14) Android release this [http://marc.info/?l=linux-omap&m=120384694214686&w=2 isn't supported] yet.<br />
<br />
===TLS issue and processors===<br />
<br />
'''Q''': Which processors have this TLS issue?<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120394328804005&w=2 ARMv6K (MPCORE) and ARMv7 (Cortex)]. Regarding OMAP, this is OMAP3 (Cortex). OMAP1 (ARM9) and OMAP2 (ARM11) don't have this issue.<br />
<br />
===TLS issue workaround===<br />
<br />
'''Q''': I'd like to use (m5-rc14) Android on processors with TLS issue, what can I do?<br />
<br />
'''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<br />
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,<br />
you really don't want to do this as it does cause a performance hit.<br />
<br />
diff -Naur 2.6_kernel-orig/arch/arm/mm/Kconfig 2.6_kernel-android/arch/arm/mm/Kconfig<br />
--- 2.6_kernel-orig/arch/arm/mm/Kconfig 2007-11-20 12:09:42.000000000-0600<br />
+++ 2.6_kernel-new/arch/arm/mm/Kconfig 2007-12-08 22:23:04.000000000-0600<br />
@@ -675,7 +675,7 @@<br />
config HAS_TLS_REG<br />
bool<br />
depends on !TLS_REG_EMUL<br />
- default y if SMP || CPU_32v7<br />
+ default y if SMP || CPU_32v7 && !ARCH_OMAP<br />
help<br />
This selects support for the CP15 thread register.<br />
It is defined to be available on some ARMv6 processors (including<br />
<br />
(Thanks to Keith Deacon!)<br />
<br />
''Note'': A [http://marc.info/?l=linux-omap&m=120400327301855&w=2 user report] wasn't quite successful regarding this.<br />
<br />
===Red cycle eye runtime speed===<br />
<br />
'''Q''': The red cycle eye runs very fast on my board, and the system_server take almost 100% CPU<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120399654528241&w=2 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.<br />
<br />
===File not found===<br />
<br />
'''Q''': At Android start up I get some ''File not found ...'' error messages like:<br />
<br />
Prepping: /system/app/AlarmClock.apk:/system/app/AlarmProvider.apk:...<br />
File not found: /system/app/AlarmClock.apk<br />
File not found: /system/app/AlarmProvider.apk<br />
File not found: /system/app/Anagrams.apk<br />
...<br />
File not found: /system/app/Vending.apk<br />
File not found: /system/app/VoiceDialer.apk<br />
File not found: /system/app/Voicemail.apk<br />
File not found: /system/app/YouTube.apk<br />
Prep complete<br />
<br />
Do I have to care about these?<br />
<br />
'''A''': No, it doesn't seem so. See [http://benno.id.au/blog/2007/11/18/android-framework-startup Benno's blog], section Manual startup.<br />
<br />
===Limited main memory===<br />
<br />
'''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?<br />
<br />
'''A''': Try to enable lowmemorykiller:<br />
<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
<br />
For this, in kernel enable<br />
<br />
CONFIG_LOW_MEMORY_KILLER=y<br />
<br />
in Device drivers -> Misc devices. At Android startup this then results in messages like<br />
<br />
...<br />
send sigkill to 920 (app_process), adj 1, size 1838<br />
...<br />
<br />
===Some buttons work, some not===<br />
<br />
'''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?<br />
<br />
'''A''': From [http://marc.info/?l=linux-omap&m=120749091514894&w=2 Brian at OMAP ML]:<br />
<br />
''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.''<br />
<br />
===Filesystem, JFFS2 and SIGSEGV===<br />
<br />
'''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?<br />
<br />
'''A''': Don't use JFFS2 as file system for Android. [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/71709fc4adcb2ddd Android does not support JFFS]. Use an ext2/3 formatted medium. Or use YAFFS2 if you use a NAND device (as emulator does).<br />
<br />
===Using JFFS2===<br />
<br />
'''Q''': Okay, I understand from above that Android doesn't support JFFS2. But, maybe there is a hack to try?<br />
<br />
'''A''': You could try what [http://marc.info/?l=linux-omap&m=120946006920397&w=2 Brian] reports:<br />
<br />
''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 /.''<br />
<br />
''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.''<br />
<br />
===Nokia N8x0 and Android SDK===<br />
<br />
'''Q''': I'd like to run [[Android_on_OMAP#Screenshots|Android on Nokia N8x0]] ([http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57 link 1], [http://code.google.com/p/android-on-n8xx/ link 2]). Which [http://code.google.com/p/android/downloads/list Android SDK] should I use? Can I use m5-rc14/15 SDK?<br />
<br />
'''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.<br />
<br />
m5 user space will '''not''' work, because it needs [[Android_on_OMAP#Page_flipping_frame_buffer|page flipping frame buffer]] and N8x0 fb driver doesn't support this.<br />
<br />
===N8x0 and recent OMAP git kernel===<br />
'''Q''': I'd like to use recent OMAP git kernel on N8x0. What do I need to run git kernel on N8x0?<br />
<br />
'''A''': Have a look to Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel].<br />
<br />
===N810 keys===<br />
<br />
'''Q''': How do I get the N810 keyboard to work with Android?<br />
<br />
'''A''': Try the following [http://groups.google.com/group/android-internals/msg/04f842aa0710932a changes] to get most of N810 keys working with Android, except Fn and the numbers:<br />
<br />
Just update one file: /system/usr/keylayout/qwerty.kl<br />
<br />
-key 158 BACK WAKE_DROPPED<br />
+key 1 BACK WAKE_DROPPED<br />
key 230 SOFT_RIGHT WAKE<br />
key 60 SOFT_RIGHT WAKE<br />
key 107 ENDCALL WAKE_DROPPED<br />
key 62 ENDCALL WAKE_DROPPED<br />
-key 229 SOFT_LEFT WAKE_DROPPED<br />
+key 62 SOFT_LEFT WAKE_DROPPED<br />
key 59 SOFT_LEFT WAKE_DROPPED<br />
key 139 SOFT_LEFT WAKE_DROPPED<br />
key 228 POUND<br />
key 227 STAR<br />
key 231 CALL WAKE_DROPPED<br />
key 61 CALL WAKE_DROPPED<br />
-key 232 DPAD_CENTER WAKE_DROPPED<br />
+key 96 DPAD_CENTER WAKE_DROPPED<br />
key 108 DPAD_DOWN WAKE_DROPPED<br />
key 103 DPAD_UP WAKE_DROPPED<br />
-key 102 HOME WAKE<br />
+key 63 HOME WAKE<br />
key 105 DPAD_LEFT WAKE_DROPPED<br />
key 106 DPAD_RIGHT WAKE_DROPPED<br />
-key 115 VOLUME_UP<br />
-key 114 VOLUME_DOWN<br />
+key 65 VOLUME_UP<br />
+key 66 VOLUME_DOWN<br />
<br />
===N8x0 touchscreen===<br />
<br />
'''Q''': Is there any way to get N8x0 touchscreen working with Android?<br />
<br />
'''A''': Yes. There is a [http://groups.google.com/group/android-internals/msg/7c6ff76e0381e95a patch] you can apply to a nokia+android patched 2.6.21 kernel and you should<br />
have a working touchscreen.<br />
<br />
===HW interfaces support===<br />
<br />
'''Q''': Which hardware interfaces or kernel drivers does current Android support?<br />
<br />
'''A''': See discussion on [http://marc.info/?l=linux-omap&m=120946406828608&w=2 OMAP ML]:<br />
<br />
> I was able to add support for the keypad, touch and network in Android,<br />
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D<br />
> acceleration, battery etc. are not integrated with Android right now. I<br />
> would appreciate if you could throw some light on these open issues. How<br />
> exactly can these interfaces be integrated with Android? <br />
<br />
We're trying to use the standard kernel/driver interfaces when possible,<br />
but for things that may have a good deal of variation in implementation,<br />
we're looking to provide a very thin "hardware interface library" layer<br />
to adapt between the bottom of the userspace stack and the drivers or<br />
whatnot for specific hardware platforms. <br />
<br />
We'll continue to adopt standardized kernel solutions as they become<br />
available -- We're now using the power supply framework in 2.6.24 for<br />
monitoring battery/charge state (post M5 SDK -- it'll be in the next <br />
release), for example.<br />
<br />
=Links=<br />
<br />
* [http://code.google.com/android/ Android] homepage<br />
* [http://benno.id.au/blog/ Bennos blog] with lot of reverse engineering info about Android<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Android on Zaurus]<br />
* [http://www.kandroid.org Korea Android Community] <br />
''Note'':Connect this site using http://www.google.com/translate website.<br />
* Linux devices about [http://www.linuxdevices.com/news/NS4262102607.html Penguinistas hack Android onto real hardware]<br />
* [http://tree.celinuxforum.org/CelfPubWiki/Jamboree18AndroidDemo Google Android on Working Target]<br />
* [http://code.google.com/android/groups.html Android discussion groups]. These concentrate more on Android application programming. Not really HW and processor related.<br />
* [http://www.oesf.org/forum/index.php?showforum=158 Open Embedded Software Foundation Android forum]. Discussion, support and general information about running Android on a handheld.<br />
* [http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en Porting Android to real HW at Android internals list]<br />
* [http://nemustech.blogspot.com/2007/12/android-porting-to-real-target-hw.html Android Porting to Real Target HW]<br />
* [http://code.google.com/p/android-on-n8xx/ Android on Nokia 8xx]<br />
* Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel]<br />
* [http://forums.lugradio.org/viewtopic.php?f=4&t=4094#p41437 Robert Love talks about Google Android]. Recorded at [http://www.lugradio.org/live/USA2008/ LUG Radio Live USA 2008] at the Metreon Theatre, San Francisco.<br />
<br />
''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.<br />
<br />
=Contact=<br />
<br />
See [http://vger.kernel.org/vger-lists.html#linux-omap OMAP mailing list] for more information.<br />
<br />
This page is distilled by [mailto:dirk.behme@gmail.com Dirk Behme] and information added by [mailto:leemgs@gmail.com Lim,GeunSik].<br />
<br />
=Screenshots=<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.23 on OMAP5912 [[OSK|OSK]]: <br />
<br />
[[Image:Android m5 rc14 omap osk kernel 2 6 23.jpg]]<br />
<br />
* Android m5-rc14 kernel + m3 image, on a Nokia N810:<br />
<br />
[[Image:Cimg0608.jpg]]<br />
<br />
<br />
[[Image:Cimg0610.jpg]]<br />
<br />
<br />
[[Image:Cimg0611.jpg]]<br />
<br />
<br />
* Android m5-rc15 home screen with kernel 2.6.18 on armadillo-500 1136 ([http://www.youtube.com/watch?v=jGvGl0nOQNo YouTube Movie])<br />
<br />
[[Image:androidarmadillo200804.jpg]]<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.19 on OMAP2430 [[OSK|OSK]]:<br />
-If you have unstable sdcard, You will meet for Looping of "Red Eye" Status.<br />
[[Image:omap2evm.android.PNG]]<br />
<br />
<br />
* Android m5-rc14 on Nokia's n810 Tablet<br />
[[Image:n810.kandroid200805.PNG]]</div>Anil Shttps://elinux.org/index.php?title=Android_on_OMAP&diff=6494Android on OMAP2008-07-16T12:48:16Z<p>Anil S: /* Real hardware */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This page collects information about and guides you through the installation of [http://www.google.de/ Google's] [http://code.google.com/android/ Android] on [http://www.ti.com/ TI's] [http://www.arm.com/ ARM] based [http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4752 OMAP] [http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638&DCMP=WTBU&HQS=Other+OT+omap SoCs].<br />
<br />
''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.<br />
<br />
''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.<br />
<br />
=Android=<br />
<br />
==What is Android (not)==<br />
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. See [http://code.google.com/android/what-is-android.html Google's ''What is Android?''] page and [http://benno.id.au/blog/2007/11/26/what-is-android Benno's ''What is Android?'' and ''What Android isn't''] page for more details about Android.<br />
<br />
==Versions==<br />
<br />
From time to time Google updates their [http://code.google.com/android/download_previous.html 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).<br />
<br />
=Hardware=<br />
<br />
==Goldfish==<br />
Android SDK isn't targeted for a special (ARM) SoC. Instead, they use [http://fabrice.bellard.free.fr/qemu/ 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.<br />
<br />
This virtual ARM SoC comprises:<br />
<br />
* ARM926ej-S CPU<br />
* Thumb support<br />
* MMC<br />
* RTC<br />
* Keyboard<br />
* USB Gadget<br />
* Framebuffer<br />
* TTY driver<br />
* NAND<br />
* Software compiled for ARMv5TEJ instruction set (!) with EABI<br />
* no [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] [http://marc.info/?l=linux-omap&m=120384694214686&w=2 yet]<br />
<br />
==Real hardware==<br />
<br />
Running Android on real hardware, some prerequisites should be fulfilled:<br />
<br />
* SoC with ARM926 or higher (e.g. ARM11) (check [http://marc.info/?l=linux-omap&m=120394328104000&w=2 ARM MPCore or ARM Cortex] regarding [[Android_on_OMAP#TLS_issue|TLS issue]])<br />
** Note: ARM920T with ARMv4 instruction set [http://benno.id.au/blog/2007/11/21/android-neo1973 will not work]<br />
* You have already a recent (~2.6.23) Linux kernel with Thumb & MMU & EABI etc support running on your target<br />
* Soc/HW has and Linux kernel supports<br />
** Display/frame buffer (touchscreen would be good but optional). Frame buffer ''has'' to support [[Android_on_OMAP#Page_flipping_frame_buffer|double buffer/page flipping]].<br />
** Keyboard<br />
** USB (optional)<br />
** RTC (optional?)<br />
** Serial console<br />
** 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<br />
** 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.<br />
<br />
<br />
'''Known to work HW'''<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP1 based boards] (ARM v5 ARM926)<br />
* [http://marc.info/?l=linux-omap&m=120368832309928&w=2 OMAP2 based boards] (ARM v6 ARM11)<br />
* [http://www.mistralsolutions.com/assets/downloads/2530.php omap2530evm] 2430OSK is renamed as 2530EVM based on TI's recommendation (ARM v6 ARM1136jf-s)<br />
* [http://euedge.com/blog/2007/12/06/google-android-runs-on-sharp-zaurus-sl-c760/ Sharp Zaurus SL-C760(PXA255)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C1000(PXA270)]<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Sharp Zaurus SL-C3000](PXA270)<br />
* [http://www.atmark-techno.com/en/products/armadillo/a500 Armadillo-500] and [http://youtube.com/watch?v=eFxnCaEwL_U Armadillo Panel Computer] (Freescale i.MX31L ARM11)<br />
* OMAP1 based [[OSK]] (OMAP5912 ARM926 with only 32MB SDRAM). Really slow, mainly usable as ''proof of concept''.<br />
* OMAP2 based OMAP2420 [http://www.nokiausa.com/A4626058 N810]: [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57?hl=en& Android internals ML], [http://marc.info/?l=linux-omap&m=120741537025066&w=2 OMAP ML] and [http://code.google.com/p/android-on-n8xx/ Android on N810] page. <br />
* OMAP3430 based OMAP3 EVM from Mistral [http://www.nokiausa.com/A4626058 N810]: (Android runs on ARMv7)<br />
<br />
'''Known to not work HW'''<br />
* [http://benno.id.au/blog/2007/11/21/android-neo1973 Neo 1973] (ARM920T)<br />
<br />
=Compiler=<br />
Getting Android working on real hardware, you need an [http://wiki.debian.org/ArmEabiPort 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 [http://www.codesourcery.com/ CodeSourcery's] [http://www.codesourcery.com/gnu_toolchains/arm/download.html '''ARM GNU/Linux''' tool chain].<br />
<br />
''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.<br />
<br />
=Code=<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Kernel==<br />
<br />
On [http://code.google.com/p/android/downloads/list 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.<br />
<br />
===Patch extraction===<br />
<br />
See third paragraph of [http://benno.id.au/blog/2007/11/21/android-neo1973 Benno's Android on NEO 1973 article].<br />
<br />
* Download matching version (e.g. m5-rc14) of [http://code.google.com/p/android/downloads/list Android kernel source]. Besides complete kernel source this will contain Android specific changes.<br />
* 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.<br />
* 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 [http://www.yaffs.net/ 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 [[Android_on_OMAP#OpenBinder|OpenBinder related files]] (/driver/binder) as well. [[Android_on_OMAP#Kernel_patch|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.<br />
<br />
''Note'': There seems to be [http://marc.info/?l=linux-omap&m=120384694214686&w=2 some effort] to make Android kernel patches available in a easier usable format.<br />
<br />
===Extracted patches===<br />
<br />
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 ([[Android_on_OMAP#Extracted_binaries|see below]]) version.<br />
<br />
* [http://benno.id.au/android/android-noqemu-nogoldfish-noyaffs2.diff Benno's no Qemu no goldfish no yaffs2 patch], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android patches extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
===Git patches===<br />
<br />
There are Android kernel patches available using [http://git.android.com/?p=kernel.git;a=shortlog;h=android Android's git] repository. But have a look to [http://marc.info/?l=linux-omap&m=120716474803274&w=2 Brian's notes] regarding this.<br />
<br />
==File System==<br />
<br />
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 [http://marc.info/?l=linux-omap&m=120368832309928&w=2 Google itself and eventually WindRiver].<br />
<br />
Again, there are two ways to get user space binaries: Extracting them your self or taking already extracted ones.<br />
<br />
===Binary extraction===<br />
<br />
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.<br />
<br />
* [http://code.google.com/android/download_list.html Download SDK] and unzip it<br />
* system.img and userdata.img are [http://www.yaffs.net/ yaffs2] images. There is no way yet to mount them directly on a host to extract their content. An [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool is missing, so the only way to get the content is to start the emulator and extract the contents from running emulator.<br />
* As file system in emulator as no ''cp'' or ''tar'' command, we use a statically linked [http://www.busybox.net/ BusyBox] cross compiled for ARM and use it inside emulator (get it from [http://benno.id.au/blog/2007/11/14/android-busybox Benno] or build it your own with above tool chain).<br />
* Set path to emulator tools<br />
<br />
export PATH=${PATH}:<path_to>/android-sdk_m5-rc14_linux-x86/tools<br />
<br />
* Create an empty SDcard (image)<br />
<br />
[http://code.google.com/android/reference/othertools.html#mksdcard mksdcard] -l card 100M card.img<br />
<br />
* Start emulator<br />
<br />
[http://code.google.com/android/reference/emulator.html emulator] -sdcard card.img -console -debug-kernel<br />
<br />
* 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:<br />
<br />
[http://code.google.com/android/reference/adb.html adb] -d 1 push busybox /data/busybox<br />
<br />
* Inside emulation, set tar (and bzip2) links to busybox, tar ''/system'' and ''/data'' directories to sdcard.<br />
* Shutdown emulator, mount card.img<br />
<br />
mount -o loop card.img mnt/<br />
<br />
and get the images of system and user data.<br />
<br />
* 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:<br />
** Remove all content of ''data/dalvik-cache/''. It holds the decompressed files from the apk packages.<br />
** Remove the static busybox image. We only needed it for extraction and don't need it any more.<br />
<br />
''Note'': Anybody likes to hack this [http://lists.aleph1.co.uk/lurker/message/20080218.222359.6cc4bd2e.en.html ''unyaffs''] tool? Then the system.img and userdata.img extraction would be a lot easier.<br />
<br />
''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. <br />
<br />
===Extracted binaries===<br />
<br />
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 ([[Android_on_OMAP#Extracted_patches|see above]]) version.<br />
<br />
* [http://benno.id.au/blog/2007/11/14/android-filesystems Android file system images], as of date of Benno's article most probably based on m3-rc20.<br />
<br />
''Note'': Some guys on OMAP mailing list have Android binaries extracted (currently from m5-rc14) and [http://marc.info/?l=linux-omap&m=120401478515308&w=2 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 [http://vger.kernel.org/vger-lists.html#linux-omap OMAP list].<br />
<br />
=Target=<br />
<br />
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.<br />
<br />
==Kernel configuration==<br />
<br />
Make sure your kernel boots normally on your board. Then enable some Android specific configuration (needs [[Android_on_OMAP#Kernel|kernel patch extracted above]]) and make sure that your kernel still boots (with your standard file system).<br />
<br />
''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. <br />
<br />
'''EABI'''<br />
<br />
CONFIG_AEABI=y<br />
# CONFIG_OABI_COMPAT is not set<br />
<br />
'''THUMB'''<br />
<br />
CONFIG_ARM_THUMB=y<br />
<br />
'''Android drivers'''<br />
<br />
#<br />
# Android<br />
#<br />
# CONFIG_ANDROID_GADGET is not set<br />
# CONFIG_ANDROID_RAM_CONSOLE is not set<br />
CONFIG_ANDROID_POWER=y<br />
CONFIG_ANDROID_POWER_STAT=y<br />
CONFIG_ANDROID_LOGGER=y<br />
# CONFIG_ANDROID_TIMED_GPIO is not set<br />
CONFIG_ANDROID_BINDER_IPC=y<br />
<br />
After you successfully booted the kernel with configuration above (and m5-rc14 kernel patch), make sure you have following /sys files:<br />
<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/last_user_activity<br />
/sys/android_power/request_sleep<br />
/sys/android_power/acquire_full_wake_lock<br />
/sys/android_power/acquire_partial_wake_lock<br />
/sys/android_power/battery_level<br />
/sys/android_power/battery_level_low<br />
/sys/android_power/battery_level_raw<br />
/sys/android_power/battery_level_scale<br />
/sys/android_power/battery_low_level<br />
/sys/android_power/battery_shutdown_level<br />
/sys/android_power/charging_state<br />
/sys/android_power/release_wake_lock<br />
/sys/android_power/request_state<br />
/sys/android_power/state<br />
<br />
==File system configuration==<br />
<br />
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.<br />
<br />
The Android file system we establish here on one of the the storage from above is built from four parts:<br />
<br />
* Content of system data image extracted above<br />
* Content of user data image extracted above (make sure temporary files are removed)<br />
* Content of Android ram disk image<br />
* Device file system <br />
<br />
To create Android file system, take (empty) storage you selected and start with ram disk:<br />
<br />
Android ram disk image can be found as ramdisk.img in tools/lib/images of Android SDK. This is a gziped cpio archive:<br />
<br />
cp ramdisk.img ramdisk.gz<br />
gunzip ramdisk.gz<br />
cd target_fs<br />
cpio -iv < ../ramdisk<br />
<br />
Result of this should be an root file system tree with:<br />
<br />
data<br />
dev<br />
etc<br />
init<br />
proc<br />
sbin<br />
sys<br />
system<br />
tmp<br />
var<br />
<br />
Directories data, dev and system are empty. Extract content of extracted user data image to /data and system image to /system directories. E.g.<br />
<br />
tar xvfj ../system_m5_rc14.tar.bz2 system/<br />
tar xvfj ../userdata_m5_rc14.tar.bz2 data/<br />
<br />
Note: This depends on how you named and stored extracted user data and system image above.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Start up==<br />
<br />
Starting Android using the file system and kernel created above, there are three ways:<br />
<br />
* Directly boot from Android kernel into the Android file system. I.e. let the Android kernel directly start init etc. from Android file system.<br />
* 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.<br />
* 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. <br />
<br />
===Android root file system===<br />
<br />
There are several ways to directly start Android from (root) file system created above:<br />
<br />
* 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<br />
* Use Android's shell and give kernel /system/bin/sh as init program. Then start Android's init manually (/init&) . <br />
<br />
===Start via scripts===<br />
<br />
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.<br />
<br />
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.<br />
<br />
start_android.sh in standard root file system:<br />
<br />
#!/bin/sh -x<br />
echo "Starting Android..."<br />
fsck.ext2 -pv /dev/sda1<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umount /proc<br />
umount /sys<br />
mount -t proc proc /mnt/usb/proc<br />
mount -t sysfs sysfs /mnt/usb/sys<br />
umask 000<br />
chroot /mnt/usb/a.sh<br />
<br />
a.sh to start Android at Android file system:<br />
<br />
#!/system/bin/sh -x<br />
<br />
export PATH=/sbin:/system/sbin:/system/bin:$PATH<br />
export LD_LIBRARY_PATH=/system/lib<br />
export ANDROID_ROOT=/system<br />
export ANDROID_ASSETS=/system/app<br />
export ANDROID_DATA=/data<br />
export EXTERNAL_STORAGE=/sdcard<br />
export DRM_CONTENT=/data/drm/content<br />
<br />
/system/bin/app_process -Xzygote /system/bin --zygote &<br />
/system/bin/dbus-daemon --system &<br />
runtime &<br />
/system/bin/sh<br />
<br />
Notes:<br />
<br />
* fsck.ext2 -pv /dev/sda1: Make sure ext2 file system is clean. ext2 doesn't like unclean switch off while debugging Android start up ;)<br />
* rm -f /mnt/usb/tmp/*: Remove Android temporary files before starting Android.<br />
* mount proc and mount sys: This has to be done somewhere. Depending on your scripts, you can do it in a.sh as well.<br />
* runtime: For debugging use here /system/bin/strace -f -ff -tt -s 200 runtime&.<br />
* 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 ;) <br />
<br />
===Start init via scripts===<br />
<br />
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.<br />
<br />
From standard non-Android file system this switch can look like:<br />
<br />
mount /dev/sda1 /mnt/usb<br />
rm -f /mnt/usb/tmp/*<br />
umask 000<br />
chroot /mnt/usb /init<br />
<br />
==Debugging==<br />
<br />
* Strace: The main debugging help currently known is [http://benno.id.au/blog/2007/11/18/android-runtime-strace strace]. Again, a statically linked one is used.<br />
** You should invoke strace with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, e.g.<br />
<br />
strace -f -ff -tt -s 200 /system/bin/runtime<br />
<br />
=FAQ=<br />
<br />
===Kernel patch===<br />
<br />
'''Q''': Above section about [[Android_on_OMAP#Patch_extraction|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? <br />
<br />
'''A''': Regarding m5-rc14 and kernel 2.6.23 the (changed) files below seem to be sufficient to run Android on real HW:<br />
<br />
arch/arm/Kconfig<br />
arch/arm/kernel/process.c<br />
arch/arm/kernel/signal.c<br />
drivers/android/alarm.c<br />
drivers/android/android_gadget.c<br />
drivers/android/android_kernel_debug.c<br />
drivers/android/android_kernel_debug.h<br />
drivers/android/binder.c<br />
drivers/android/Kconfig<br />
drivers/android/logger.c<br />
drivers/android/Makefile<br />
drivers/android/power.c<br />
drivers/android/ram_console.c<br />
drivers/android/timed_gpio.c<br />
drivers/input/evdev.c<br />
drivers/Kconfig<br />
drivers/misc/Kconfig<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
drivers/misc/lowmemorykiller/Makefile<br />
drivers/misc/Makefile<br />
fs/inotify_user.c<br />
include/linux/android_alarm.h<br />
include/linux/android_gadget.h<br />
include/linux/android_power.h<br />
include/linux/android_timed_gpio.h<br />
include/linux/binder_module.h<br />
include/linux/binder_type_constants.h<br />
include/linux/logger.h<br />
kernel/power/process.c<br />
drivers/Makefile<br />
<br />
===OpenBinder===<br />
<br />
'''Q''': When I extract the kernel patch, I additionally get a ''drivers/binder/'' directory. Why isn't it listed/needed above?<br />
<br />
'''A''': The ''drivers/binder/'' directory seems to contain [http://www.newmobilecomputing.com/story/13674/Introduction-to-OpenBinder-and-Interview-with-Dianne-Hackborn/ OpenBinder]. In Android m5-rc14 this seems to be [http://marc.info/?l=linux-omap&m=120417098706141&w=2 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.<br />
<br />
===Devices nodes===<br />
<br />
'''Q''': Do I need special devices nodes? Which?<br />
<br />
'''A''': [[Android_on_OMAP#File_System|Above]] we only extracted system and userdata image. If you like, you can extract /dev entries as well. However, starting Android's ''runtime'' under [[Android_on_OMAP#Debugging|strace]] control should give you a list which devices will be opened. Besides the standard ones you will need (incomplete?):<br />
<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 binder<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/radio<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/events<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 log/main<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 alarm<br />
crw-rw-rw- 1 root root 10, x Jan 1 00:00 eac<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 graphics/fb0<br />
more ?<br />
<br />
===/dev/xxx minor numbers===<br />
<br />
'''Q''': Which minor number will I need for /dev/xxx entries above? E.g. for /dev/binder?<br />
<br />
'''A''': The major number 10 (major number for "misc" devices) above are for new drivers of m5-rc14. The minor numbers [http://marc.info/?l=linux-omap&m=120417584110733&w=2 would be as given] by cat /proc/misc. They are somehow board dependent and may change.<br />
<br />
E.g. in m5-rc14 emulator you may get:<br />
<br />
# cat /proc/misc<br />
58 binder<br />
59 log_radio<br />
60 log_events<br />
61 log_main<br />
62 alarm<br />
1 psaux<br />
63 eac<br />
<br />
With [[Android_on_OMAP#Patch_extraction|kernel patch on real HW]] you may get:<br />
<br />
# cat /proc/misc<br />
59 binder<br />
60 log_radio<br />
61 log_events<br />
62 log_main<br />
63 alarm<br />
<br />
===/dev/fb0===<br />
<br />
'''Q''': I have /dev/fb0, is this correct?<br />
<br />
'''A''': With m5-rc14 [http://androidzaurus.seesaa.net/article/84934031.html Google switched frame buffer interface] to /dev/graphics/fb0. So you need:<br />
<br />
crw-rw-rw- 1 root root 29, 0 Jan 1 00:00 /dev/graphics/fb0<br />
<br />
===Blank screen===<br />
<br />
'''Q''': I did all steps like above, [[Android_on_OMAP#Debugging|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.<br />
<br />
'''A''': With m5-rc14 the frame buffer handling changed. You now need a frame buffer driver which [http://androidzaurus.seesaa.net/article/87808061.html supports double buffer/page flipping]. Observe the output of strace. If you get:<br />
<br />
...<br />
writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38<br />
open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21<br />
ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0<br />
writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, '''{"page flipping not supported (yres_virtual=640, requested=1280)\", 63}], 3)''' = 82<br />
ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0<br />
...<br />
<br />
your frame buffer driver doesn't support page flipping.<br />
<br />
''Note'': For above output, strace has to be invoked with [http://marc.info/?l=linux-omap&m=120410568226398&w=2 ''-f -ff -tt -s 200''] options, else you wouldn't see this.<br />
<br />
===Page flipping frame buffer===<br />
<br />
'''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?<br />
<br />
'''A''': This depends on frame buffer driver.<br />
* For OMAP you can try following hack:<br />
<br />
Index: linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
===================================================================<br />
--- linux-omap-2_6_23.orig/drivers/video/omap/omapfb_main.c<br />
+++ linux-omap-2_6_23/drivers/video/omap/omapfb_main.c<br />
@@ -168,7 +168,7 @@ static int ctrl_init(struct omapfb_devic<br />
/* 12 bpp is packed in 16 bits */<br />
if (bpp == 12)<br />
bpp = 16;<br />
- def_size = def_vxres * def_vyres * bpp / 8;<br />
+ def_size = def_vxres * def_vyres * 2 * bpp / 8;<br />
fbdev->mem_desc.region_cnt = 1;<br />
fbdev->mem_desc.region[0].size = PAGE_ALIGN(def_size);<br />
}<br />
@@ -415,6 +415,7 @@ static void set_fb_fix(struct fb_info *f<br />
}<br />
fix->accel = FB_ACCEL_OMAP1610;<br />
fix->line_length = var->xres_virtual * bpp / 8;<br />
+ fix->ypanstep = 1;<br />
}<br />
<br />
static int set_color_mode(struct omapfb_plane_struct *plane,<br />
@@ -1471,7 +1472,7 @@ static int fbinfo_init(struct omapfb_dev<br />
var->xres = def_vxres;<br />
var->yres = def_vyres;<br />
var->xres_virtual = def_vxres;<br />
- var->yres_virtual = def_vyres;<br />
+ var->yres_virtual = def_vyres * 2;<br />
var->rotate = def_rotate;<br />
var->bits_per_pixel = fbdev->panel->bpp;<br />
<br />
<br />
(anybody with clean patch? ->[[Android_on_OMAP#Contact|contact]])<br />
<br />
* For Zaurus/pxafb have a look to following [http://androidzaurus.seesaa.net/article/87973048.html solution]. See [http://www.oesf.org/forum/index.php?s=b33968d11c595adb9ac146a6d4c59366&showtopic=25517&st=15&start=15 OESF] as well.<br />
<br />
===Android start crashes===<br />
<br />
'''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.<br />
<br />
'''A''': Make sure that you use kernel patch and file system from most [http://marc.info/?l=linux-omap&m=120392877715554&w=2 recent Android] release (currently m5-rc14). [http://marc.info/?l=linux-omap&m=120400983008672&w=2 Don't mix] kernel patch and file system from different versions.<br />
<br />
===Power management===<br />
<br />
'''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 [http://marc.info/?l=linux-omap&m=120470400929434&w=2 fake Android power management].<br />
<br />
'''A''': unknown yet :( There is some guessing and some workaround.<br />
<br />
* Some [http://androidzaurus.seesaa.net/article/87973048.html#comment guess from androidzaurus]. <br />
<br />
* Workaround reported from [http://marc.info/?l=linux-omap&m=120538179321533&w=2 Anil]: <br />
<br />
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<br />
<br />
android_power_suspend: enter suspend<br />
android_power_suspend: exit suspend, ret = -38<br />
android_power_suspend: pm_suspend returned with no event<br />
<br />
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<br />
<br />
android_power_wakeup 2->0 at 447592867845<br />
active wake lock PowerManagerService<br />
active wake lock KeyEvents<br />
android_power_suspend: done<br />
<br />
===TLS issue===<br />
<br />
'''Q''': What is this TLS issue?<br />
<br />
'''A''': Some newer ARM processors support [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/CIAIIFIB.html TLS] in hardware. With current (m5-rc14) Android release this [http://marc.info/?l=linux-omap&m=120384694214686&w=2 isn't supported] yet.<br />
<br />
===TLS issue and processors===<br />
<br />
'''Q''': Which processors have this TLS issue?<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120394328804005&w=2 ARMv6K (MPCORE) and ARMv7 (Cortex)]. Regarding OMAP, this is OMAP3 (Cortex). OMAP1 (ARM9) and OMAP2 (ARM11) don't have this issue.<br />
<br />
===TLS issue workaround===<br />
<br />
'''Q''': I'd like to use (m5-rc14) Android on processors with TLS issue, what can I do?<br />
<br />
'''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<br />
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,<br />
you really don't want to do this as it does cause a performance hit.<br />
<br />
diff -Naur 2.6_kernel-orig/arch/arm/mm/Kconfig 2.6_kernel-android/arch/arm/mm/Kconfig<br />
--- 2.6_kernel-orig/arch/arm/mm/Kconfig 2007-11-20 12:09:42.000000000-0600<br />
+++ 2.6_kernel-new/arch/arm/mm/Kconfig 2007-12-08 22:23:04.000000000-0600<br />
@@ -675,7 +675,7 @@<br />
config HAS_TLS_REG<br />
bool<br />
depends on !TLS_REG_EMUL<br />
- default y if SMP || CPU_32v7<br />
+ default y if SMP || CPU_32v7 && !ARCH_OMAP<br />
help<br />
This selects support for the CP15 thread register.<br />
It is defined to be available on some ARMv6 processors (including<br />
<br />
(Thanks to Keith Deacon!)<br />
<br />
''Note'': A [http://marc.info/?l=linux-omap&m=120400327301855&w=2 user report] wasn't quite successful regarding this.<br />
<br />
===Red cycle eye runtime speed===<br />
<br />
'''Q''': The red cycle eye runs very fast on my board, and the system_server take almost 100% CPU<br />
<br />
'''A''': [http://marc.info/?l=linux-omap&m=120399654528241&w=2 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.<br />
<br />
===File not found===<br />
<br />
'''Q''': At Android start up I get some ''File not found ...'' error messages like:<br />
<br />
Prepping: /system/app/AlarmClock.apk:/system/app/AlarmProvider.apk:...<br />
File not found: /system/app/AlarmClock.apk<br />
File not found: /system/app/AlarmProvider.apk<br />
File not found: /system/app/Anagrams.apk<br />
...<br />
File not found: /system/app/Vending.apk<br />
File not found: /system/app/VoiceDialer.apk<br />
File not found: /system/app/Voicemail.apk<br />
File not found: /system/app/YouTube.apk<br />
Prep complete<br />
<br />
Do I have to care about these?<br />
<br />
'''A''': No, it doesn't seem so. See [http://benno.id.au/blog/2007/11/18/android-framework-startup Benno's blog], section Manual startup.<br />
<br />
===Limited main memory===<br />
<br />
'''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?<br />
<br />
'''A''': Try to enable lowmemorykiller:<br />
<br />
drivers/misc/lowmemorykiller/lowmemorykiller.c<br />
<br />
For this, in kernel enable<br />
<br />
CONFIG_LOW_MEMORY_KILLER=y<br />
<br />
in Device drivers -> Misc devices. At Android startup this then results in messages like<br />
<br />
...<br />
send sigkill to 920 (app_process), adj 1, size 1838<br />
...<br />
<br />
===Some buttons work, some not===<br />
<br />
'''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?<br />
<br />
'''A''': From [http://marc.info/?l=linux-omap&m=120749091514894&w=2 Brian at OMAP ML]:<br />
<br />
''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.''<br />
<br />
===Filesystem, JFFS2 and SIGSEGV===<br />
<br />
'''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?<br />
<br />
'''A''': Don't use JFFS2 as file system for Android. [http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/71709fc4adcb2ddd Android does not support JFFS]. Use an ext2/3 formatted medium. Or use YAFFS2 if you use a NAND device (as emulator does).<br />
<br />
===Using JFFS2===<br />
<br />
'''Q''': Okay, I understand from above that Android doesn't support JFFS2. But, maybe there is a hack to try?<br />
<br />
'''A''': You could try what [http://marc.info/?l=linux-omap&m=120946006920397&w=2 Brian] reports:<br />
<br />
''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 /.''<br />
<br />
''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.''<br />
<br />
===Nokia N8x0 and Android SDK===<br />
<br />
'''Q''': I'd like to run [[Android_on_OMAP#Screenshots|Android on Nokia N8x0]] ([http://groups.google.com/group/android-internals/browse_thread/thread/7028432fa76f57e8/1556f431d3eb1e57 link 1], [http://code.google.com/p/android-on-n8xx/ link 2]). Which [http://code.google.com/p/android/downloads/list Android SDK] should I use? Can I use m5-rc14/15 SDK?<br />
<br />
'''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.<br />
<br />
m5 user space will '''not''' work, because it needs [[Android_on_OMAP#Page_flipping_frame_buffer|page flipping frame buffer]] and N8x0 fb driver doesn't support this.<br />
<br />
===N8x0 and recent OMAP git kernel===<br />
'''Q''': I'd like to use recent OMAP git kernel on N8x0. What do I need to run git kernel on N8x0?<br />
<br />
'''A''': Have a look to Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel].<br />
<br />
===N810 keys===<br />
<br />
'''Q''': How do I get the N810 keyboard to work with Android?<br />
<br />
'''A''': Try the following [http://groups.google.com/group/android-internals/msg/04f842aa0710932a changes] to get most of N810 keys working with Android, except Fn and the numbers:<br />
<br />
Just update one file: /system/usr/keylayout/qwerty.kl<br />
<br />
-key 158 BACK WAKE_DROPPED<br />
+key 1 BACK WAKE_DROPPED<br />
key 230 SOFT_RIGHT WAKE<br />
key 60 SOFT_RIGHT WAKE<br />
key 107 ENDCALL WAKE_DROPPED<br />
key 62 ENDCALL WAKE_DROPPED<br />
-key 229 SOFT_LEFT WAKE_DROPPED<br />
+key 62 SOFT_LEFT WAKE_DROPPED<br />
key 59 SOFT_LEFT WAKE_DROPPED<br />
key 139 SOFT_LEFT WAKE_DROPPED<br />
key 228 POUND<br />
key 227 STAR<br />
key 231 CALL WAKE_DROPPED<br />
key 61 CALL WAKE_DROPPED<br />
-key 232 DPAD_CENTER WAKE_DROPPED<br />
+key 96 DPAD_CENTER WAKE_DROPPED<br />
key 108 DPAD_DOWN WAKE_DROPPED<br />
key 103 DPAD_UP WAKE_DROPPED<br />
-key 102 HOME WAKE<br />
+key 63 HOME WAKE<br />
key 105 DPAD_LEFT WAKE_DROPPED<br />
key 106 DPAD_RIGHT WAKE_DROPPED<br />
-key 115 VOLUME_UP<br />
-key 114 VOLUME_DOWN<br />
+key 65 VOLUME_UP<br />
+key 66 VOLUME_DOWN<br />
<br />
===N8x0 touchscreen===<br />
<br />
'''Q''': Is there any way to get N8x0 touchscreen working with Android?<br />
<br />
'''A''': Yes. There is a [http://groups.google.com/group/android-internals/msg/7c6ff76e0381e95a patch] you can apply to a nokia+android patched 2.6.21 kernel and you should<br />
have a working touchscreen.<br />
<br />
===HW interfaces support===<br />
<br />
'''Q''': Which hardware interfaces or kernel drivers does current Android support?<br />
<br />
'''A''': See discussion on [http://marc.info/?l=linux-omap&m=120946406828608&w=2 OMAP ML]:<br />
<br />
> I was able to add support for the keypad, touch and network in Android,<br />
> however the interfaces like GPS, Accelerometer, vibrator, hardware 3D<br />
> acceleration, battery etc. are not integrated with Android right now. I<br />
> would appreciate if you could throw some light on these open issues. How<br />
> exactly can these interfaces be integrated with Android? <br />
<br />
We're trying to use the standard kernel/driver interfaces when possible,<br />
but for things that may have a good deal of variation in implementation,<br />
we're looking to provide a very thin "hardware interface library" layer<br />
to adapt between the bottom of the userspace stack and the drivers or<br />
whatnot for specific hardware platforms. <br />
<br />
We'll continue to adopt standardized kernel solutions as they become<br />
available -- We're now using the power supply framework in 2.6.24 for<br />
monitoring battery/charge state (post M5 SDK -- it'll be in the next <br />
release), for example.<br />
<br />
=Links=<br />
<br />
* [http://code.google.com/android/ Android] homepage<br />
* [http://benno.id.au/blog/ Bennos blog] with lot of reverse engineering info about Android<br />
* [http://androidzaurus.seesaa.net/article/74237419.html Android on Zaurus]<br />
* [http://www.kandroid.org Korea Android Community] <br />
''Note'':Connect this site using http://www.google.com/translate website.<br />
* Linux devices about [http://www.linuxdevices.com/news/NS4262102607.html Penguinistas hack Android onto real hardware]<br />
* [http://tree.celinuxforum.org/CelfPubWiki/Jamboree18AndroidDemo Google Android on Working Target]<br />
* [http://code.google.com/android/groups.html Android discussion groups]. These concentrate more on Android application programming. Not really HW and processor related.<br />
* [http://www.oesf.org/forum/index.php?showforum=158 Open Embedded Software Foundation Android forum]. Discussion, support and general information about running Android on a handheld.<br />
* [http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en Porting Android to real HW at Android internals list]<br />
* [http://nemustech.blogspot.com/2007/12/android-porting-to-real-target-hw.html Android Porting to Real Target HW]<br />
* [http://code.google.com/p/android-on-n8xx/ Android on Nokia 8xx]<br />
* Tony's [http://www.muru.com/linux/n8x0/ booting nokia N8x0 with current OMAP git kernel]<br />
* [http://forums.lugradio.org/viewtopic.php?f=4&t=4094#p41437 Robert Love talks about Google Android]. Recorded at [http://www.lugradio.org/live/USA2008/ LUG Radio Live USA 2008] at the Metreon Theatre, San Francisco.<br />
<br />
''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.<br />
<br />
=Contact=<br />
<br />
See [http://vger.kernel.org/vger-lists.html#linux-omap OMAP mailing list] for more information.<br />
<br />
This page is distilled by [mailto:dirk.behme@gmail.com Dirk Behme] and information added by [mailto:leemgs@gmail.com Lim,GeunSik].<br />
<br />
=Screenshots=<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.23 on OMAP5912 [[OSK|OSK]]: <br />
<br />
[[Image:Android m5 rc14 omap osk kernel 2 6 23.jpg]]<br />
<br />
* Android m5-rc14 kernel + m3 image, on a Nokia N810:<br />
<br />
[[Image:Cimg0608.jpg]]<br />
<br />
<br />
[[Image:Cimg0610.jpg]]<br />
<br />
<br />
[[Image:Cimg0611.jpg]]<br />
<br />
<br />
* Android m5-rc15 home screen with kernel 2.6.18 on armadillo-500 1136 ([http://www.youtube.com/watch?v=jGvGl0nOQNo YouTube Movie])<br />
<br />
[[Image:androidarmadillo200804.jpg]]<br />
<br />
* Android m5-rc14 home screen with kernel 2.6.19 on OMAP2430 [[OSK|OSK]]:<br />
-If you have unstable sdcard, You will meet for Looping of "Red Eye" Status.<br />
[[Image:omap2evm.android.PNG]]<br />
<br />
<br />
* Android m5-rc14 on Nokia's n810 Tablet<br />
[[Image:n810.kandroid200805.PNG]]</div>Anil S