Android ARMv4T Donut Patch

On my most recent flight from Canada to Germany, and in spite of having a great conversation with a single-serving friend, I got a bit bored and decided to try and build Donut for ARMv4T, which is quite unstable at the moment. The single-serving friend, whose name I never learned, was in a very similar boat as me - he said he was in the middle of an MSc in biomedical engineering in Lyon, and was originally from Kentucky. It's nice to actually have a decent conversation on an overseas flight for a change.

Anyway - back to the topic at hand.

The reason I'm working on the Donut branch of Android, and patching it for ARMv4T, is that I would eventually like to use it on my OpenMoko FreeRunner, which currently uses Android-Cupcake from KoolU / Michael Trimarchi. Although the generic Donut branch now builds successfully with my patch, I still need to migrate all of the hardware-specific FreeRunner changes that KoolU (any many others) made.

If you feel interested in starting from the upstream end and working downstream, as opposed to starting from KoolU git and working upstream, then check out my patch (update: see bottom of post for updated patches) and give me some feedback. I'm not inclined to submit it upstream yet, without having tested out an an actual device, so it's in very early stages right now, but it definitely builds.

You'll need to create a buildspecs.mk file, like the one below, and put it in the base of your android build directory:

TARGET_SIMULATOR := false
TARGET_BUILD_TYPE := release
TARGET_ARCH_VERSION := armv4t

Happy hacking!

update-20090824: android-donut-armv4t-20090824.patch
update-20090825: android-donut-armv4t-20090825.patch

• While working on the above patch, I discovered that a lot of upstream work has been done on Android under the hood to support ARMv4T. That includes v4T assembly optimization for opencore, dalvik, etc. Bottom line - this is good for the FreeRunner! However, there are still a few places which need improvement though, and equivalent v4 asm. I filled in some of the gaps (external/opencore/codecs_v2/video/m4v_h263/enc/src/fastquant_inline.h) last night, but the rest are mainly all of the files that think CLZ is an V4 ARM instruction (sheesh!). They were easy enough to convert to C-equivalent code.
• Recently Michael Trimarchi also announced some work was underway to integrate the libGlamo code into Android's GL. Not too shabby! Perhaps we might see an accelerated Android on the OpenMoko FreeRunner in the near future!
• I recently put some thought to the Glamo's limited 511x511 buffer and limit of 7Mb/s to memory. Sure, it sucks, that we can't do everything at 640x480 (as advertised), but aren't there other ways to get around it? Such as performing acceleration on one quadrant of the FB at a time? Or switching to/from a lower or higher resolution when playing video / games ? We essentially have to beg for, borrow, cheat & steal those accelerated pixels if acceleration is to work.

update-20091017: android-donut-armv4t-20090825-1.patch

• Thanks to androjes and bend for pointing this out.
  

update-20091214: Please see my newer post for a continuation of the effort.

HTC Hero vs Samsung Galaxy

I've been wowing over these two devices approximately for the last couple of months, and decided that it's finally time to make a decision.

