Hacking HTC’s Windows CE phones with Linux — a progress report
Dec 31, 2005 — by LinuxDevices Staff — from the LinuxDevices Archive — 50 views
There is a curious lack in the Linux community — the number of community-led Linux distributions for commodity mobile phone hardware is zero. There are PDAs for which you can get a GSM/GPRS SD card; there are mobile phones, such as the Motorola A780, that are
As reported two years ago by LinuxDevices.com, the aim of the Xanadux project is to change that, and this article describes how it's getting on. The devices are the secretive High Tech Computer Corporation's (HTC's) “Designed for Windows CE” PDA phones, which have several codenames — Wallaby, Himalaya, Blue Angel, Universal, and Magician, to name most of them. They are known by several names — O2 calls them XDAs, T-Mobile calls them MDAs, and they also go by brand names such as iMate's JasJar.
The Wallaby, Himalaya, and Blue Angel are sufficiently similar that they share chips and code. The Universal (aka the XDA Executive and the iMate JasJar) is, however, a sufficient departure, not least because it is a 3G device, to make running Linux usefully on it a tantalizing prospect at some time within the next couple of years.
Why Linux?
The question has to be asked, though: why on earth would anyone want to “own” their own mobile phone — and by “own” I mean put up with an unpolished and clunky user interface that is designed for PDAs and not for mobile phone usage?
The reasoning goes like this. With Windows CE devices, if there's a problem, you are stuck and there's nothing you can do about it. Unless you're very rich, you've just spent a significant amount of money on a phone that will irritate you for the rest of your phone contract.
For example, on the Blue Angel device (pictured at right), if you have it in your pocket, there are buttons on the front for email, Internet, Windows Menu, and an “OK” button. The profile of these buttons is such that they stick out just enough to easily be pressed without your knowledge, thereby connecting you to the Internet and charging you GPRS connection fees for the privilege.
Got Linux? Don't like that happening? Go get the source code, add in a dialog box that asks on the touch-screen, “do you really really want to connect to an expensive GPRS network?”
You're not a programmer? Contact one of the developers via the xda-developers.com web site, and commission someone to add the required code for you. Is there any chance that something like this could be done for you by Microsoft? Absolutely none!
Got really important sensitive data on your PDA? Want a better password on your PDA/phone, or an encrypted filesystem, under Windows CE? Tough luck! Want a VoIP phone that transfers over to GSM/GPRS/3G when you go out of wireless range? You'll be very, very lucky.
Getting viruses targeted at your mobile? How do you stop them? Under Windows CE, you can't. You're totally dependent on your airtime provider or your Windows CE OS provider to stop viruses, neither of which is going to be particularly effective or interested in helping you. They're already making money off of you, and you're not going to stop using their services, so, why should they care?
The alternative? Run Linux on your phone, install clamav and spamassassin. Download the virus updates over wireless to save yourself money; plus, you're running an OS that can't possibly run Windows CE viruses. By being different, you avoid the problem, just like you do with a Mac or with Linux on your desktop.
Getting fed up with nuisance phone calls and unwanted SMS messages? Write yourself a program that reacts to the caller-id, and if it's an unwanted caller, answers the phone on your behalf (to make them accept the call charges and cost them money) and plays a recorded message at them. Better yet, treat SMS messages just like email, and put them through spamassassin before they get to you.
Does your phone receive MMS spam? Did you know that when an MMS message arrives, it's actually a hyperlink that causes your phone to connect over GPRS or 3G? So, not only are you at risk of having viruses and spyware installed on your Windows CE mobile, but you are also made to pay for the privilege.
In other words, with Linux running on your mobile device, you have options outside of the box that don't fit the mass market, and that avoid the wars and battles going on between manufacturers and GSM providers as they limit your choices in order to get as much money out of you as they can. (Did you honestly think VoIP hadn't been added years ago to mobile phones for purely technical reasons?)
Help is on the way
Over two years ago, the xda-developers.com web site was set up to coordinate an effort to run Linux on HTC's devices. Since then, the site has morphed into an informational resource center in general. The site is primarily focused on topics such as: how to unlock your phone; how to put your own software onto the device; how to upgrade it to Windows CE 5.0.
Behind the scenes, though, several intrepid developers come and go — some running Microsoft Windows CE development tools on Windows; some running Microsoft's ARM cross-compiler on Linux using WINE (the Windows emulator); others working on device drivers and analyzing Windows CE; still others running the OpenEmbedded.org toolchain to compile up GPE/Familiar to run on the phones as an embedded Linux OS.
Perhaps not surprisingly, the developers who are interested in HTC phones are almost exclusively European — particularly from the UK, Holland, and Germany. Given that the HTC devices focus on the GSM and 3G (WCDMA/UMTS) markets, it's unlikely that these brilliant products will even be sold in the US or the Far East.
Some of these developers, from a Windows background, are just curious and enthusiastic, want to learn Linux, and for some reason figure that a really hard-core project like Xanadux is as good a place as any to start. Others are die-hard geeks who dislike Windows CE enough that they are prepared to go borderline insane, head-butting their keyboard and nearby walls, just to make it go away.
Xanadux has had a number of its contributors run away screaming and never come back. Reverse-engineering sounds appealing and cool, but it is very demanding. Eight 80-hour weeks of concentrated attention can result in twenty lines of code being written that successfully switch on an LCD screen; another four weeks, and the charger is being successfully switched on when the device is plugged in to the USB.
Blue Angel Linux port takes form
It's a small wonder, then, that finally, after two years and contributions from several enthusiasts, at least one of HTC's mobile phone devices — the Blue Angel — can actually make and receive phone calls, even if things are still a bit rough-and-ready.
How has this come about, and why is it so problematic?
Well, here's an example…
HTC has had to produce its own ASICs. Its devices are based on Intel XScale PXA250 (and recently PXA270) series ARM processors, and there aren't enough I/O pins on those processors to control all the required peripherals. So, HTC produced its own custom chip (which has been nicknamed the “ASIC3,” due to lack of any other information). The ASIC3 chip, apart from multiplexing more I/O (for example, you can either have Bluetooth or IrDA, but not both), has an SD (Secure Digital) card interface for accessing flash memory cards and other SD devices.
Absolutely no information on how the ASIC3 chip works has been made publicly available by HTC. However, the ASIC3 chip has found its way into Compaq iPAQs, such as the Hx4700, and information has been more forthcoming from HP — sufficient to produce a reliable driver for Linux, including the ability to control SD cards. Adapting the ASIC3 and SD card Linux driver to the HTC Himalaya and Blue Angel devices has then turned out to be a relatively straightforward task.
It's still not all roses. For example, only recently has the sound chip for the Himalaya been identified, from close-up photographs, as a Philips UDA 1380. Fortunately, this is exactly the same chip used on the Blue Angel, which is already working successfully. Wireless on the Blue Angel requires firmware to be uploaded; the M-Systems DiskOnChip flash chips are 32 MB capacity, which is not supported by the Linux DiskOnChip Millennium Plus drivers (only 16 MB is supported); on the Blue Angel Revision 6 devices (for example, the more recent XDA IIs PDA phones from O2), the LCD screen is still not reinitialized correctly when the phone is woken up; although the Bluetooth drivers work, it's still not known how to connect GSM phone calls to Bluetooth; GPRS, however, does actually work, but because the GPE/Familiar distribution is for PDAs, it doesn't really have support for GPRS, so you have to know what Linux voodoo incantation to use to make it connect.
Yet despite these niggles, a significant amount of progress has been made already — definitely enough for an experienced Linux hacker or enthusiast to tolerate its foibles and run Linux successfully on the Himalaya, and even better on the Blue Angel devices, though definitely not well enough yet to run your business off of it. Yet.
Some links of interest…
About the author: Luke Kenneth Casson Leighton describes himself as a serious Linux geek with borderline autistic tendencies who tends to accidentally and amiably drive people nuts. His vocation is to seek out, understand and then explain esoteric and archaic technologies. The Xanadux project is one such example, where he managed two years ago to create the beginnings of an SSP Linux driver for the TI TSC 2200 touchscreen, a framebuffer video driver for the Himalaya, and more recently making the Linux SD card reader driver work. He is also responsible for the network-reverse-engineering on Windows NT Domains protocols, from 1997 to 1999. That Samba can be a Primary Domain Controller, saving businesses world-wide from Microsoft Server licensing fees, is entirely his fault.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.