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.

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.

This year a slew of companies have launched competing Android tablet devices. A lot of rhetoric has been spun about how Android’s open source ecosystem gives manufacturers and consumers an advantage.

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.

Manufacturer Based In Tablets GPL Compliant Sources Available
Apad China 1+ No No
Archos France 2 Yes (see caveats below) Yes
Barnes & Noble United States 1 Yes Yes
Eken Group China 4+ No Partial
(see below)
Gome China 1 No Partial
(see below)
Moonse China 1+ No No
Pandigital United States 1 No (may change) ?
Smart Devices China 5 No Community

EDIT 2/9: Benmars posted in the comments that Archos have now released GPL source code for the Archos 7 Home Tablet. This looks to be a full kernel source release for the Rockchip RK28xx SoC, and even includes includes a prebuilt linux-x86 cross-compiler toolchain. Thank you Archos!

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!

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.