Android is open source; it can be liberally extended to incorporate new cutting edge technologies as they emerge. The platform will continue to evolve as the developer community works together to build innovative mobile applications. (Open Handset Alliance)

Unfortunately, the current crop of Android tablets aren’t nurturing open source at all.

Android Tablets

With the exception of Barnes & Noble’s Nook e-reader, a device that isn’t even really a tablet, I couldn’t find a single EDIT: I found one tablet manufacturer who was complying with the minimum of their legal open source requirements under GNU GPL. Let alone supporting community development.

EDIT 31/7: In the comments, xauieous points out that while Archos have released GPL source for the ARM11/OMAP2 based “Archos 5 Internet Tablet” (aka Archos Generation 7), they are not complying with GPL for the ARM9 based “Archos 7 Home Tablet”. The contents of the “Generation 7″ kernel tarball seem to bear this out. Xauieous claims Rockchip are holding out on the source for the Archos 9 Home Tablet, same as Apad.

Also, personal note to Archos: Please get a less confusing naming scheme!

EDIT 28/7: Courtesy Harald Welte @ VIA, there’s been a source drop of kernel source for WM8505-based tablets (Eken M001,M003,Gome FlyTouch, etc.) Some parts (video, SD/MMC drivers) are still binary only, Harald says he’s talking to VIA about it.

EDIT 26/7: Zebul posted a comment and drew my attention back to Archos’ GPL download section. I originally thought these were all just media player firmwares, but it turns out “Archos Generation 7″ means the “Archos 5 Internet Tablet” and this tarball is a full GPL source release. Well done Archos! To their detriment, the binary firmware does not contain any obvious GPL mention – and this may mean they are still in technical breach of the GPL. The manual doesn’t mention anything either. But it’s still streets ahead of the others. Yay Archos!

(EDIT: I posted some details here. Please leave a comment if I’ve missed any tablets, or any source releases.)

What’s this GPL?

The GNU General Public License is a “copyleft” software license. Manufacturers releasing products with GPL licensed code, like the Linux kernel that underpins Android, are required to make their changes available in source code form.

Android itself isn’t GPL. Its open source Apache license does not mandate that source code has to be made available. However, all Android systems include the Linux kernel at minimum, and may also include other GPL-licensed pieces of software that are not part of the base Android distribution.

GPL source releases for these kernels make it easier for developers to build alternative operating systems, Android or otherwise, to run on the tablet hardware. It also allows improvements and changes to flow back “upstream” to the original software authors.

Why should consumers care?

The average tablet buyer isn’t an open source developer. However, having healthy open source releases means future support for these devices is guaranteed. Currently, projects like CyanogenMod make new improvements available to old Android phones whose manufacturers have already moved on. Similar community improvements could make new releases available on tablets, even though manufacturers are no longer supporting them.

Often, community Android releases are better than the original manufacturer’s. Slatedroid & ECOTOX have been releasing customised Android versions for the Eken M001 tablet which are both faster and support more features than the OEM release. Having kernel source available can only serve to make these releases better. For the Nook e-reader, community software releases allow you to view more ebook formats on your Nook, and even add totally unexpected features like Pandora Internet Radio.

Why should tablet manufacturers care?

Most manufacturers seem to be stuck in the “vendor” mindset that their hardware should remain entirely under their control, and that anyone else working on it is a problem.

However, it seems like community development almost always adds value to the hardware by extending it and adding more features. Especially in the tablet arena where there are no carriers to insist on platform lockdown to support their business model, an open platform doesn’t seem like it carries any significant drawbacks.

Some companies, particularly the smaller Chinese ones, appear to be concerned about competitors ripping their software off into compatible hardware. From what we’ve seen with the Eken M001 though, it doesn’t seem like source availability – especially kernel source – would do much to change the situation.

Outside of e-readers, there aren’t any companies competing on custom software anyhow: for the most part the software is vanilla Android, and competition is on performance, specifications, and especially price. This seems to make an even bigger opportunity for a clever manufacturer to embrace community open-source development, and differentiate themselves from all the “me too” Android clones without incurring any actual R&D cost.

What about chipset manufacturers?

A lot of kernel development for these devices is done by the original chipset manufacturers themselves. For example, it seems like VIA authored and compiled the kernels found in all devices based on the WM8505 chipset (including Eken’s tablets and some others..) It seems like the same story is true for Rockchip, who make the chipset used in the iRobot APad & Moonse E-7001.

Chipset manufacturers aren’t required to release GPL source code to the public, provided they send sources alongside any GPL software that goes to the device manufacturer. VIA has so far chosen this path, stating all sources are released to device manufacturers (although Eken has claimed differently at least once.) In the case of RockChip, manufacturers claim RockChip isn’t even doing that much and are violating GPL themselves (see first comment).

In addition, chipset manufacturers may sometimes author custom kernel modules or other components that are not GPL licensed at all. For example, Samsung have a video acceleration kernel module that is included in the firmware for the SmartQ tablet range. These components are normally not open sourced at all.

I can think of three reasons which chipset manufacturers do not embrace open source. One is that it is simpler not to. Another is that they charge device manufacturers for access to their SDK, and preemptively releasing source takes away that revenue stream (although possibly at the expense of extra hardware sales.) The last is that they are concerned about protection of their intellectual property, although this seems unnecessary given that most of their trade secrets are captured in the hardware itself, which is in turn protected by patents.

What about Google?

Google is in an interesting position here. On the one hand, they have worked hard to make sure that above the kernel layer Android is not GPL licensed. This serves to calm worried manufacturers threatened by the idea of having to release source. It seems, sadly, like a necessary step in order for Android to receive the kind of market prominence that Google wants for it.

On the other hand, it seems hypocritical for Google to tout Android’s “open source” credentials when it seems so clear that most companies profiting from it are completely oblivious, maybe even antagonistic, to open source.

