Android is one of the many distributions that currently work on the Openmoko phones. You can compare a distribution with an Operating System on normal computers. It gives the phone all the software needed for operating. For more information about the different flavors, see distributions.

20081022 User:Cfriedt I was able to 'trivially' compile all of the Android source code without error for the ARMv4T architecture by removing v5TE instructions. Although it will definitely not run anything predictably, at least now that I know the build system will work with a few simple substitutions in build/core/combo/arm-linux.mk. At this point I am able to go ahead and re-implement v5TE instructions as v4T instruction sequences instead (or re-implement entire sections of assembly with hand-optimized v4T instructions).

20081021 Google released the majority source code for the phone under Apache free and open-source license, with portions covered by other existing licenses, such as the Linux kernel under GPLv2.

200810?? Koolu.com has announced that they will be selling the OpenMoko Freerunner with Android pre-installed beginning in November 2008, as well as offering free downloads of the Freerunner port of Android to existing Freerunner owners. Well-known open-source advocate Jon "maddog" Hall is CTO and Ambassador for Koolu.

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 nondeterministic.

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.

Sean McNeil said that he was able to get Androind running (including telephony) in his Freerunner source.

Ben Leslie mentioned on the android-porting list that he was able to get the 'Android' logo to appear on his Neo 1973.

How to Help

Getting Started

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'

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.

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 .

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

Discussion

Notes

The file

system/core/libpixelflinger/codeflinger/ARMAssembler.cpp

will need special attention. It's responsible for dynamic generation of DSP code.

Suggestions

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.

Android is one of the many distributions that currently work on the Openmoko phones. You can compare a distribution with an Operating System on normal computers. It gives the phone all the software needed for operating. For more information about the different flavors, see distributions.

Updates

20081104 The first Android-image has been successfully created by Sean McNeil! You can try on your own: android image and kernel - sms and calling works, wifi and bluetooth doesn't. news-source

20081022 User:Cfriedt I was able to 'trivially' compile all of the Android source code without error for the ARMv4T architecture by removing v5TE instructions. Although it will definitely not run anything predictably, at least now that I know the build system will work with a few simple substitutions in build/core/combo/arm-linux.mk. At this point I am able to go ahead and re-implement v5TE instructions as v4T instruction sequences instead (or re-implement entire sections of assembly with hand-optimized v4T instructions).

20081021 Google released the majority source code for the phone under Apache free and open-source license, with portions covered by other existing licenses, such as the Linux kernel under GPLv2.

200810?? Koolu.com has announced that they will be selling the OpenMoko Freerunner with Android pre-installed beginning in November 2008, as well as offering free downloads of the Freerunner port of Android to existing Freerunner owners. Well-known open-source advocate Jon "maddog" Hall is CTO and Ambassador for Koolu.

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 nondeterministic.

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.

Sean McNeil said that he was able to get Androind running (including telephony) in his Freerunner source.

Ben Leslie mentioned on the android-porting list that he was able to get the 'Android' logo to appear on his Neo 1973.

How to Help

Getting Started

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'

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.

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 .

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

Discussion

Notes

The file

system/core/libpixelflinger/codeflinger/ARMAssembler.cpp

will need special attention. It's responsible for dynamic generation of DSP code.

Suggestions

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.