Both the Samsung Galaxy and the HTC Hero use the same SoC (who isn't?) - the Qualcomm MSM7200A, a 528 MHz ARM1136EJ-S core, using the ARMv6 ISA. The MSM7200 includes a 3D acceleration unit and a Qualcomm DSP, making it very suitable for any multimedia application. I do believe that the 3D acceleration unit still lacks full support under Linux/Android (much like the OMAP3530/PowerVR). Both handsets have a 5MP camera, although no secondary camera for video calling. They both have 802.11b/g, bluetooth, etc. The display on both devices is 320x480 pixels. Major differences are that the Galaxy has several more buttons (e.g. volume control), much more internal storage space, and a very power efficient AMOLED display, while the Hero sports the new Sense(R) UI, integrated Adobe Flash, more RAM, and multi-touch support.

I thought I would summarize. For those who would like to see a detailed comparison of the two devices, check out this link from pdadb.net .

	HTC Hero	Samsung Galaxy
RAM (MB)	288	128
Flash (MB)	512	7630
Connector	ext-USB (mini-USB compatible)	micro-USB
Battery (mAh)	1350	1500
Display Depth	16-bit (65-thousand colours)	24-bit (16-million colours)
Display Type	Transflective TFT (standard)	AMOLED (very low power)
Multi-Touch?	YES!	NO!
Price (€)	485,97 (Amazon.de)	476,98 (Amazon.de)

So far, I have not had a chance to examine either of these devices in any detail, but from what I have read, the Hero does support multi-touch. Until now, most sources have stated that the Galaxy does not support multi-touch. However, that might only be due to the fact that Android did not support multi-touch in software until the Hero came out. Perhaps the Galaxy has hardware support for multi-touch. Who knows with any certainty? I've read that the Galaxy actually has a capacitive touchscreen, so multi-touch does not seem that far off. The Galaxy also lacks Google-branding, which (aside from lacking some cover-art) means that software updates are not transferred over the air. Rather, updates must be performed manually with a USB cable, which some users might actually prefer.

Let's start with the Hero. I like that it has a large amount of RAM a great UI that supports multi-touch. The RAM will come in handy for streaming media (i.e. video) and fast context switching (Android's OOM process killer will not be called as frequently). As for multi-touch, I think you would probably agree, that there really is no alternative for pinch-zooming in the browser, or easy photo rotations. Now, the Galaxy - the fact that it's missing some RAM has been somewhat accounted for with the built-in 8GB of storage. As far as the screen goes, AMOLED spells very low-power (I love it) and still supports a true-colour (16million level) display. That will make it excellent for viewing any type of video or looking at photos. However, if the Samsung hardware truly does not support multi-touch, then I would be quite disappointed.

I have to admit, that I'm still sitting on the fence about this until I know with any certainty that the Samsung does not support multi-touch. Originally, I was thinking that the Samsung would be the best choice, without a doubt, but now I'm really considering how the extra RAM in the Hero might be beneficial. In terms of permanent storage, the Hero has more than enough, and is expandable with a micro-SD card anyway. On the other hand, the Galaxy could easily host a few operating systems on-board, or perhaps my entire collection of (decent) mp3s. This decision would definitely be easier if I knew for a fact that the Galaxy hardware did or did not support multi-touch.

Suggestions for Future OpenMoko Device

I love my FreeRunner as much as the next guy. The truth is, though, that there are some serious improvements that could be made to the OpenMoko hardware - some purely for usability, and some to fix a couple of plaguing, nasty bugs. The suggestions below would really turn something like the FreeRunner into a truly portable computing device - not just another iPhone clone.

I've collected a few of my own suggestions below

• use capacitive instead of resistive touch-screen (for multi-touch gestures)
  
• switch to a newer generation SoC, such as the Qualcomm MSM7200A
• newer ARM ISA (e.g. enhanced, jazelle, dsp, etc)
• integrated video codec (ditch the Glamo)
  
• integrated 3D graphics (again, ditch the Glamo)
• integrated GPS receiver - just needs internal antenna
  
• get rid of external GPS antenna connector (use internal instead)
• add dedicated power connector (e.g. Nokia 6620)
• built-in circuitry for 'software-free' battery charging (see discharged battery bug)
  
• support charging from 1st USB if dedicated power supply is absent (1st port should be USB OTG)
  
• add 2nd USB for use as dedicated host port
• add a mini-dvi video output
• add an ambient light sensor (auto backlight control in software)
• a 5MP photo / video camera and 1.3MP camera for video chat.
  

A couple of incidentals 1) switch to using 100% recycled materials for the casing, if it already isn't, 2) use AMOLED display technology to prolong battery life.

Comments?

Hello, Native Android World!

I just thought I would post my experiences with creating an Android application that uses JNI to call native code.

First of all, create a regular Android project in Eclipse, following the Hello Android tutorial, except

• change the project name to HelloNativeAndroid
• change the class name to be HelloNativeAndroid
  
• change the package name to be com.christopherfriedt.android, or something similar
  

Then change your HelloNativeAndroid.java to be something like this:

HelloNativeAndroid.java:
package com.christopherfriedt.android;

import java.io.*;
import java.util.zip.*;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.TextView;