I think there may be things Google could do to encourage manufacturers to be more friendly (or at least legally compliant) with open source, without scaring them off. An idea that springs to mind, especially now Google seem to be out of the device business, is promotion & accreditation of open source friendly manufacturers who receive extra kudos and promotion from Google in exchange for giving back to the community. Some kind of base level accreditation for companies who do not violate GPL, and additional incentives for companies who give back extra to the community.

Where to from here?

There are a lot more Android devices on the horizon, from a variety of manufacturers. It is my sincere hope that, especially following the growing buzz around “open source hardware”, at least one chipset or device manufacturer decides to make a break from the pack and announce “open source friendly products & manufacturing” that includes supporting community development.

Until then, if you care about open source you may actually be better off buying an iPad than many of the devices listed above. At least Apple comply with GPL and contribute back to the open source projects that they benefit from!

EDIT: Everything here is somewhat out of date now. Jacob Stoner has released a Debian build with X11 & touchscreen support. Initial post here. Initial download here.

Debian on the WM8505 netbooks has been around for a while, thanks to the efforts of #easypc’s abrasive. I needed to tweak a couple of things before his release worked on the Eken M001 tablet.

Before you begin

You probably want to start by plugging in either a USB keyboard or a serial cable. Otherwise, all Debian has to offer you is a blank login console.

Howto

Follow abrasive’s directions in the README here to set up the partitions on your SD card.

Before you boot the SD card, make the following 4 changes:

1. In the FAT partition you made, replace script/scriptcmd with this scriptcmd file.
2. Download the Eken official Android 1.6 upgrade from here, unzip it and copy the script/uzImage.bin file (kernel image) over script/uzImage.bin on the FAT partition you made.
3. In the ext2 partition, edit etc/inittab and replace this line:
   #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
   with this one:
   T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
4. Also in the ext2 partition, run sudo mknod (mount-point-of-ext2-part)/dev/ttyS0 c 4 64(or equivalent)

(The last two steps are only strictly necessary if you want to use the serial console, but the first two are necessary all of the time.)

Then pop the card in and you should boot into Debian! The instructions on the bento-linux Wiki for X11 work as well, although I found I needed a window manager (like xfce4) installed before X11 would stay launched.

EDIT: If you’re having trouble booting from SD, I just had an experience where uboot was refusing to load ’scriptcmd’ even though it was correct. I had to reformat the FAT partition and re-copy the files. Not sure what that was about, but might be worth trying if your Debian suddenly refuses to boot.

Notes

The new scriptcmd adds the kernel command line arg “console=ttyS0,115200n8″ to the command line. Seems unnecessary, but I couldn’t get it to boot successfully at all without this addition.

If you don’t replace the netbook kernel with the one from Eken, you won’t get any graphics display. Although debian will still run fine through the serial port. I’m guessing the netbook kernel has the LCD buffer at a different address.

Eken boots android with mem=109M on the command line whereas abrasive has used mem=112M. I don’t know if the Android version is allocating extra space for framebuffer double buffering, or something else. I haven’t noticed any differences yet so I’m running with mem=109M.

I haven’t tried the optional scriptcmd.install to install Debian to the internal flash, yet. I’m guessing you may need to repartition the mtd to get full use, as the Android partitioning scheme uses two partitions.

Pro tip: to see the insides of a scriptcmd file run ‘tail -c +73 scriptcmd’

Disk access when running from the SD card is sloooow (at least for slow SD cards like mine.) Don’t know if running from internal flash is any better.

I’m guessing that the framebuffer works normally in the Debian install because it isn’t using double-buffering, which is necessary for Android to work. I don’t know if ‘abrasive’ had to do anything special to get the ‘fbcon’ console module to work, I’m going to try and find out though!

EDIT: Jacob Stoner has come up with a small program to init the touchscreen, and a more recent version of evtouch that works for input. info here, init program & recent evtouch. He says he’s going to come out with an installable package (no serial/keyboard required) shortly.

I had a quick try at copying across the wm9715-api.ko & wm9715-ts_800_480.ko touchscreen modules from the Eken firmware, and using them with the package xserver-xorg-input-evtouch to provide a touchscreen mouse. No luck, though. The ‘evtest’ utility shows screen presses coming in, but no X/Y coordinates. A better approach might be to compile the the Wolfson OSS drivers against the 2.6.29 kernel headers.

Finally,

Want a quick laugh?


~# modinfo wm9715-api.ko
filename: wm9715-api.ko
author: VIA ShenZhen MCE SW Team
license: GPL
description: WM9715 api for the driver of touchscreen and battery

GPL, huh? This is kind of “GPL” where noone releases any source code. Ho ho ho! Thanks VIA, Wondermedia & Eken.

I have a EKEN M001, which will not unlock the screen by pressing MENU.

I have tried reseting the EKEN M001 by pressing the Reset button on the back ofthe MID, but te screen stays unlocked.

The top of the screen says: “Demo Version” when the GUI appears, does this need a Operating System update. If so, hpw can this be done.

Short Answer

I think your tablet has failed its internal licensing check. Try to return it to the retailer that you bought it from. If you now connect it to the internet, it will “phone home” to a company in Shenzhen, China.

EDIT: Before you give up try connecting to the internet for a while and leave it connected. It seems like sometimes “phoning home” will verify that it’s a legit install and then the message will go away.

Long Answer

This is a coincidence, because just yesterday I was looking at the decompiled Eken libraries posted to slatedroid by ‘bushing’. Hidden in there is licensing code that verifies the Eken is running on genuine hardware. I think it works like this:

• The Eken has a serial number loaded into its CPU (a WMT system parameter in the SoC.)
• The serial number maps to the hardware (MAC) address of the onboard wireless adapter.
• At startup, the Eken loads the serial number and compares it with the serial number it calculates from the wireless adapter.
• If they do not match, it locks and throws up “Demo Purpose Only” (possibly “Demo version has expired” on the latest firmware.) It will also continually try to “phone home” with some details about the device (see below.)

