20090930

Motorola Q9h

So I wrote Motorola recently to see if they would like to cooperate in my effort to port Linux and Android to the Q9h, and although a couple of engineers on the motodev site seemed enthusiastic, I still haven't heard any kind of definitive reply.

The next logical step was to disassemble a broken Motorola Q9h I found on eBay :) I'm not entirely finished this tear-down yet, because I'm still trying to pry-off a few remaining EMI shields, but its coming along smoothly.

 I'd have to say, that I'm amazed with all of the components that went into this device from various vendors. Of course, there's the TI OMAP2420, a TI power management chip, some Samsung memory, Elpida memory, a Broadcom (I'm guessing bluetooth) transceiver, several FreeScale parts that I haven't yet identified, the SiRF 5000 AGPS receiver, a few random sensors (ambient light, ...), etc.

I'll be specifically looking for a 'companion chip' sort of like the TWL4030, to see what I can get out of the USB pins. I believe that D+ / D- are not fully muxed with UART2, but they are with GPIO 107 / 108, which means I might have to write a small soft-uart driver for the Linux kernel. 

Most of the Linux-OMAP code for the 2420 device is already present upstream in the kernel (mainly written by Nokia engineers), so in terms of the Linux porting effort, it's really just a matter of configuration. There may be a couple of non-standard peripheral devices, but I'm not expecting any major difficulties.

I hope you eagerly await some photos of the internals :) I'll have to take a pause in order to get back to the library and resume studying for my wireless communication exam, but I should be done the teardown in another day or two.

Wish me luck!

Update-20091002: Teardown
Update-20091002: OpenEZX Page

20090915

Gentoo BootSplash for ARM FrameBuffers

With Gentoo now running on several mobile devices, including the OpenMoko devices, HTC Wizard, and one that I'm still unable to mention due to NDA, I thought that it would be advantageous to be able to package splashutils for ARM devices in order to make the Gentoo boot process as visually appealing as others (notably Angstrom).

One major blocker in that process was being able to (cross-)compile klibc for ARM devices. Although that has been working well for a couple of years already, klibc was unavailable for Gentoo / ARM without an arm keyword. So I had to edit the klibc ebuild considerably and make it cross-compile friendly. In the process I added a couple of useful features and bug-fixes that were already in OpenEmbedded, like wc, losetup, etc. You can see the efforts of my klibc ebuild at Gentoo's Bugzilla under bug #284957. It's currently working without any issues. Incidentally, the ebuild configures for the ARM EABI if it's applicable.

Once that was ready to go, I contacted Spock and he assured me that his splashutils would work for generic framebuffers, and not just vesa or vga style devices. Then, it was just a matter of emerge-ing splashutils, and creating a theme.

I chose to modify the natural_gentoo theme because it was relatively clean-looking and recent. There are definitely hundreds of themes to choose from though. Here are the modified version for resolutions 240x320 (silent), 240x320 (verbose), 320x240 (silent), and 320x240 (verbose). My 240x320.cfg file is available here and a feature request has been added at Gentoo's Bugzilla under bug #285088.


 














Note: Ned Ludd and Angelo from #gentoo-embedded had apparently done this a year ago, but I guess they hadn't submitted it to the main portage tree. I was unaware of their efforts unfortunately, and maybe could have spared myself some time if I would have known about it beforehand.

20090821

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
update-20091214: Please see my newer post for a continuation of the effort.

20090711

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 HeroSamsung Galaxy
RAM (MB)288128
Flash (MB)5127630
Connectorext-USB
(mini-USB compatible)
micro-USB
Battery (mAh)13501500
Display Depth16-bit
(65-thousand colours)
24-bit
(16-million colours)
Display TypeTransflective 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.

20090708

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?

20090627

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

20090626

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.

20090624

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.