This letter is my plea and suggestion to Wondermedia, although the theme applies to similar tech companies as well.

(If any fluent speaker can translate this into Chinese for me, I’d very much appreciate it!)

Dear Wondermedia Technologies,

Congratulations on your WM8505 system-on-a-chip. In 2005, a “$100 laptop” was a visionary idea, a dream. Now, thanks to your technology, I can buy a netbook for $85, including shipping to my house in Australia. If I was in Shenzhen, who knows how cheap it would be?

That netbook has more power than the $3000 desktop computer that I owned 12 years ago.

However, it’s not all good. Ars Technica recently labelled the $99 Maylong M-150 tablet the “worst gadget ever”. That tablet is built around your WM8505. Noone who reads that review will buy the product. No importer will read that review and decide to wholesale order any WM8505 product. No hardware engineer would choose WM8505 on the basis of that review, either.

It doesn’t have to be that way. Vendors can ship better tablets and netbooks, that get better reviews, at no cost to you. You can sell more units, at no cost to you.

Take a look at the custom firmware on Slatedroid.com. Every one of those people has modded the same proprietary WM8505 build of Android 1.6 to try and make it better. It runs faster and smoother and has more features. They have spent hours of their time trying to make your products better.

Take a look at the rough port I did of Android 2.2 this week. It’s very poor quality, but it doesn’t have to be. It can be better, at no cost to you.

Look at the months of hard work by the talented Alexey Charkov to make a WM8505 Linux kernel that is good enough to be in the official kernel tree. Big players like TI, Marvell, NVidia all pay talented developers to make Linux code that is good enough for inclusion in the official kernel. Alexey is doing the same for you, for free. His work is coming along slowly, but it could be coming faster. You can help him to help you, at no cost.

What resources are the community using, at this moment? At the beginning, barely anything at all, just incomplete leaked data sheets. Then you were kind enough to release most of your Linux kernel source, which has helped greatly.

<

p>I’m writing this letter to suggest you release more, for your own benefit. Many big companies provide datasheets, BSPs, SDKs, source code for free. You should do the same with what you already have. With more information and more source code, it would be possible for the community to build many things. If we had the Android 1.6 source code, WMT SDK source code, or current/complete documentation (even in Chinese) then the community would be able to develop Android firmwares with more features and better hardware support, maybe even a 2.2 port that runs well. There is nothing stopping vendors from shipping devices with a community Android build, if it is better. More WM8505 sales, at no cost to you.

More datasheets and documentation will also make Linux kernel development faster and better. How much of your own developers’ time do you save if the mainline Linux kernel has Wondermedia hardware support in it, instead of having to keep patching it in-house? Better quality kernel, less maintenance costs, no cost to you.

The community is indirectly trying to give you a competitive advantage, for free. All you need to do is open up.

Why not open up? One reason, I think, is that you probably charge for this information. Charging for BSPs & SDKs is a revenue stream. I ask you this: How big is that revenue stream? How many more units do you need to sell before it does not matter any more?

Maybe you think that you can’t afford the support costs, or the maintenance overhead. If this is a concern, rest assured that the community does not need much. Even if you just “leak” a torrent file or send the files for someone else to host, the Internet will make sure that they never go away. The community already provides support for each other.

I realise this is not the same as most small hardware companies’ culture. However, there’s no reason why you can’t behave like the big companies on this. This will differentiate you in the marketplace and give you an advantage. The community is standing by, waiting to help make your products great.

These words apply to all similar companies, not just Wondermedia. If someone becomes the first truly open manufacturer of small, affordable, embedded ARM systems then I predict that the developer community will beat a path to their door.

Update 25/11: Now supports M003 as well, and it appears the M002 may be able to boot from the M001 build.

Update 27/11: New build posted, now with better functioning Wifi!

Android 2.2 on dirt cheap WM8505 tablets. I said it may not be possible. Since then, I’ve spent hours and hours trying to reverse-engineer the custom calls that the WM8505 Android port uses to set up the correct graphics modes. I still can’t replicate their process successfully.

However, on Sunday I had what my friend Adam has called “an a-ha moment1. Android’s own porting guide says the graphics mode has to be RGB565 with double-buffering (aka page-flipping), but apparently this is not strictly true.

Within a couple of hours, I had a Froyo home screen up on my M001:

Now, a few busy evenings later, I can offer a hacky alpha for people to check out, and hopefully build upon. However, this is not the same as “the Eken M001 now supports Android 2.2“.