I think all of this is to prevent someone putting their firmware into another device, unlicensed. The code is obfuscated (intentionally hidden in the source) in the hope that a casual shanzhai observer will miss it.

From looking around the internet, it looks like quite a few devices are turning up brand new with “Demo Purpose Only”. The only easy thing to do is to return it to the retailer that you bought it from.

It is possible some retailers are selling fake or refurbished units (maybe they swapped the WiFi unit or the CPU daughterboard out.) In other cases like this, it looks like units may be shipping from Eken with invalid serial numbers (poor quality control?) Finally, in cases like this it seems that temporary problems with the WiFi may trigger this behaviour for a while, then it fixes itself.

Eken Phone Home

I found it quite surprising that the unit tries to phone home if it thinks its license is invalid. It phones home with 3 details:

• A username & password which is decoded from the file /data/wmtpref/custkey (in the firmware itself.)
• The MAC address of the wireless adapter

… the very odd thing is that the unit does not phone home to Eken. It phones home to a company called Aiteer, who are also based in Shenzhen but do not seem to have any published relationship with Eken. Aiteer’s web site doesn’t say anything about software development, but I can only guess that they did the firmware development for Eken and possibly related MID/tablet devices using the WM8505 chipset.

Other Thoughts

It’s odd that the firmware locks the user out and tries to phone home, because if the user is locked out then it’s unlikely that they’re going to be able to connect to the internet. Maybe I missed a detail in my reverse-engineering, and the lockout only kicks in every few minutes or something.

Although “phoning home” is pretty common, software phoning home without the knowledge or consent of the user is less common and is often regarded as unethical. I’m glad that in this case no personal information is being sent back, but clearly we’re at the mercy of the manufacturers in this regard. Unlike mainstream manufacturers, companies like Eken have no corporate presence outside of their factory in China – in other countries, the laws that protect consumers are effectively powerless. If you hypothetically did find out that an unscrupulous shanzhai was stealing your personal details, there is no real recourse you could take.

The license check code was obfuscated in the library (libui.so in this case) so that a casual observer would not see it. For example, nothing unusual showed up when I ran ’strings’ the other day. However, a tiny bit more reverse-engineering shows up a helper method calling base64_decode to decode each of the string constants related to the license check.

The code used to decode the username & password from the customer key, as well as the code used to calculate the serial number, are both trivially simple and anyone with some C programming knowledge can decipher them from the decompiled dump in an hour or two. For this reason, I think that the manufacturers only put in this protection to avoid casual copying of their firmware into another product – anyone serious about ripping them off could spend a couple of hours and generate their own serial numbers, and disable the “phone home” feature, without needing to modify the binary code at all.

Because the serial number is tied to the MAC, I don’t think anyone will be able to replace the WiFi module at all – even though you own the product.

It bothers me a lot that Eken are going to lengths to protect the tiny amount of proprietary code in their product, while not doing anything to fulfill either the legal obligations or the spirit of the substantial open source parts of the product. It bothers me doubly so now that they’ve locked out the root serial console in the latest (1.7.4) firmware release. How do they think that this helps their product?

Alternatives

First, the existing alternatives:

• Arduino has EEPROM, which is simple but it only reads/writes single bytes.
• Arduino Playground has two templated functions that let you read/write anything. However, you need to know the offset of whatever you are accessing. Also, I find C++ templates a bit icky for this use case.
• One level deeper, avr-libc has a more complex API for other kinds of integers, and buffers. However, you still need to remember offsets & sizes.
• The EEMEM keyword works like PROGMEM to let you flag things as stored in the EEPROM. Which is nice, but you still need to pass size and offset whenever you read a value.

Technique

This technique uses a single ’struct’ to represent the entire contents of your EEPROM, so you can then use macros to read and write fields.

You define a struct called __eeprom_data that describes your EEPROM:

struct __eeprom_data {
  int first;
  int second[64];
  boolean third;
  char fourth[buf_len];
}

Then use macros eeprom_read & eeprom_write to read and write each field:

int x;
eeprom_write(-7, first);
eeprom_read(x, first);

Full Example

/*
 * Copy and paste this block of #include & #defines into your code to use
 * this technique.
 *
 * (Don't worry too much about reading the macros, read through the
 * examples below instead.)
 */

#include <avr/eeprom.h>
#define eeprom_read_to(dst_p, eeprom_field, dst_size) eeprom_read_block(dst_p, (void *)offsetof(__eeprom_data, eeprom_field), MIN(dst_size, sizeof((__eeprom_data*)0)->eeprom_field))
#define eeprom_read(dst, eeprom_field) eeprom_read_to(&dst, eeprom_field, sizeof(dst))
#define eeprom_write_from(src_p, eeprom_field, src_size) eeprom_write_block(src_p, (void *)offsetof(__eeprom_data, eeprom_field), MIN(src_size, sizeof((__eeprom_data*)0)->eeprom_field))
#define eeprom_write(src, eeprom_field) { typeof(src) x = src; eeprom_write_from(&x, eeprom_field, sizeof(x)); }
#define MIN(x,y) ( x > y ? y : x )

const int buflen = 32;

/*
 * __eeprom_data is the magic name that maps all of the data we are
 * storing in our EEPROM
 */
struct __eeprom_data {
  int first;
  int second;
  boolean third;
  char fourth[buflen];
  char fifth[buflen];
};

