Android porting
From Openmoko
![]() |
Languages: |
English • العربية • Български • Česky • Dansk • Deutsch • Esperanto • Eesti • Español • فارسی • Suomi • Français • עברית • Magyar • Italiano • 한국어 • Nederlands • Norsk (bokmål) • Polski • Português • Română • Русский • Svenska • Slovenčina • Українська • 中文(中国大陆) • 中文(台灣) • Euskara • Català |
|
Introduction
NOTE: The Android for FreeRunner development now takes place here. It has it's own wiki as well. |
This page is dedicated to porting the Android OS to the Neo 1973 and Neo FreeRunner handsets. Since the Android OS was publically released on 20081021, work is currently underway to port Android to the Neo 1973 and FreeRunner handsets.
Goals
- Systematically introduce patches for ARMv4T in the Android codebase
- Provide Neo1973 and Neo FreeRunner hardware-dependent patches in the Android codebase, leveraging the work already done by the Openmoko developers, without forcing Android-specific changes upstream
- Provide a useable Android filesystem and kernel on the Distributions page that conform to current Openmoko installation routines
Early Attempts
Before the source code was released, kernel trap handlers were implemented to 'emulate' the ARMv5TE ISA. Although the results worked in many cases, trapping is costly and performance suffered as a result. Moreover, without explicitly knowing which conditions were set by various instructions, such as Thumb Mode execution, the result became non deterministic.
Current State
With the release of the Android source code, the Open Source community is no longer limited to dealing with a binary-only product. The Open Handset Alliance (OHA) has let their source code become their product for everyone enrich and benefit from. Currently, porting efforts are underway in many circles.
Patches should be submitted via the official Android channels.
To track the status of which parts of the Android source tree contain ARMv5 specific code, I've created a table of where it is contained, and the status of patches. It can be found at: http://spreadsheets.google.com/pub?key=pzDEXnU19gkeTjpD28t-7fw User:Bricode
Google has released their open source version of the Android phone software distribution. In order to use it on the Freerunner, a number of patches need to be applied and a compiler with armv4 java exception support needs to be used to compile the software.
Status
Most of the hardware on Freerunner seems to work on latest Android images, but not always perfectly.
If you want to see details of what is already usable, please have a look at: Android_usage
Compiler suite
Android is a little picky about the version of gcc compiler. It also requires some java exception support that isn't available for armv4 without a minor modification. The following tools are what I use to build Android:
Binutils 2.18
At one time I had some armv5t code that was compiled into Android which would cause the linker to generate these blx instructions which fail on armv4. I'm not sure if this is still necessary, but I still have the following change applied to binutils:
diff -urN binutils-2.18-orig/bfd/elf32-arm.c binutils-2.18/bfd/elf32-arm.c --- binutils-2.18-orig/bfd/elf32-arm.c 2007-08-07 02:59:23.000000000 +0700 +++ binutils-2.18/bfd/elf32-arm.c 2008-03-15 11:30:17.000000000 +0700 @@ -3093,8 +3093,8 @@ static void check_use_blx(struct elf32_arm_link_hash_table *globals) { if (bfd_elf_get_obj_attr_int (globals->obfd, OBJ_ATTR_PROC, - Tag_CPU_arch) > 2) - globals->use_blx = 1; + Tag_CPU_arch) >= TAG_CPU_ARCH_V5T) + globals->use_blx = 0; } bfd_boolean
configure --prefix={devel path}/android/cross --target=arm-eabi
gcc 4.2.4 with gcc41-java-arm4.patch
configure --prefix={devel path}/android/cross --target=arm-eabi --with-arch=armv4t --enable-shared --enable-threads --disable-nls --disable-libmudflap --enable-target-optspace --with-abi=aapcs --enable-multilib --disable-libssp --disable-libstdcxx --enable-languages=c,c++
java-6-sun
This is the standard Linux package available for most (all?) distributions.
Patches
Coming soon. I've posted a number of them on the devel mailing list so far. Eventually, I expect to provide everything necessary for people to build Android for themselves.
Building the Koolu Android Source
- Configure your machine with the prerequisites documented in the Setting up your machine section of Google's build instructions.
- Install repo and download the source, as documented at http://trac.koolu.org/.
- After the build finishes you can put together a root file system by editing and running Sean McNeil's scripts, which are attached to this message. The first script (cp_android_OS) is used to copy the newly built files into a staging area. The second one (mkjffs2) makes a jffs2 image from the staging area. Be sure to edit the paths in the two files to match your environment. Alternatively, you can use the script below
- The result of the previos step is a file, androidfs.jffs2, which may be flashed to your Freerunner.
sudo apt-get install mtd-tools
Building a jffs2 image
You can use this script:
#!/bin/sh currentdir=`pwd` ANDROID_OUT=out ANDROID_DEVICE=freerunner EXPORT_ROOT=$currentdir/build_jffs2_tmp Usage() { echo "Usage: $0 release|debug jffs2filename" } BuildImage() { if [ -d $1 ] then echo "[INFO] Copying from... $1" sudo rm -rf $EXPORT_ROOT mkdir $EXPORT_ROOT mkdir $EXPORT_ROOT/root # Copy the image... cd $1 tar cf - root | (cd $EXPORT_ROOT; sudo tar xf -) tar cf - system | (cd $EXPORT_ROOT/root; sudo tar xf -) # Change owner and permissions... cd $EXPORT_ROOT sudo chown -R root:root root sudo chmod -R 777 root cd $currentdir # Make the JFFS2 file mkfs.jffs2 --pad=0x700000 -o $2 -e 0x20000 -n -d$EXPORT_ROOT/root/ echo "[INFO] Image written to $2" sudo rm -rf $EXPORT_ROOT else echo "$1 does not exist!" fi } if [ $# != 2 ] then Usage else case $1 in release) BuildImage $ANDROID_OUT/target/product/$ANDROID_DEVICE $2 ;; debug) BuildImage $ANDROID_OUT/debug/target/product/$ANDROID_DEVICE $2 ;; *) Usage esac fi
Android Debug Bridge
To assist in debugging and to gain shell access to the phone with Android, you can use the instructions found here: Android_debug_bridge
Windows Connectivity
It is possible to get Windows to at least recognize the Android "Ethernet Gadget" and charge the FreeRunner using the Android USB Windows driver (http://dl.google.com/android/android_usb_windows.zip) by modifying the android_usb.inf file in that package before attempting to install the driver. The following modifications are required:
Add the following to the [Google.NTx86] section of the android_usb.inf file:
; Neo FreeRunner %USB\VID_1457&PID_5117.DeviceDescRelease%=androidusb.Dev, USB\VID_1457&PID_5117 %USB\VID_1457&PID_5117&MI_01.DeviceDescRelease%=androidusb.Dev, USB\VID_1457&PID_5117&MI_01
and add the following to the to the [Strings] section of the android_usb.inf file:
USB\VID_1457&PID_5117.DeviceDescRelease="Neo FreeRunner" USB\VID_1457&PID_5117&MI_01.DeviceDescRelease="Neo FreeRunner Composite ADB Interface"
The Windows version of adb does not appear to recognize the connected device yet but at least the FreeRunner charges and the device driver indicates that "This device is working properly."
How to Help
You can start by following the instructions to download and build the Android source from scratch. Please see http://source.android.com/download and follow the instructions for your architecture.
Publicize Your Efforts
It's generally a good idea to make your efforts known via wiki systems, public mailing lists, forums, and publically open version control systems.
Always take credit for your work but please don't do it in the form of comments. Some code is already hard enough to read without comments polluting the text. The best thing to do is to create a patch and put a header with your information at the top. Collaboration systems such as git might already do this for you (??).
If you create something new and have the ability to designate the license for it, please consider license compatibility issues.
Porting Strategy
- Analysis and leverage of the existing build system
- buid/core/combo/arm-linux.mk
- -D__ARCH_ARM_4__ -D__ARCH_ARM_4T__
- -march=armv4t -mcpu=arm920t
- fix various static references to 'armv5'
- buid/core/combo/arm-linux.mk
- Isolating ARMv5TE ISA dependent code
- e.g. grep -n -R -i "${armv5te_isa_pattern}" ~/android
- Abstracting
- ( C/C++ )
- Use inlined functions / #ifdef statments to implement functions in a portable manner
- For inlined assembler calls, it's acceptable for now to use generic C code instead, so long as later on we optimize it by hand.
- ( ASM )
- Proprocessor statements based on ISA / architecture, e.g. #ifdef __ARCH_ARM_5__ ... #endif #ifdef __ARCH_ARM_4__ ... #endif
- It's highly suggested that preprocessor statements should not be nested (i.e. make them mutually exclusive)
- Some people have suggested that we should not do #ifdef's based on ARCH or ISA, but rather based on an AndroidConfig.h which would define macros like PLD(...) #ifdef HAVE_ARM_PLD pld #else ... #endif .
- ( C/C++ )
For each ARMv5TE instruction, one could potentially
- Implement the instruction using general registers instead of DSP calls (i.e. eabi / softfloat)
- If that is a) nondeterministic, or b) slow, then sections of code need to be analyzed and hand-optimized for the ARMv4T isa
List of Unsupported Instructions
This is a list of opcodes, extracted from the Android source, that are unsupported for ARMv4T compliant processors (specifically the arm920t). The opcodes represent instructions available for ARMv5, ARMv5T, and ARMv5TE architectures, which are not present in the ARMv4T ISA. The list was obtained by exhaustively editing the recompiling the Android source code until it compiled without error.
Please keep in mind, that in some cases, translating these instructions into a sequence of ARMv4T instructions will be impossible and / or result in nondeterministic execution because of
- the requirement of additional context
- the tendencies of certain opcodes to change condition registers that may or may not be present in the arm920t core
Opcodes
|
Scanning for Files That Use the ARMv5TE ISA
Using the above list of opcodes, one can scan the Android source code for ARMv4T-incompatible instruction sequences.
Code:
#!/bin/sh # $1 is the android directory if [ $# -ne 1 ]; then exit -1 fi cd "${1}" opcodes="blx clz ldrd pld smlabb smlabt smlatt smlal smlawb smlawt smulbb smulbt smultt smulwb smulwt qadd qdadd qdsub qsub strd" for op in ${opcodes}; do echo "* ${op} =====================================" if [ ! -e .files.${op} ]; then files="$(grep -R -i "${op} " * 2>/dev/null)" files="$(echo $files | grep -v "^Binary file" | sed -e 's/:.*//')" files="$(echo $files| grep -v "CREDIT\|README\|^\(kernel/\|.git/\)\|\(\.txt\)$" | sort -u)" echo "${files}" > .files.${op} else files="$(cat .files.${op})" fi for fil in ${files}; do lines="$(grep -n -i "${op} " ${fil} | sed -e 's/:.*//g' )" lines="$(echo $lines | sed -e 's/ /,/g')" echo "** ${fil}: lines {${lines}}" done done |
Source Files in Android that Use the ARMv5TE ISA
The list of files below may or may not be complete. There might also be some assembly code that is generated with a python script (verification?).
|
Discussion
The file system/core/libpixelflinger/codeflinger/ARMAssembler.cpp will need special attention. It's responsible for dynamic generation of DSP code.
User:Cfriedt 20081024 I'm not sure how feasible this is, given that the SMedia 3362 is heavily NDA'd. However, since the arm920t lacks a floating-point unit / DSP core, is it possible to use the SMedia chip for general-purpose math? This would help in the Android platform, at least, for things like audio and video codecs. Aside from an OpenGL ES driver, OpenMoko documentation for the SMedia would be highly appreciated.
Important Links
Documentation
- Android Documentation
- ARM Documentation, (keywords: armv4t, armv5t, armv5te, arm920t, arm926ej-s)
- ARM Assembly Language Programming
- An Introduction to the GNU Assembler
- ARM Procedure Call Standard, ARM Calling Conventions
Instruction Set References
- ARM Architecture Reference Manual, The definitive ISA documentation
- ARM Instruction Set Quick Reference Card
- ARM and Thumb -2 Instruction Set Quick Reference Card
- ARMv4T (See section 1.4.13)
- ARMv5T (See section 4.16)
- ARM DSP Enhanced Instruction Set
- Procedure Call Standard for the ARM Architecture
Hardware Reference
Communities
- Android Public Mailing Lists
- Specifically, android-porting
- OpenMoko Mailing Lists
- Specifically, openmoko-kernel
- Android on FreeRunner at KoolU.com
- Openmoko Local Groups
- Community Resources