public class HelloNativeAndroid extends Activity {

private native String greet();

/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
TextView tv = new TextView(this);
tv.setText( greet() );
setContentView(tv);
}

static {

String pkg = "com.christopherfriedt.android";
String cls = "HelloNativeAndroid";
String lib = "libHelloNativeAndroid.so";
String apkLocation = "/data/app/" + pkg + ".apk";
String libLocation = "/sdcard/" + lib;

File f = new File(libLocation);

if ( ! f.canRead() ) {

Log.d( cls, "'" + libLocation + "' not found, proceeding to installation" );

try {

ZipFile zip = new ZipFile(apkLocation);
Log.d( cls, "found ZipFile " + apkLocation );

ZipEntry zipen = zip.getEntry("assets/" + lib );

if ( zipen == null ) {
Log.d( cls, "unable to find ZipEntry '" + "assets/" + lib + "'" );
} else {
Log.d( cls, "found ZipEntry '" + "assets/" + lib + "'" );
}

InputStream is = zip.getInputStream(zipen);
Log.d( cls, "opened InputStream" );
OutputStream os = new FileOutputStream(libLocation);
Log.d( cls, "opened OutputStream " + libLocation );

byte[] buf = new byte[4096];
int n;
while ( (n = is.read(buf)) > 0 ) {
Log.d( cls, "read " + n + " bytes from InputStream" );
os.write(buf,0,n);
Log.d( cls, "wrote " + n + " bytes to OutputStream" );
}
os.close();
Log.d( cls, "closed OutputStream" );
is.close();
Log.d( cls, "closed InputStream" );
} catch( Exception e ) {
Log.e( cls, "failed to install native library: " + e );
}
}

try {
Log.d( cls, "attempting to load " + lib );
System.load( libLocation );
//System.loadLibrary( cls );
Log.d( cls, "loaded " + lib );
} catch(Exception e) {
Log.e( cls, "failed to load native library: " + e );
}
}
}

Open up a shell in the 'src' directory of your project and run

javac com.christopherfriedt.android.HelloNativeAndroid.java
javah com.christopherfriedt.android.HelloNativeAndroid

Make a subdirectory in your Android project, called for example 'C', and then copy the resulting com_christopherfriedt_android_HelloNativeAndroid.h (created with javah), to the 'C' folder.

Next, create the following files:

HelloAndroid.c:

#include "com_christopherfriedt_android_HelloNativeAndroid.h"

#define GREETING "Hello, Native Android!"

JNIEXPORT jstring JNICALL Java_com_christopherfriedt_android_HelloNativeAndroid_greet
(JNIEnv *e, jobject o) {
return (*e)->NewStringUTF(e,GREETING);
}

Makefile:
CROSS = arm-softfloat-linux-gnueabi- CC = $(CROSS)gcc STRIP = $(CROSS)strip JDK_HOME = /opt/sun-jdk-1.6.0.14 PKG = com_christopherfriedt_android CLASS = HelloNativeAndroid DEBUG = CFLAGS = -O2 -pipe -Wall -march=armv4t -mtune=arm920t \ -I$(JDK_HOME)/include -I$(JDK_HOME)/include/linux LDFLAGS = -fPIC -shared -nostdlib -Wl,-rpath,/system/lib ifneq ($(DEBUG),) CFLAGS += -g endif SOBJ = lib$(CLASS).so all: $(SOBJ) $(SOBJ): $(PKG)_$(CLASS).h $(CLASS).c $(CC) $(CFLAGS) $(LDFLAGS) -o $(SOBJ) $(CLASS).c ifeq ($(DEBUG),) $(STRIP) --strip-unneeded $(SOBJ) endif clean: rm -f $(SOBJ) install: all cp $(SOBJ) ../assets