void setup()
{
   Serial.begin(57600);

   /*
    * Writing simple variables to the EEPROM becomes simple
    *
    * First argument is the value to write, second argument is which field
    * (in __eeprom_data) to write to.
    */
   int q = 132;
   eeprom_write(q, first);
   eeprom_write(5958, second);
   eeprom_write(false, third);
   eeprom_write("Hello from EEPROM!", fourth);

   /*
    * You can even write from a pointer address if need be
    *
    * First argument is the pointer to write from.
    * Second argument is the field (in __eeprom_data)
    * to write to.
    * Third argument is the buffer length
    */
    const char * buf = "Another hello looks like this";
    eeprom_write_from(buf, fifth, strlen(buf)+1);

    int a, b;
    boolean c;
    char d[buflen], e[buflen];
    char *e_p = e;

    /*
     * Reading back is just as simple. First argument is the variable to read
     * back to, the second argument is the field (in __eeprom_data) to read
     * from.
     */
    eeprom_read(a, first);
    eeprom_read(b, second);
    eeprom_read(c, third);
    eeprom_read(d, fourth);

    /*
     * You can read back to a pointer address, if you need to.
     */
    eeprom_read_to(e_p, fifth, buflen);

    Serial.println(a);
    Serial.println(b);
    Serial.println(c ? "TRUE" : "FALSE");
    Serial.println(d);
    Serial.println(e_p);

    /*
     * The eeprom_write macros do bounds checking,
     * so you can't overrun a buffer.
     *
     * In __eeprom_data, 'third' is a one-byte boolean, but
     * eeprom_write knows this so only the first char 'T' is written
     * to EEPROM
     */
    eeprom_write("This is a buffer overflow", third);

    /*
     * If you have an array, like char[], you can write & read a single
     * array entry from a particular constant index
     *
     * Unfortunately, it only works for constant indexes not variables.
     * eeprom_write('X', fourth[x]) does not work with these macros.
     */
    eeprom_write('X', fourth[3]);
    eeprom_read(d, fourth);
    char x;
    eeprom_read(x, fourth[3]);
    Serial.println(d);
    Serial.println(x);
}

void loop() { }

(This is Arduino code, obviously if you’re using avr-libc directly then you can rewrite it for that.)

Downsides

The downsides of this technique (as I see them) are:

• Uses macro magic (so a bit icky.)
• Overkill if you only need to store one type of data in EEPROM, but useful if you have lots of different types.

Initial Values

When you start up, you need to know if the data in EEPROM is data that your program saved, or something else. There are a few different ways to deal with this.

EEMEM

EEMEM provides a way for you to set default values easily in your code:

EEMEM struct __eeprom_data initial_data EEMEM = {
  1, // first
  2, // second
  false, // third
  "Initial fourth", // fourth
   "Initial fifth" // fifth
};

Via avr-objcopy & avrdude you can generate a .eep file and flash it to the AVR. This is nice, but it won’t work if you’re using the Arduino IDE because (as of version 0018) it doesn’t generate .eep files properly, and it also doesn’t support flashing them.

It’s a good option if you’re using your own Makefile, though.

“Magic” number

The other way is to check for and expect a “magic” value somewhere in the EEPROM data. Something like:

// Change this any time the EEPROM content changes
const long magic_number = 0x5432;

struct __eeprom_data {
  long magic; // should be set to magic_number
  int first;
  int second;
}

void setup() {
  long magic;
  eeprom_read(magic, magic);
  if(magic != magic_number)
    initialise_eeprom();
}

void initialise_eeprom() {
  eeprom_write(0, first);
  eeprom_write(0, second);
  eeprom_write(magic_number, magic);
}

This teardown shows the V006 revision of the board, a quick serial port install, and includes some console/dmesg output. The main difference between V005 and V006/V007 board revisions seems to be relocating the USB WiFi dongle to a better position.

EDIT: It took me a while to post this article, and Slatedroid is down this past week. So links to there will be broken (hopefully not for good.)

This isn’t the first teardown of the Eken M001, the first one was the “Aimless Teardown” and there is also a disassembly howto video by another community member.

Warning

I’ve had lots of hardware problems with my Eken since I took it apart. They may have been there before, but maybe not. YMMV, but be careful and remember you may not still have a warranty after the device has been opened, and especially after it’s been modified.

Specifically, I have two problems. There is a cold solder joint in one corner of the board (I’m currently warming it up before it will boot at all.) Also I get occasional failure of the LCD (totally black) on reassembly, which requires me to press on the front of the unit until it clicks back on.

Getting In

1. Remove the two phillips screws on each side of the base:
   

2. The only other thing holding the back on is a series of plastic clips around the outside of the unit. Working from the base (the first clip is half-way between the two screws), carefully insert a plastic spudger or a knife (worse, but what I used) and jiggle it around until each clip snaps open. Some clips may break, they’re not very strong.

   Then work your way along towards the top of the unit:
   

   

3. Once all the clips have popped, remove the plastic back. Take care not to disturb the small speaker
   
   

Main Board

(Click through for a high-res version.)

You can see:

• Battery and backlight connectors bottom-left
• Internal USB soldered to pads bottom-right (leading up to the USB WiFi module, installed top left.)
• LCD and touchscreen ribbon connectors on the left side.
• Main CPU daughterboard in DIMM socket.

CPU Board

Here’s some shots of the CPU daughterboard:


The board is hosting a VIA/Wondermedia WM8505 SoC. Datasheet shared here (courtesy Slatedroid, again.

Serial Connector

J17 on the back of the board is a RvTTL (3.3v) serial port. 115200 8N1. Pinout, left to right, is Vcc Tx Rx Gnd.

I didn’t take any photos of it before I soldered on my serial port, but here it is after:


The only other interesting thing I saw on the back of the board was the 2Gb NAND flash:


Boot logs

Once you have the serial port connected, you can grab some log data easily (and you also get a root shell once startup completes.)

EDIT: As of firmware release 1.7.4, no more automatic root shell on serial console. It’s still a boot console, but for root you need to log in… Poor show, Eken.

Standard kernel boot log, plus some /proc entries

Log of a factory upgrade via SD card

I meant to capture and post some of the ‘logcat’ Android log output as well, from standard startup, but it doesn’t look like I kept any.

]]> http://projectgus.com/2010/06/eken-m001-teardown-serial-consol/feed/ 1 http://projectgus.com/2010/06/notes-on-porting-android-2-x-to-eken-m001/ http://projectgus.com/2010/06/notes-on-porting-android-2-x-to-eken-m001/#comments Thu, 10 Jun 2010 12:54:41 +0000 angus http://projectgus.com/?p=268 Over the past couple of evenings I’ve been looking into porting Android 2.x (eclair or froyo) to the Eken M001. These are my notes from unsuccessful binary-only reverse engineering.