Get to the Android already!

OK, here it is. This build is configured to boot entirely from the SD card, to minimise the chances of bricking a tablet and to make it easy for people to check it out. You should be able to run this without any impact on the OS installed in the tablet.

This image is a dodgy hack, pre-release quality, and totally unsupported, btw. Do not expect very much.

Installing from Linux/OS X

If you have a 2Gb+ SD card, you can download the image (M001 or M003) and use ‘dd’ to copy it over the top of your SD card:

zcat image-m001.gz | dd of=/dev/sdX

(where sdX is your SD card device. You’ll need to unmount the SD card, first.)

Installing from Windows

If you’re unfortunate enough to be stuck on Windows, you can download a zip file with the image (M001 or M003). First, unzip the image. Then, the Slatedroid forums have instructions on how to flash the Debian SD card image from Windows. If that doesn’t work, you can try these instructions. The Debian image is the same format as the Froyo image, so the same steps should apply.

Installing the SD Card manually

If you have a smaller SD card, or you just want to make your own, then I also uploaded tarballs containing the FAT and ext2 partitions for each tablet. You can unpack these onto any SD card, with the following partition & formatting scheme:

  1. FAT16 (for script/ directory)
  2. linux-swap (optional)
  3. ext2 (for root filesystem)

(NB: The partitioning scheme has changed since the first set of posted images.)

First boot

The first boot from the SD card will take a few minutes longer than usual, because the Dalvik VM is generating its cache. I think mine takes around 5 minutes the first time.

Status

The following things work:

  • Basic Android UI
  • Touchscreen
  • Blanking the screen when idle
  • Swap partition on SD card

The following things should work, please test:

  • Wifi
  • SetCPU & other CPU scaling (will need to “root” first)

The following things are untested and probably don’t work:

  • Audio
  • Video playback (probably will be choppy)
  • Battery level tracking
  • Automatic screen rotation (I hope you like landscape)

However I expect all those things should be fairly easy to implement, except for smooth video playback.

The following things definitely don’t work:

  • Graphics acceleration, there isn’t even page flipping/double buffering at the moment, let alone OpenGL ES (which there will never be.) It isn’t as painfully slow as I thought it might be, but it definitely isn’t fast. There are also a few artifacts, like lock screen redraw when turning back on. Also, some apps may not work as expected due to the odd graphics mode.
  • Touchscreen calibration. The device ships with my Eken M001 calibration on it. If mine is no good then you can copy your /data/wmt/touchcal to /etc/touchcal on the SD card to bring it across. But there’s no WM8505 calibration app installed, so someone either needs to port Wondermedia’s or write a new one from scratch.
  • Suspend/Resume (was broken in 1.6, still broken in 2.2 as it’s a kernel deficiency.)

Installing to the flash in the tablet

At the moment, this only supports booting from SD card. However, there’s no reason why someone clever couldn’t build an alternate version that installs to the tablet’s internal flash – all the required pieces exist AFAIK.

Building On This

All the scripts & patches I used are available on github. There should be enough there for a savvy person to fairly easily build this again from an AOSP release.

The kernel used is “my” copy of Wondermedia’s kernel source release. Hopefully as Alexey’s from-scratch kernel adds more features, it will eventually be able to run Android as well.

If you do build anything using this, please please please share source/instructions for what you improve. Every “secret” someone hoards away is a step away from making these devices properly usable.

This Froyo build comes unsupported (sorry), and I’m not likely to do a whole lot more on it. However, one thing I do intend to do is get it running on my Eken M003 (my M001 has serious hardware problems so I can’t really use it as a tablet any more.)

However, I really hope that others will jump in, build on it, and make something good. Enjoy!



  1. I called it a doh! moment []

I seem to be getting at least two unsolicited questions a day from people who have inadvertently bricked their Eken M001/M002/M003 or Flytouch/noname tablets . So here’s a quick post with what I know about unbricking.

You should also try slatedroid, and hassle whoever is making custom firmwares to remove the unnecessary bootloader reflash steps. These dangerous reflashes are what is causing so many tablets to brick in the first place.

Also, always plug your tablet in to the charger when flashing. Never unplug it or turn it off while it’s flashing, even if you’re accidentally flashing it twice. Seriously, people.

Bootloaders

WM8505 tablets have a pre-bootloader called W-Load, then a bootloader called u-boot, then the main OS boots.

