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 great, I hadnt even gotten to looking into this yet. This saves me tons of time. I did find a few wondermedia related items in the framework related to wondermedia protect, other then that I havent found much difference between aosp and the eken framework.
Glad it helped you out. I left a post on your slatedroid firmware thread about how I’d go about reverse-engineering the libwmt patches using objdump. Good luck, remember to share anything you find (N heads are better than 1.)
Good work!
But one question, what do you do if you damage your kernel or bootloader, do you have a possibility to flash it again?
As you said, you don’t have JTAG ore something like this…
I woulden’t try it because I have only one device;-)
Andreas
andreas,
A bad flash of the kernel is recoverable. However, AFAIK, if the u-boot bootloader flash partition or the w-boot (I think it is) “pre-bootloader” goes bad then I think you’ve got a brick.
The boot process in a nutshell is that, each boot, u-boot runs a short script that looks for an alternative “upgrade” uboot script in the SD card and then either runs that or boots from the kernel partition.
The default upgrade script will re-flash u-boot each time, even though it has never changed (it’s another binary patched component.) If you look on the slatedroid forums, someone has posted a “safer” modified upgrade script that skips the u-boot reflash. If you’re running that upgrade script then you should be safe from bricking, because u-boot is never being reflashed.
Enjoy,
- Angus
[...] their patches to the 'Android base' libraries in order to make 2.1 porting easy. Here's why: http://projectgus.com/2010/06/notes-…-to-eken-m001/ (link was on forum before but got lost during the last outage.) I thought this would be part of a [...]
Thank you for the answer, maybe I will try it if I have time.
I hope Eken publish her paches, but I think the don’t…
Andreas
Hi, i bought an Android Tablet from China. it’s from a company called Maixin. model MX007. i was tinkering with it and went to “restore factory settings” i went ahead with it and the Android reset. Then this calibrate touch screen came up. i followed the “+” sign. but after that, it said “touch screen calibration failure”. so from then on, the touchscreen no longer responds. Nothing happens when i touch the screen. by the way, the apps vanished. like the calculator and other stuff, they’re all gone. Is there a way i can get it back to the condition when i got it? or did i wreck it already and now it’s paperweight? hope someone can help. thanks.
Hey i have an Eken M001 as well, Just a heads up if you filter through youtube you will find videos and links on getting the upgraded firmware and getting the tablet rooted. I assume you already know about rooting the tablet…anyways if you find the firmware update you may look into how the “sript.zip” file is compiled, hopefully you can go brute force and replace files within it to upgrade the os… Its a stretch but i have the same end goal as you buddy. I want froyo! lol i hear android is working on a design overhaul lately, hope the eken can take advantage of those…
please keep us posted!
thanks again for your work.
@ulysses: Sorry, I don’t know anything about MX007. If you can reflash it from the SD card by loading a firmware upgrade there and rebooting, you might get it back to the “as new” specs. That would work with the M001. Good luck.
@Yev: Thanks. Slatedroid.com has a lot of this information too, hidden away. I have a physical serial console hooked up to my Eken now, so I have the bootloader output and also always have a root console, as described in the post. I’ve also experimented with replacing files in script.zip, inside the filesystem tarballs (as described above) but this will only work for modifying Android 1.6, not for 2.1 (as described above, also.)
Oh i see, thanks for the clarification., so updating android 1.6 only updates parts of it and doesnt upgrade the actual version…ok great that was a let down. I guess i will just get the firmware upgraded and keep the 1.6 for reading books. This thing is a pain to use sometimes especially loading large ebooks (1,000 pages+) and i got to keep it plugged in if its idle or else the battery dies that is ridiculous especially because the thing tells you what takes up the most battery recourses and that is the LCD! oh well, good luck with everything. Nice review also.
Hello.I am interesting in create a “dust donut” : using the froyo’s jit on our eken’s donut ,but my first test the system doesnt work.(and infinite loop on startup)
It seems the new libdvm.so needs some donut’s files not included on eken
I tried use the Galaxo 1.6.3.3 as base because it seems works with new jit (also 2.2 version),and adding libs from eken but system doesnt load.
Would you able to run the system with the iphone androids files and the eken libs you comment on this post?
i have created an script for upgrading without flash the system which i use for testing.When i have a problem,uncoment two lines,load from sd and the system again works :p
here i upload:
http://www.megaupload.com/?d=UT0MGQUK
///////////////
HERE SOMO LIKS ABOUT :DUST DONUTS
http://www.drakaz.com/FILES/GALAXY/
http://www.drakaz.com/forum/viewtopic.php?id=207
http://www.htcmania.com/showthread.php?t=98366
http://www.absolutelyandroid.com/juice-up-your-android-phone-with-dusted-donuts/
Hi dani,
Seems like an interesting experiment. The last link you posted said this relies on phones with most of the Eclair (2.x) components already loaded, so presumably you need more than just “libdvm.so”
You should be able to find out what other libraries libdvm.so links against by using ‘nm’ or ‘strings’ (strings is available in the Eken’s default firmware.) It’s likely there are other non-library files the JIT needs, and/or you need to clear the dalvik-cache directory as well.
I’ve been really busy lately but I might have a try and see what I can come up with. Try posting on slatedroid as well, people there will be interested in this.
- Angus
Hi again.Yes i tried to load other donut as you did with iphone version,i tried with galaxo because where i read it worked the test where done on this fimware but it doesnt worked (a loop boot :( )
I will post on slatedroid,last time i conected it was not available.
I hope also have time for testing.
dani
Hi again.I have done some test,but i think maybe it is something related with kernel (in a post i read about the kernel ready for eclair)
That’s a shame. :(. Hopefully we’ll make it to a full Froyo built from source on the M001, and then these hacks won’t be necessary. :)
I have a eken m001 1.6 android and i tried to download ecotox firmware and i did everything right and it went to the boot screen when i turned it on . Then i waited like an hour and it wasnt doin anything until it went dead . and now when i turned the the power on the red light turns on but the screen is black an it wont load and reset doesnt work either .How do I fix this Problem ?
nick – Please don’t comment on blog posts that have nothing to do with your question. See here instead: http://projectgus.com/2010/08/unbricking-wm8505-based-tablets/
so the conclusion is?
The eclair or froyo can installed on m001 or not?
If it can,please send me email how to installing those OS to my m001.. A lot of thank for you dani..
No, sorry to disappoint.
thanka
[...] Unfortunately, a completely stock Android 1.6 won't work. Here's a vague explanation of why. I'm not sure what the black bar is about, and none of my devices are working at the moment(!!) to [...]