Short version

Although Android 2.1, and possibly 2.2, will run against Eken’s supplied 2.6.29 kernel, Eken have patched several of the ‘base’ userspace binaries against the proprietary Wondermedia SDK. Without accessing the SDK, or reverse engineering the SDK’s workings, it may not be possible to port Android 2.x to the Eken.

I worked this out trying to install the iPhone Android 2.2 port by munging it into the existing Eken binary firmware. I initially had a lot of success, because the link I followed was completely wrong, and I had the Android 1.6 iPhone build. After I got that booting to the home screen, someone on the slatedroid forums let me know it was the wrong version. Oops! I then found a genuine binary release of Froyo for iPhone and tried the same tricks, without success.

In this post I’ll explain what I learned. I hope it’s of use to someone.

Differences in firmware format

One of the first things that you’ll notice is that Eken firmware looks different to “normal” Android disk images. Instead of a group of disk images, the main Android userspace data is contained in two tarballs – android_fs.tgz and data.tgz. android_fs.tgz contains the parts of the filesystem would normally be mounted from ramdisk.img and system.img, data.tgz contains the parts from userdata.img.

A u-boot script (scriptcmd) in the firmware package performs an initial flash of the bootloader and then directs the Eken to boot from a small ramdisk image on the SD card. Ramdisk init then runs update.sh to reflash the firmware onto the internal flash.

Other than the different firmware image layout, the firmware layout of a running Eken is similar to any other Android system.

Using the Eken kernel

There are no kernel sources, so the Eken-provided 2.6.29 kernel is the only one we have. Slatedroid user bushing has started working on an alternative kernel, here, but it is very early days (doesn’t boot, let alone support any of the Eken’s WM8505 hardware.)

I don’t this is the big problem for Android 2.x, though. 2.1 officially supports kernel 2.6.29, and it looks like the 2.2 userspace components might even run against the 2.6.29 kernel without any serious problems (although probably with reduced performance.)

Getting info

The serial port on the board gives you a linux kernel console, and then a root shell with busybox. Running ‘logcat’ gives you the Android log as it runs. Run ‘logcat -d’ if you don’t want to lose your root shell forever. Strace is also available.

Munging the firmwares

My dodgy technique for munging the firmwares together was, roughly:

• Copy the iPhone system.img contents over system/ in android_fs
• Copy init and init.rc from iPhone ramdisk.img to the root of android_fs
• Merge differences between the new init.rc and the old Eken one.
• Flash & Boot!

Dodgy framebuffer driver

This method eventually leaves you with a flashing LCD display, showing 4 distorted copies of the screen you’re expecting. That’s what I got with 1.6 & 2.2, and I think that’s where Slatedroid modder ECOTOX got to as well.

If the Eken kernel provided a properly supported framebuffer device, this wouldn’t happen. The framebuffer device looks correct (although unaccelerated):


/ # fbset -s -fb /dev/graphics/fb0

mode "800x480-0"
# D: 0.033 MHz, H: 0.035 kHz, V: 0.066 Hz
geometry 800 480 800 480 32
timings 30000000 40 24 32 11 96 2
accel false
rgba 8/16,8/8,8/0,0/0
endmode


… but that’s not enough. There’s some userspace magic required to make the display work properly. Normally this would be implemented in the driver itself, and standard ioctl calls would make the changes. In this case, Android’s /system/lib/libui.so has been patched and now links against libwmtapi.so, a proprietary Wondermedia WM8505 SDK library:


:lib gus$ strings libui.so | grep wmt
wmt_vpp_init
wmt_vpp_set_direct_path
wmt_vpp_exit
wmt_mb_init
wmt_mb_alloc
wmt_mb_user2phys
libwmtapi.so
wmt_setsyspara
wmt_getsyspara
wmt_getsocinfo
wmt_vpp_set_direct_path


… I have no idea what it’s doing, but when I copied the patched libui.so (and dependencies) onto my Android 1.6 iPhone system, the display immediately started working.

On Android 2.2, copying the library causes system_server to segfault because the library is no longer ABI compatible. There have been big changes, just look at the 1.6 ui headers compared to the 2.1 ui headers. So there’s no way the patched libui will work without the source patches being merged and recompiled, at the minimum.

That’s not all either, there are actually quite a few Android libraries linked against WMT libraries, presumably with other patches:

$ grep libwmt *
Binary file libcamera.so matches
Binary file libmediaplayerservice.so matches
Binary file libopencore_player.so matches
Binary file libui.so matches


Where to from here?

Speaking for myself, I’m done, unless Eken release their Android & kernel sources. There’s no sense in working to improve a product when the company itself is blatantly abusing OSS and refusing to honour its obligations.

On the other hand, even if an Eken source release left out the Wondermedia SDK, it would be a great start.

In the absense of the source, it seems there would be two options for the intrepid coder. The first would be to reverse-engineer the WM8505 hardware and write an OSS version of the platform drivers. This would be a massive job, although there is a datasheet we don’t even have JTAG available for debugging.