U-boot will read a custom boot script from a file “script/scriptcmd” on an SD card, if it is present. This is how upgrades and reflashes work. U-boot is also capable of interacting with the user via the built-in 3.3v serial port, if you solder some wires to it.

Stuck on the ‘Android Logo’ boot screen

This is the first screen, which also says “Kernel Version X.Y.Z” and “SDK Version X.Y.Z.”. This screen is put up by u-boot.

If you’re stuck on this screen then u-boot is loading, which is a good sign. If putting in an SD card with an upgrade script does not work, then it may be broken in some other way. You may be able to connect a serial cable and interact directly with u-boot to issue commands.

Before you bother with the serial cable, make very sure you have formatted your SD card correctly (FAT32) . Try reformatting and re-copying all the files to the SD card, and then try using a different SD card. Various people have reported that only SD cards 2Gb or smaller work reliably.

Stuck on the ‘Android’ “shimmer” boot screen

If you’re stuck on the next boot screen (the text ‘Android’ that shimmers back and forth) then Android has started loading but is crashing. Reflash via the SD card.

Blank screen

If you have a totally blank screen then this is a much worse sign. In my experience, I’ve seen three possible things:

If the red power light blinks on when you press Power but then immediately goes out

Then you have a fault in your power circuit on the board. In my Eken, I can still make it boot if I take the back off and heat up the board with a heat gun (hair dryer would also work.)

If the red power light stays on and eventually you hear the ‘ding’ startup sound

(Instead of the ‘ding’, another sign is if you can connect it to your computer via USB.)

Then your Eken is working but your LCD panel is not. It might be broken, or it might be a bad connection. I’ve had luck pressing (lightly) around the edges of the screen.

If the red power light stays on but you don’t eventually hear any ‘ding’ startup sound

Then your Eken is probably stuck either loading W-load or u-boot. There are some anecdotal reports that these boards will still take a normal SD card based update, so try some different firmwares via SD card as a first step.

If that doesn’t work then you probably have a brick. The only way from here would be to reflash directly or via JTAG, and noone has found a JTAG pinout on these boards. You can connect the serial port to be 100% sure, but I wouldn’t hold my breath.

EDIT: Ziann123 has posted a comment about unbricking via JTAG. Apparently he has a newer revision board, where the JTAG pinout is broken out and clearly labelled.

I have none of the above

If you have different symptoms, feel free to post in the comments. You’ll probably get better responses by posting on slatedroid, though.

There’s been a lot of fragmented discussion about developing kernels for these SoCs, including a big thread of comments on my previous blog post.

So I’ve decided to create a Google Group to act as a mailing list for people interested in Linux kernel development on these devices: http://groups.google.com/group/vt8500-wm8505-linux-kernel.

This is intended for people interested in hacking on the kernel. If you’re interested in just running Linux on VT/WM netbooks, there is bento-linux and their forums. For tablets, there is slatedroid.com. Both are great communities.

Have started tidying up a Linux kernel for Eken M001 & similar devices (tablets and netbooks), based on the source release that came from VIA last week.

Very, very, early days yet. http://github.com/projectgus/kernel_wm8505.

Not all of the WM8505 functionality is available in source form yet, in particular VIA have chosen not to give us the video source for some reason. So there’s still quite a lot of work before this will be suitable for an Android 2.1/2.2 port. But it’s a very solid start.

EDIT: Source for all drivers is now available except for the SD/MMC driver. I suggest joining the Google Group if you’re interested in this stuff.

(One more Eken post and I’m going to have to rename this blog to Project M001!)

EDIT: Everything here is somewhat out of date now. Jacob Stoner has released a Debian build with X11 & touchscreen support. The links are all posted on the slatedroid forum.

Debian Boots! I wish I had a keyboard!

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.

Default XFCE4 on my M001 tablet

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.

“Derek” posted up a comment yesterday:

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?

See here for my review of the M001.

Eken M001

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:
    Base of Eken
  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:
    Eken part open

    Eken more open

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

Main Board

Main board as installed
(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:
    CPU daughterboard front
    CPU daughterboard back
    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:
    Eken M001 serial port

    The only other interesting thing I saw on the back of the board was the 2Gb NAND flash:
    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.

IMPORTANT EDIT: There is now an Alpha release of Froyo hacked onto the Eken M001. This isn’t the same as full support, but it’s a step in the right direction!

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

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.

Eken on my desk

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.

Eken in the dark

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!):
LEDs

In darkness, the whole thing glows:
Glowing M001

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.