Then run 'make', and 'make install'. Build your Android project, and it will now have libHelloNativeAndroid.so bundled in the .apk file, inside the 'assets' directory (you can easily view the contents of it with unzip -l, because it's just a zip file).

Then install the .apk file using the android debug bridge (adb), with 'adb install HelloNativeAndroid.apk'.

Open the application up on your mobile, or in the emulator, and you should see something resembling the screenshot below.

Some notes:

• My target was a Neo FreeRunner from OpenMoko, hence the -march=armv4t -mtune=arm920t . Feel free to change that to something like -march=armv5te as appropriate
• In the Makefile, adjust the path to your JDK as appropriate
• The rpath argument is necessary so that the native Android linker will know to link the shared object to /system/lib/libc.so, which is from the Bionic C library
• The -nostdlib option is required so that the shared library does not require libc.so.6, which would actually refer to glibc
• The shared library will be extracted to /sdcard/libHelloNativeAndroid.so, so you'll need that folder to exist and be writable on your device
  

Acknowlegements:

• http://android.wooyd.org/
• http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-android.html
  

Mac OS X on a Dual-Core ARM-Powered Netbook?

With all of the hype over ARM-powered netbooks recently, they seem to be here to stay. Basically all of the major companies are jumping on this opportunity; we have the ARM licensees such as TI, Marvell, Qualcomm, and FreeScale, as well as major operating system providers such as Google (i.e. Android), and Microsoft. Even third-party software vendors like Adobe (i.e. Flash) are jumping aboard.

 The ideal silicon solution is a system-on-a-chip (SoC) maybe accompanied by an external graphics  co-processor (if it's not already integrated). For ARM architectures, that basically means 1 or 2 chips to power the entire computer versus Intel's 3, 4, 5, etc. Peripheral devices aside, ARM architectures use an order of magnitude less power than equivalent Intel architectures. What that means, is that the computers we use for our daily tasks, including document / internet activities, multimedia, programming, numerical analysis, etc, will have no fan, no heat-sink, and enough battery power for 10 times the active computing or standby time as Intel-based devices.

Now, I came across an article that I think actually has some merit. Apple could potentially become the next big-time ARM licensee and chip fabricator! Considering their recent acquisition of P.A. Semi and their huge successes with the iPod and iPhone (both ARM devices), they would technically stand to save millions by designing and fabricating their ARM chips in-house rather than purchasing them from outside vendors. Now in terms of porting the OS X to an ARM device - piece of cake. The core of the Apple operating system was designed from the start with portability and inheritance in mind. Their software is already pre-built and packaged in a universal binary format. With all likelihood, all they would need to do is highlight a check-box in XCode to build OS X for the ARM.

Honestly, I've never owned any apple products other than a second-hand 4th generation iPod that I lost on my last flight, mainly due to the prices, but if Apple decides to make a competitive move in the netbook market, then such a device might be the first Apple computer that I would buy, if the price is right. 

To elaborate - I'm a really big fan of the TouchBook from Always Innovating, Inc, especially with the detachable keyboard, and touchscreen / tablet form factor. If Apple could do the same, with a unibody aluminum case, have nice illuminated keys, and throw in that always-on 3G HSDPA modem that Qualcomm has in their Snapdragon, then I would be 100% in. In that case, I would very likely be willing to cough up another hundred for what I see as the ideal netbook. Of course, this could draw the power ratio to something like 1/7 instead of 1/10 when compared to an Intel netbook, but that still makes a very, very big difference.

On a final note, in 2010 consumers will see the dawn of when ARM chips actually incorporate two applications processors (aside from radio, DSP, Graphics, etc), much like the 'Core Duo' from Intel. Apple could incorporate two ARM cores, in order to retain that same UI responsiveness that Apple has been so well known for in the past.

Below is a block diagram [via Engadget] of the new ARM Cortex A9 chips that will begin to appear in 2010. The Cortex line of ARM processors was a step in a slightly different direction, being the first ARM devices to support out-of-order execution (OoOE), and although ARM chips have supported single-instruction-multiple-data (SIMD) since the v6 instruction set was introduced, OoOE will boost ARM performance to a level closer to Intel processors, which have traditionally used both OoOE and SIMD (as MMX). OoOE represents instruction-level parallelism while SIMD represents data-level parellelism. It should be noted that both of the aforementioned optimizations are independent of each other as well as independent of instruction pipelining. However, having pipelining, OoOE, and SIMD on the same chip leads to a exponentially increased complexity, resulting in a very large and necessary amount of silicon to reduce data collisions. This is the primary reason that Intel chips have been had such a long history of being power-hungry. Hopefully, this won't have too large of an effect on the power efficiency of future ARM chips.

Samsung i7500 Galaxy from O2 Germany

I thought I would post a link I found to a PDF on O2's website that states what the price of the Samsung i7500 with Android. The flyer says that it will cost 367€ without a contract.

Check it out here. Some updates are on the O2Online.de blog, saying that it should be available either this week or next.

I hope I won't be out of luck if I ask for it with an english UI :)

Update: Nooooooo.... I was just checking out a youtube video preview of the i7500 and discovered a horrible design decision on the part of Samsung. In spite of having designed the  device with a 3.5mm audio jack (thank you Samsung!) they used one of those super annoying, hard-to-find, flat USB jacks.

The flat USB jacks are horrible and tend to break quite easily. It's also not saving any space as there is a huge 3.5mm jack directly beside it - the whole point of the flat USB connectors is that they're supposed to be used when thickness is an issue.

Read this, and just know that I'm shaking my head 'no' right now in disappointment.

Incidentally, has anyone found out of there is a regular Mini USB connector with the same pinouts as the flat type? I wouldn't mind just soldering out the old one and putting in a standard Mini USB jack.

NVidia Prefers WinCE to Android

There have been hordes of ARM-powered netbooks that have been popping out of the woodworks of Computex this year. One of which was touting the new NVidia ARM Tegra chip.

Here's a link to an article on Slashdot which reports that NVidia is not ready to back Android as a capable platform for Netbooks.

I unfortunately say that I must agree - although its not completely Google, or the Open Handset Alliance, or Linux that is truly at fault - or NVidia for that matter.

The problem is that NVidia would need to expose yet another kernel and user-space ABI (for their latest, integrated Tegra GPU no-less), and they are not prepared to do so. Aside from that, Android performs much of the hardware acceleration (a.k.a. DSP algorithms) for graphic and audio in a completely re-done set of non-portable libraries (the last time I saw the code), rather than using a single, portable abstraction layer such as OpenGL.

My recommendation? End-users should stick with WinCE (as well as the NVidia-modified UI) that will ship with the NVidia-based netbooks - IF THEY CHOOSE TO BUY A NETBOOK THAT USES AN NVIDIA TEGRA CHIP. Certainly, there are many other, more mature ARM chip vendors that will be offering netbook platforms (e.g. Qualcomm, TI, etc).

However, for almost all other ARM cores with unencumbered ABI's and API's for hardware acceleration - by all means use Android! The Android community, which is composed of literally thousands of developers, will have an exponentially greater ramp-up on new technology and software integration speed than NVidia & MS will, as single entities. Plus, as we have seen in the past, the release cycle for Android will likely be more frequent and since it's Open Source. Furthermore, there is less likelihood that Android will fall behind and become unmaintained (which was the whole purpose of the OHA in the first place), while the NVidia & WinCE combination will likely become unsupported and outdated at some point.

Canada Rejects Business Method Patents

Here's a link to an interesting article by Michael Geist [via Slashdot].

I completely agree with the ruling, and am very glad that we still don't patent software in Canada.

More From Computex. The Green Revolution of Computing Begins

One word: Wow!

For basically as long as I can remember, I've been interested in low-power computing. The combination of environmental awareness, plus the ability to understand how things work (i.e. engineering), essentially equates to my urge to want to make the universe more energy efficient. This is the reason why I've been such a big fan of ARM cores for so many years, and also why I've been following the progress of ARM and Linux together. Linux is basically the only publicly-available, fully-featured OS for alternative architectures such as ARM(ok, BSD too), which is why I consider Linux as pivotal for the recent achievements of ARM and their licensees. Having seen the Qualcomm-powered Netbook only a few days ago, I am no longer hesitant to say, that

Linux has enabled ARM to potentially overcome Intel in the PC market

Slashdot posted this yesterday, and I see no shame in admitting I read it there first. Computex has yet again unveiled what I consider to be the future of mobile computing and traditional workstations. Take a few minutes and please watch these videos. What you'll see is that several well-known semiconductor companies (Freescale, Nvidia, Qualcomm, ... Samsung?) plus many new and established manufacturers, have decided that it is time to bring ARM devices to the desktop.

As many engineers are already aware, ARM chips generally use < 1W of power, and entire systems often consume < 5W. These ARM chips run in the GHz range and offer more than enough computational power for day-to-day tasks, multimedia applications, and now even 3D gaming. When we compare the power consumption of about 5 W for a power-hungry ARM system, with the power consumption of a 300W office computer, the greener choice is clear.

A typical Intel-powered laptop or workstation (see x86 architecture) can often consume power in the range of 250-400W, when hard disks, optical drives, and expansion cards are taken into consideration. The most power-efficient x86-systems can run at about 30W. Therefore, the power savings using an ARM-based system can be between 100 times (in the most optimistic case) and 10 times (in the most conservative case) - but always in the favour of ARM systems.

Although the economy is on everyone's minds these days, energy is probably going to be one of the hottest markets in the next decade (and arguably now). I predict that we are likely to see the Green Revolution of Computing within the next few years. Power-efficient chips, such as those based on ARM, MIPS, and PowerPC architectures, will likely start replacing Intel chips on a massive scale. It's likely that this will first happen in the home, and then it will make its way into businesses. Businesses typically rely on 'legacy' applications and the cost is just to high to redesign most programs right away, so we will likely see the business adoption of Green Computing later on, hopefully driven by some kind of government incentive program.

ARM chips are typically designed for a single-user-load, and aren't necessarily the best thing for professional video editing, high-demand servers, extreme gaming, or scientific computing - at least not yet anyway. Of course, adding optical or magnetic-disk drives to any ARM system would increase the average power consumption of the device, but not as much as it would in the case of a PC, as most of required components for ARM are integrated onto a single chip, and not contained in a different chipset altogether. But isn't physical media becoming almost irrelevant these days, with the increased tendency toward cloud computing?

Qualcomm SnapDragon Powered EEE PC Surfaces at Computex

Computex 2009 was host today to the newest member of the EEE PC family, powered by the Qualcomm SnapDragon system-on-a-chip and Google's Android OS for mobile devices. The Qualcomm Snapdragon SoC incoroporates an ARM11 core operating ag 1 GHz (future models will be running at 1.3 GHz), an integrated 600 MHz DSP (a coprocessor for math, audio, and 3D acceleration), as well as embedded hardware video codecs, enabling this processor to support HD video of 720p (later models with 1080p). This netbook also offers always-up connectivity with an integrated internationally-compatible 3G modem, as well as the standard 802.11g wireless connectivity. The full spec list is available here. However, the kicker in favour of ARM-based netbooks is their power efficiency. The Qualcomm-powered EEE PC is expected to boast a battery life of 8 to 10 hours on a single charge!

ARM based processors are what power 99% of today's cellular phones and mobile electronics, such as the iPhone. As one might expect, there is no room for a heat sink or fan in a mobile phone. Therefore, ARM engineers and their licensees have taken power efficiency to a whole new level with this technology. Aside from the impressive multimedia and gaming capabilities, and like most ARM-based SoCs, all of the transistor logic for the CPU, co-processor, and peripheral devices is integrated onto a single wafer of silicon, hence the term 'system-on-a-chip'. Its as if the video, sound, network, PCIe controller, memory controllers, etc, etc, etc, were crammed onto a single package. For comparison, a similar netbook platform, based on the Intel architecture, would occupy at least three, but more commonly four or more chips, resulting in a drastically larger amount of power dissipated as heat.

The 1GHz barrier for ARM chips was first traversed commercially by Marvell, with their Shiva-Plug. Texas Instruments had reached milestones even earlier with their OMAP line of chips which power devices such as the BeagleBoard development board and the OpenPandora mobile gaming platform. The Qualcomm-powered EEE PC is not the first ARM-powered netbook though; some people may still have their eyes on the Always Innovating TouchBook, which is also powered by the familiar OMAP processor. However, if ASUS blesses this marriage of ARM and Android in their cathedrals of manufacturing, then the new Qualcomm-powered ASUS EEE PC might be the first ARM-powered netbook that hits the mass market.