Alternatively, some judicious use of objdump would probably show what calls are being made to libwmt. With that knowledge, it is possible to reverse engineer function declarations and create patches for the relevant sources in Android 1.6, then port those source patches to Android 2.x. (I posted steps that I would try to follow, here.)

]]> http://projectgus.com/2010/06/notes-on-porting-android-2-x-to-eken-m001/feed/ 12 http://projectgus.com/2010/06/eken-m001-android-tablet-review-pt-1/ http://projectgus.com/2010/06/eken-m001-android-tablet-review-pt-1/#comments Thu, 03 Jun 2010 13:17:05 +0000 angus http://projectgus.com/?p=233 This is part one of an 3 part mini review of the Eken M001 tablet, from a tinkerer’s perspective.
• Part One: Review of the M001 as a tablet.
• Part Two: Teardown & serial console.
• Part Three: The M001 board as an embedded computer for robotics.
  (Robotics plan aborted due to poor build quality & insufficient vendor support, see below.)




What is it?

It’s a sub-$100 tablet computer running Android, with a 7 inch touchscreen and 2Gb of onboard storage.



There are a few other cheap models with the same chipset, like the M003 (bigger 8″ screen) and a netbook form factor model.

Summary

You get what you pay for.

Longer Summary

If you want an iPad, but don’t want to spend the cash. Don’t buy this. It’s not in the same league as devices like the iPad

If you want a “tablet device”, just not an iPad because you’re ideologically or tribally opposed to Apple, or you’re sure you need something that the iPad doesn’t do. Don’t buy this either. You’ll be underwhelmed, and eventually it’ll end up gathering dust on a shelf while you look to the next big iPad killer.

If you want a digital photo frame, a clumsy furless chumby, a mediocre tethered video player, or an ebook reader that works in the dark for limited periods. This might prove OK for your needs.

If you just want something to tinker with, then this is a good cheap gizmo to tinker with.



The Good

Price. $99 including shipping anywhere in the world. ‘Nuff said.

LCD. It’s actually pretty good for a cheap LCD display, especially if you’re in low light.

Performance. Pretty good in general, UI is responsive and snappy. Better than an iPhone 2G, similar to a 3GS. Some performance tasks (like video playback, depending on codec & resolution) are a bit limited by the CPU, though.

Community. A small community is forming around the M001. They have already come up with some software improvements. Unfortunately, they are limited by poor vendor support (see below.)

The Bad

Touchscreen. It’s resistive, so it’s never going to be much good for finger presses. My unit has major problems with mis-touches (wrong buttons being pressed) and identifying the difference between a tap and a swipe. Using a stylus didn’t really help, either. I think this might be solvable in software though, with better debouncing in the touchscreen driver.

Build quality. It isn’t going to fall apart immediately, but it’s not built to last. In particular, things like the LEDs are just cheap and nasty – one of the 3 indicator LEDs is enough to light up all 3 recesses, and the area around it.

In indoor lighting, it makes the LEDs really hard to read (only one is on in this shot!):


In darkness, the whole thing glows:


Fake chrome around the LCD. What were they thinking? Looks good in promo shots, means you have a reflection of your face any time you use the device in bright light. Really bad usability choice.

Battery Life. Seems like 2-3 hours is the norm, and the battery runs down at almost the same rate when the device is idle compared to when it is in use. Probably a driver problem, but whether it can/will be fixed is up in the air.

Accelerometer. Way too sensitive, the tablet flips orientation at any chance – including just when laid down on a table. Another driver sensitivity issue, I’m guessing.

Android 1.6. Lack of 3D acceleration, and only 128Mb of RAM, give the general opinion that Android 1.6 will be the last version that runs well on this device. That said, noone has actually run 2.x on it yet.

Bad vendor support. Eken haven’t released any of the GPL sources that they’re required to release. Not only is this in violation of the license, it prevents community members from working together to improve the software and the device performance. If I had to pick one thing that limits the potential for the M001, this would be it.

I think in this market a vendor who really nurtured open source development, and swiftly incorporated improvements back into the official software updates, would find a real competitive advantage – the product would still be cheap, but the software and driver layers would be less buggy and restrictive.

Conclusion

I didn’t buy this as a tablet (I bought it for a robot platform), so maybe I’m not the best person to review it as a tablet. However, I can’t see myself ever reaching for the M001 to perform anything but the simplest of tasks – watching a video I’d already loaded on it, for example.

My prediction is that in 3 months, pending some amazing community software developments, many of the models sold to date will be gathering dust in a corner.

]]> http://projectgus.com/2010/06/eken-m001-android-tablet-review-pt-1/feed/ 12 http://projectgus.com/2010/04/apple-takes-all/ http://projectgus.com/2010/04/apple-takes-all/#comments Mon, 05 Apr 2010 12:12:13 +0000 angus http://projectgus.com/?p=196 I’m a bit late to the party on this one. I’ve read all of the big ranty iPhone and iPad arguments. I’ve worried a little about the monoculture that the iPhone represents. I decided these were mostly ivory tower arguments. Meaningful for geeks and technorati, but not for anyone much else.

I changed my mind this weekend.



This weekend I attended the National Folk Festival here in Canberra. Folk Festivals are a celebration of traditional folk music and folk arts. With a smattering of other musical traditions and innovations, the focus is on traditional musical instruments played in traditional folk styles.

As far as I can see, it’s about as far from Silicon Valley as you can get without winding up in Deliverance.



This year, National Folk Festival has an iPhone app.

History of the NFF Programme

1967-	printed on paper
2000	also available as HTML
2003-	also available as PDF
2010	also available as iPhone app

This is a pretty momentous innovation.

Don’t get me wrong, it really is an innovation. At a festival where a dozen performers are playing at any given time, finding out what’s on is hard. Being able to see it quickly and easily on your mobile phone is extremely useful.

I’m worried because, as in all things, it’s an iPhone App. If you were a Mac or Linux user around 1999, you were probably familiar with web sites that required “Windows 95 & Internet Explorer 5 or Better”. They didn’t work on your computer, or they only half worked.

