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.
Telstra have issued a PR statement about their GPL compliance. The statement is a promising sign, but I’m afraid it is somewhat misguided.
Update 9/11: Today Netgem have posted a new version of their GPL source, labelled “T-Box”. I’ve also been contacted personally today by a Telstra representative about the T-Hub product. Both things are excellent to see, Telstra do appear to be taking this very seriously. Will post any more developments as they occur.
However, now I know. If you want an answer from a massive multi-billion dollar company like Telstra, you don’t waste your time with customer service. You carefully research and publish a blog post shaming them, then hope that the tech media will pick it up and bring it to their attention.
The follow up was so awesome that this afternoon Telstra released a PR statement. To my knowledge they haven’t released it publicly, and they didn’t send it to me (*sadface*), so I can only quote from Delimiter:
â€œWeâ€™re currently talking with our T-Hub vendor to work out whether software used in the product is subject to [the] General Public License (GPL),â€ said the company. â€œShould we find a lack of compliance, we promise to work with our supplier to correct it.â€
This is excellent. I think it’s commendable that Telstra have reacted to this, and I eagerly await news of further progress.
Clearly, I would have rather that they (a) checked well before they launched the product back in April, and (b) had an effective customer service system so I could have gotten this answer when I first tried to contact them privately about it. However, nonetheless, it’s excellent news.
Telstra also weighed in on their T-Box, a set-top box & IPTV product which is manufactured by Netgem but branded and sold by Telstra:
â€œT-Box owners can find licensing information about the open source software incorporated into their device by visiting the settings menu,â€ Telstra said. â€œThe source code for the open source material is available from our vendorâ€™s website and we believe all GPL code is identified and is available to customers.â€
To verify this, I detoured home from work via my local Telstra Shop and took a look at the demo model. Sure enough, you can select Menu -> Settings -> Information -> Licensing & Copyright.
Apologies for my crummy photos:
Here are the two sections that appear relevant to GPL (my transcription):
FFMPEG License LGPL: Detailed licensing information is available at http://www.gnu.org/licenses/gpl.html.
GPL License: libstdc++ (GPL with run-time exception), dhcpd, iptables, pppoe, madwifi, wpa-supplicant, iwtools, busybox, dosfs tools, e2fs tools, insmod, drivers i2c (partially), USB Sigma.
Detailed licensing information is available at
I’m not a lawyer, but this doesn’t look like GPL compliance to me.
In order for this section to constitute GPL compliance, I think it would need at least three things:
Actual source code included with the product, or alternatively
“a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code”
The full text of the License, as per GPL Sections 1 & 2, rather than a plain URL.
In fact, all three of these errors are listed as common mistakes in GPL-Violations’ excellent Vendor FAQ, which I linked to yesterday.
“available from our vendor’s website”
OK, so nothing indicates yet that the T-Box is technically compliant. Maybe Telstra & Netgem have still made an effort at compliance. Let’s check out the assertion that “source code for the open source material is available from our vendorâ€™s website”.
Update 9/11: Today Netgem have posted a new version of their GPL source, labelled “T-Box”. This is excellent to see.
Netgem does have a GPL download page. Unfortunately, it doesn’t actually mention T-Box anywhere. The product on that page is a “Netgem HD”. Are they the same?
I searched Netgem’s site for T-Box, but all I could find were press releases. I searched Telstra’s web site for Netgem, and all I found was a comment written by a customer suggesting a T-Box is a “Netgem 8000”. Not sure how that relates to the “Netgem HD” source, or even if it is true that the two products are 100% identical.
Adding insult to injury, the latest firmware download on Netgem’s site is v5.1.08 (January 2009), and users are reporting T-Box versions like 188.8.131.52 (03-Aug-2010). As my favourite Vendor FAQ reminds us, “The source code has to be 1:1 corresponding to the executable (object) code actually shipped.”
I also looked in the T-Box User Guide, which is available via download from Telstra.
The user guide contains no reference to the “License & Copyright” section that is available in the user interface. It does, however, contain a “Legal Notification” section. This section has completely different text, and no open source mentions. Ironically, it does contain the following passage:
In using your T-Box, you must not violate any intellectual property rights concerning a brand, design, photo, licence, software program, audiovisual work or any other form of intellectual property.
Any violation of these intellectual property rights and, in particular, any act of piracy, will be subject to the penalty applicable within the legislation put in place.
Hmm, yes. OK then.
Conclusions on T-Box
Without physical access to a T-Box it is not possible to say conclusively if it violates GPL. However, I think I can safely say that Telstra’s PR statement is completely misguided if it means to imply that this meager offering constitutes GPL compliance.
From what I have seen, I believe that Telstra and/or Netgem should immediately take the following steps:
Amend the “License & Copyright” section of the product so it contains GPL compliant text. For examples of how to do this, look at any Android mobile phone and also read the wonderful Vendor FAQ.
Amend the User Guide “Legal Notice” so it contains the same text as the “License & Copyright” section, removing ambiguity.
Provide source code under the name “T-Box”, rather than under an obscure OEM name not associated with the product in any way.
Provide source code that is up to date with the currently released firmware version.
By the way, if anyone from Telstra would like to talk to me about this, my email address is gus at this domain name. Although you already have my name, phone numbers (twice), email address (twice) and home address somewhere in your databases – courtesy of my attempts to contact you via customer service channels.
I’ve been investigating Telstra’s T-Hub “home phone of the future”. The T-Hub is built with open source software, but Telstra do not seem to be honouring any of their legal copyright or licensing obligations.
(For the non-Aussies: Telstra is Australia’s largest telecommunications company, and is part government owned.)
I investigated the T-Hub and found it is built on a variety of open source software, including GPL licensed software like Linux and busybox. However, Telstra are not mentioning this anywhere and are not distributing source code, or notices to obtain source code.
By doing this, Telstra are violating the licenses and also robbing the authors of their rightful attribution. They appear to be regarding open source as a free-for-all that they can exploit without giving back even the small amount required legally by the various license terms.
However, I believe that Telstra can easily take steps to comply with these licenses.
Telstra have a range of other Linux-based products, including the T-Box and a soon-to-be-released “T-Tab” Android tablet. To the best of my knowledge the T-Box is not GPL compliant either, which gives me little hope for the upcoming T-Tab.
What is a T-Hub?
T-Hub is Telstra’s “home phone of the future”. It’s essentially a tablet-like device (think Chumby with less functionality) loosely integrated with a cordless land-line telephone. The OEM product is from Sagem, although as far as I know Telstra is the only vendor world-wide.
The GNU General Public License is an open source “copyleft” license. Vendors are encouraged to freely distribute products built with GPL software, provided that they acknowledge the license and also provide access to the source code (modified or not) for the GPL licensed or derived portions.
A while ago I learned that the T-Hub runs Linux, which is subject to GPL.
Attempting to make contact
For over two weeks I’ve been attempting to find someone at Telstra to talk to about this. Despite best efforts (phone calls, emails), I have been unable to contact anyone with the slightest idea what I am talking about, or with the ability (it would seem) to actually find someone who knows what I am talking about.
Best quote so far, when I was transferred to tech support: “Look mate, noone calls up Microsoft and asks for their source code…” Um, sure.
Finding out myself
Frustrated, I bought an “as-new” T-Hub on ebay. First, I scoured the documentation for any mention of the software license(s):
Next, I found the URL where the device downloads its firmware. The current firmware can be downloaded directly here. The file is a JFFS2 filesystem image, which can be mounted via mtdram as described here (EDIT: you can skip the jffs2dump step if you’re on a little-endian machine like a PC.)
By browsing the filesystem of the device, I can see a range of GPL or LGPL licensed software contained within. Here is a (possibly incomplete) list. The following components are GPLv2 licensed:
Linux kernel v184.108.40.206
GNU Fdisk v2.12
The device appears to be built around a Freescale i.MX31 SoC, which means that it probably also contains a GPL licensed bootloader (u-boot or RedBoot.) I haven’t taken any steps to verify the bootloader, though.
There are also LGPL licensed libraries:
GNU C Library
The following included open source software is not GPL licensed but has a license that requires acknowledgement that it is included in the product. These notices do not appear to be included, either.
What should Telstra do?
GPL compliance is not that hard. GPL-Violations provides an excellent (and simple) vendor FAQ explaining a vendor’s obligations under GPL.
Telstra should review their use of open source in all their products, and amend their ways so they are legally compliant.
For the T-Hub, this includes adding GPL and other license and copyright notices to the product documentation, adding offers for source (or actual source code) for the GPL licensed components, and also making sure that “the tools required to compile and install the GPL licensed components” are made available.
Aside from the time this will take, I don’t see how GPL compliance could negatively impact the T-Hub product in any way. In fact, it may even provide a new market by allowing intrepid users to load different software onto the T-Hub. Of course, this is beside the point – the license terms are clear, and by choosing to use these software products Telstra must commit to honouring their license agreements.
There are a few kneejerk responses that always seem to appear in these cases, so I’m going to address them in advance:
“The source code wasn’t modified, so there was no need to comply…”
This is a misconception about GPL. The source code doesn’t need to be modified as a prerequisite for compliance.
However, the vendor doesn’t always need to distribute the source themselves. Under GPLv2 clause 3(c), they can simply redistribute an “offer to distribute corresponding source code” that they themselves received from a third party along with the binary code, provided that the vendor did not modify the source themselves.
EDIT 8/11: Glen points out in the comments that clause 3c only applies to non-commercial distribution, so it seems Telstra can’t copy someone else’s notice – they’d need to provide their own offer for source (3b) or put the source code in the box somehow (3a).
“Sagem made the device, not Telstra. They are responsible for compliance.”
It is true that Sagem made the device. However, Telstra are the legal entity who are distributing (ie selling) it. The customer’s relationship is with Telstra, not Sagem. Whatever private arrangement exists between Telstra & Sagem is not our business.
Of course, in practice, it is Sagem who will probably be responsible for providing source code and documentation in order to allow Telstra to comply. At the moment I think there are two possibilities: one is that Sagem provided enough information to ensure their compliance, and Telstra ignored that information. The second is that Sagem did not provide enough information, and are themselves in violation of the license. However, as I said before, this is Telstra’s business with Sagem, not my business or the business of any of Telstra’s customers.
“This is why I don’t trust GPL… blah blah… open source zealots… blah blah…”
This one always baffles me. Via GPL/LGPL a company can get access to a complete world-class operating system with libraries for almost any conceivable use. They get this at no monetary cost, without needing to negotiate any license agreements or pay a cent to anyone. Better yet, all of the software comes under a single license so the legal department only needs to read and understand one or two documents. The company is then welcome, even encouraged, to build end-user software on top of this OS & libraries, bundle it all into their products and sell it at a profit.
The only thing a company is asked to do is acknowledge the open source components, and make source available. That’s the sole cost to a vendor like Telstra, for an entire software ecosystem. I believe the GPL can make no claim on any of Telstra’s original contributions to the T-Hub, such as the custom HTML UI, which are not derivative works of any open source software. None of that source needs to be released, unless Telstra wants to release it. There’s no risk that Telstra will somehow lose any competitive advantage they have in this product, via open source.
Yet it seems to be all too hard. Why is that?
Alternatives to T-Hub
If you want to buy something like a T-Hub (“kitchenputer”), but want a product that respects copyright law, then I recommend checking out Chumby for starters. Chumby Industries are a terrific company when it comes to open source. Internode sell chumbys in Australia (no Chumby One yet, though. :(.)
What am I doing next?
I’m going to notify as many rights-holders as I can find for the software mentioned above, and encourage them to formally contact Telstra.
I’m not sure what I’m going to do personally with my ebay T-Hub. I’m not a Telstra customer, so it’s more or less useless in its current form. So far I haven’t found any way to load custom firmware, without spoofing Telstra’s update web server (although I haven’t taken mine apart to look for a serial console.)
I thought it might make a good Android tablet, but it has a resistive touch screen and it also probably doesn’t have enough physical buttons for a good Android user experience. Plus for the same money I could buy a OMAP3-based Android tablet with a Cortex A8 in it (newer than the ARM11 CPU in the T-Hub.)
So… it’s probably going back on ebay. Unless anyone wants to buy a nearly-new T-Hub? I can’t guarantee the sale will comply with any licenses, though. :D.
These are some quick notes from installing Linux, specifically Ubuntu Netbook Remix 10.10, on the Asus 900AX.
The 900AX is a throwback to the original eee pc 701. Side by side, they look nearly identical – the 900 just has a 9″ screen, different keyboard labels and 2 USB ports (not 3.) There are a few other budget concessions, for example the RAM is apparently soldered directly on the board instead of on a removable DIMM.
This is offset by the fact I picked it up for just $198AU on sale. It boggles my mind that you can walk into a store and buy a fully functioning brand name laptop computer, new with a warranty, for $200.
First build your USB stick. You can either do it the easy way as described by Ubuntu, or mess around with dd if you’re keen (I went for the easy way.) Once the USB stick is inserted, boot up and press F2 to get to the BIOS menu. With the USB stick inserted, there will be a “Hard Disk Drives” menu (under Boot) which will let you choose the USB stick as your boot device of choice.
For some reason the trackpad didn’t work the first time I booted the installer (it worked on subsequent boots.) Apart from that, the Ubuntu Netbook Remix 10.10 installation went smoothly. Until the system froze when restarting after installation.
Appending to /etc/modprobe.d/blacklist.conf
# blacklist other Ralink modules in favour of 3090 DKMS mod
… fixed! Other than that I’ve only noticed two problems:
The brightness hotkeys erratically switch between two brightness settings only, bright & dim. I remember this working properly under Windows in the store, so I’m guessing a driver issue.
The battery gets hot when charging, and the plug pack tip gets extremely hot – I almost burned myself on it after an hour of charging & using! Not sure if that’s a common fault or just mine. EDIT: This seems like it was me not properly inserting the plug. Has been fine since.
EDIT 2: At one point recently the trackpad totally stopped responding to me. After lots of messing around and wasted effort, I fixed it by shutting down, disconnecting power, removing the battery, and waiting for 30 seconds before powering back up.
Everything else seems to work out of the box so far. Nothing at all like the “bad old days” of Linux hardware support.
If I find anything else useful, I’ll append it here.
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.
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.
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 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!
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.
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
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.
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.
Want a quick laugh?
~# modinfo wm9715-api.ko
author: VIA ShenZhen MCE SW Team
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.
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.
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.)
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):
… 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:
… 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.)
There are a few other cheap models with the same chipset, like the M003 (bigger 8″ screen) and a netbook form factor model.
You get what you pay for.
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.
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.)
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.
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.