We now have the same situation, ironically rearranged. If you have any other mobile phone, you are a second class online citizen. Everywhere, up to and including folk festivals.

Yes, you can probably read the PDFs on the web site. No, that’s not going to be very good. The iPhone app, on the other hand, is great.



Is there an alternative approach? Maybe. The NFF site is powered by WordPress. “Mobile site” plugins exist that could format the programme for various mobile browsing devices. With some CSS wizards at the helm, I’m sure it could be quite nice.

Would that experience be as good as the iPhone app? I doubt it. The iPhone app that Bonobo Labs have made is really slick. On the iPhone, I think it could be recreated as a web site for Mobile Safari. However, I don’t think it could reach that standard for every single mobile device. The standards and the frameworks aren’t really there, and the browsers aren’t all up to it.

Making something that at least works on other phones is, however, very possible.



So what’s the point to this rant, then? Nothing really, except that I think it’s worth worrying about. In 2000 I was proud that I wasn’t stuck with Internet Explorer 5 “or better”. The alternatives were innovative and they helped dig the web out of a monoculture of ActiveX controls and bad proprietary HTML.

In 2010 I have an iPhone. I’m guilty about liking this monoculture so much. How are competitors going to innovate, short of providing a phone with a full Apple App Store compatibility layer? Is this really today’s IE 5?

(Photos taken by me at the 2008 festival.)

]]> http://projectgus.com/2010/04/apple-takes-all/feed/ 1 http://projectgus.com/2010/03/openwrt-8-09-usb-storage/ http://projectgus.com/2010/03/openwrt-8-09-usb-storage/#comments Sat, 27 Mar 2010 08:22:05 +0000 angus http://projectgus.com/?p=181 This is just a quick note on some experiences using an external USB drive with OpenWRT 8.09 on an Asus WL-500gP.

Mount options not honoured

It seems that mount options set in /etc/fstab aren’t honoured properly. I’ve filed a bug report here with a fix. If you have a running OpenWRT installation, you can grab the /sbin/usb-storage replacement from there and copy it onto your router.

A particular badness of this bug is if you’re relying noatime/nodiratime to stop your disk spinning up, or your USB stick wearing out(!)

USB startup timing

This isn’t a bug in OpenWRT, just an annoyance.

On the Asus WL-500gP (at least), USB devices don’t come online until 10-20 seconds after startup. This means that USB disks don’t mount until some time during the boot process.

This causes a problem if you have any init scripts that rely on an external disk (for example, if you’ve added Optware packages and symlinked in some Optware init scripts.)

The (half-assed) solution I have come up with is to put in an init script that waits for usb-storage to come online, and then sleeps while the disks are mounted. Make sure this script runs before any other init scripts that require the external disk.

1. Download the script from here
2. Copy the script to /etc/init.d on the router.
3. Enable it with /etc/init.d/usb-storage enable
4. You will now have /etc/rc.d/S50usb-storage. Make sure any other init scripts that rely on external disks come after ‘50′

There are a variety of other hacks to get all this stuff working, this is just my take on it. It looks like external storage has been dramatically overhauled in the upcoming OpenWRT release, so hopefully it will no longer be an issue.

]]> http://projectgus.com/2010/03/openwrt-8-09-usb-storage/feed/ 0 http://projectgus.com/2010/03/wireless-client-bridging-with-openwrt/ http://projectgus.com/2010/03/wireless-client-bridging-with-openwrt/#comments Wed, 17 Mar 2010 11:44:44 +0000 angus http://projectgus.com/?p=122 Renting sucks when you’re a nerd. When you move, you have to re-network all your bits and pieces, without the benefits of laying cable. Wireless is great, but not every network device has it. I have a VoIP phone and an XBMC XBox, each without wireless and each in a separate room.

I need a way to connect the phone and the Xbox to my existing wireless access point.

Here’s a rough diagram of my network:




Rough diagram of my network

Options

I want a flat network, single broadcast domain, for all of the (wired and unwired) devices in the diagram above.

I already have two Linux-compatible wireless routers, an Asus WL-500G and a Fonera. Both running OpenWRT.

If my routers had Broadcom wireless chipsets then this task would be easy. Thanks to driver support, OpenWRT can automatically bridge network segments through a wireless client (at least on 2.4 kernels, not sure about 2.6.) Neither of my routers have Broadcom. The Asus used to have it, but I swapped in an Atheros card. Oops.

WDS is a possibility, using each router as a repeater station. However, each repeater costs half the available bandwidth. I also can’t get WDS+WPA to work with my access point. YMMV.

You can set up separate networks, one for each segment, and the routers can route(!) between them using iptables. I’ve tried this and I don’t like it. It’s much easier when you have one single network with a single broadcast domain: simple DHCP, simple NetBIOS lookups, no routing tables to maintain, etc.

The final option, and the one I settled on, is using ARP-NAT.

What is ARPNAT?

ARPNAT is a clever hack. It’s the same idea as NAT for IP networks, except it works one layer deeper. Instead of translating IP network addresses, the router translates between the MAC hardware addresses on each side of it.

If something on the wired side of the router makes an ARP request for the MAC address of an IP on the wireless side, then the router forwards the request as if it came from the router. When the response comes back, it mangles that too. Instead of passing back the real MAC (which lives on the wireless network), the router gives its own wired MAC address. Then, when it receives frames for IP addresses on the wireless network, it forwards them through. It does this to both sides of the bridge.

Here’s an example, taken from my network:

1. XBMC Xbox asks “What is the MAC address of 10.0.0.1? Tell me: 10.0.0.5.” This is a broadcast ARP request over the wired ethernet.
2. Asus router sees the ARP request, and forwards the broadcast onto the wireless network, as “What is the MAC address of 10.0.0.1? Tell me: 10.0.0.4.”
3. Access point (at 10.0.0.1) gets the ARP request from the wireless, and replies with its MAC address: AA:AA:AA:AA:AA:AA.
4. Asus router gets the ARP response, sent to 10.0.0.4. It mangles it and forwards it back to the Xbox as “10.0.0.1 is at BB:BB:BB:BB:BB:BB”, where BB:BB:BB:BB:BB:BB is the wired address of the Asus itself.
5. Now, any time the Xbox wants to talk to 10.0.0.1, it will talk to BB:BB:BB:BB:BB:BB, and the Asus will forward that frame onto the wireless network, to the real destination AA:AA:AA:AA:AA:AA.

On Linux, this is done using a patched version of the ethernet filtering program ebtables.

How to do it?

Out of the box, OpenWRT does not support either ebtables or ARPNAT. The developers have expressed opinions that ARPNAT is a hack, and ebtables is too slow (see here & here.) We’ll get to that issue, later.

However, there are some forum posts that show how to do it. In this post, a developer of the OpenWRT fork Gargoyle links to their patch for ARPNAT. So, one option is to just use Gargoyle. Gargoyle apparently has a very nice web interface, and is good for intermediate users. I prefer flat config files, so I’m going to stick with OpenWRT.

Building OpenWRT with ARPNAT Support

If you’ve never compiled OpenWRT before, start here. Alternatively, I have some prebuilt 8.09.2 images for Atheros devices (like the Fonera), here.

To build, you’ll need two patches. One is from Gargoyle. The other is a small bugfix to allow a DHCP client to run on the router. The patches can be found here. These patches are against the 8.09 branch of OpenWRT SVN, I don’t think either will apply to the trunk.

EDIT: I’ve just posted a slightly different patch, 04-arpnat-brcm47xx.patch, for brcm47xxx devices like the Asus WL-500g. It’s different because these devices have an older kernel version in 8.09, and also because the arpnat kernel module doesn’t seem to load the first time around. Also, on this architecture DHCP responses don’t seem to pass back correctly to devices on the other side of the bridge (while on my Atheros-based Fonera they are passed back.) I’m just using a static IP on those devices, for now. Things will also work fine if the DHCP server is on the bridge router, itself.

You’ll need to enable ‘ebtables’ in your configuration (ie when you make menuconfig.) You’ll probably want wpa-supplicant as well. The .config that I used for the Fonera can be found at the link above, as well.

Once up and running, /etc/config/wireless only needs one tweak. Here’s mine:

config wifi-device  wifi0
	option type     atheros
	option channel  auto

config wifi-iface
	option device	wifi0
	option network	lan
	option mode	sta
	option client_bridge 1
	option ssid	<your ssid here>
	option encryption psk
	option key <your key here>

The only difference is “option client_bridge 1“, which indicates that you want ARPNAT enabled.

/etc/config/network is simple, too. Here’s the bridge section of mine:

config interface lan
	option ifname	eth0
	option type 	bridge
	option macaddr  CC:CC:CC:CC:CC:CC
	option proto	dhcp

The only difference here is option macaddr. You will need this only if you want to assign the router’s IP address dynamically via DHCP. If you do this, “option macaddr” must be set to the MAC address of the interface where the DHCP server lives (ie wired side or wireless side.) The DHCP request will only go out on a single interface, so you need to make sure it is the correct one.

If you don’t need DHCP then you don’t need to manually assign any MAC address. “option macaddr” can be totally removed.

That’s it! When the router boots up, it will connect to the wireless network, and any devices on the wired side will automatically be bridged onto the wireless (and vice-versa.) To them, it just looks like one big seamless network.

Bear in mind that not all routers support failsafe mode (Fonera for one), so if these values are wrong then you may end up locked out of your router, especially if you run the router with a DHCP-assigned address. If you’re not certain, I recommend running with a static IP first, so you can always plug in a network cable and still connect to the router.

Thanks again to Eric Bishop and the Gargoyle project, because it’s really his patch (building on other people’s work for ARPNAT) that makes all this possible.

Problems with ARPNAT

The OpenWRT developers will not consider ARPNAT, or even include ebtables, in the default package set of OpenWRT. They say this is because of performance impact. Every ethernet frame that hits the router needs to be inspected in software, so it’s understandable that there will be a cost.

Some cost is OK by me, in exchange for convenience. So I did some tests:

The test methodology was to ping flood the Fonera from a PC:



Performance of ebtables & ARPNAT (longer is better)

• “Ethernet, no ebtables” is a vanilla Openwrt 8.09.2 install
• “Ethernet, ebtables installed” is with patches and ebtables installed, but no ARPNAT enabled.
• “Ethernet, ARPNAT enabled” is with ARPNAT turned on, but no traversal (the pings still go just to the router.)
• “Direct WiFi” is pinging the router directly over the wireless network. It’s slower, but only because WiFi is slower than ethernet.
• “WiFi via ARPNAT” is pinging a client on the wireless side, from a client on the wired side. So the ping is going through ARPNAT translation on the router.

Under all of these tests the CPU on the router was pegged at >95%.

The results seem to show that ebtables & ARPNAT do not drastically affect the performance of the Fonera. Turning on ARPNAT causes direct traffic to the router to be about 17% more costly. Actually bridging packets through ARPNET on the router is only 32% more costly than directly accessing the router itself.

I’m surprised these figures aren’t worse, given the doom & gloom spouted by the OpenWRT devs. It’s possible there’s another circumstance under which ARPNAT falls over, or possibly it performs worse on certain architectures. I’ll post back if I learn anything interesting.

EDIT: One more discovery, obvious in retrospect, is that IPv6 won’t get ARPNATted by this config. If you have any devices that use IPv6 (like iTunes talking to an Apple Airport Express), you’ll either need to disable IPv6 or tweak the ebtables scripts somehow to translate IPv6 as well. I opted for disabling IPv6.

]]> http://projectgus.com/2010/03/wireless-client-bridging-with-openwrt/feed/ 12