Mobile Phones: the Embedded Linux Challenge

There are myriad methods, tips and tricks for reducing the user-space memory burden. These include using uClibc instead of glibc as a standard library, deploying BusyBox and TinyLogin instead of standard shells and multiple utilities, and using compressed filesystems like CramFS and YAFFS.

Phone manufacturers, however innovative they wish to be, cannot simply build the phone of your dreams—or of theirs. Rather, they must respond to the expansive and exacting requirements presented to them by their customers, the mobile carriers and operators (think Cingular, Vodaphone and others), predicated by the networks those companies build and maintain, which are highly regulated by national governments and even some international bodies. These requirements come in the form of phonebook-sized tomes, comprising 5,000 or more distinct specifications, and many of these specs are themselves highly complex and multifaceted.

Governments, especially the US Government, jealously guard their control of the electromagnetic spectrum. The US Federal Communications Commission (FCC) auctions and doles out grants of radio spectrum use and has very particular ideas about bandwidth, signal strength, security and as we've (re)learned in the last six years, about content on the “public” airways. Other governments and regulatory bodies around the world are similarly disposed toward open and free uses of radio frequencies. Devices that do not conform to these (overlapping) regulations and do not pass regulatory muster (homologation) do not earn approval and are not licensed for sale. Violations carry nasty fines and even criminal penalties.

Mobile carriers and operators, in response to these regulatory regimens, are understandably reluctant to experiment with open device architectures. Ditto for their suppliers, at least on the “thin” end of the wire (carrier-grade Linux and other implementations are today powering a growing share of wireless infrastructure). Carriers and operators are not completely averse to openness, but tend to think only in terms of secure delivery of value-added services. By establishing careful sandbox environments and limiting API sets on the technical end, and by even more careful political negotiations, the chain of manufacturing, deployment and regulation have begun to crack the lid on otherwise closed handsets. As such, mobile phone users and market watchers have seen a handful of “can openers” emerge during the last five years, principally Mid-P Java and BREW, with mixed results, especially in performance. More recently, a slew of native applications has emerged for phones based on SymbianOS and on Windows Mobile 5.0.

Linux-based phones offer up the promise of further prying open the clamshell by leveraging the OS to provide a secure application programming environment (in user space); it also comes with a well-established community of skilled developers. Whether Linux-based handsets will be truly open platforms, remains an open question. Phone deployed so far, although based on a Linux kernel and many familiar OSS components (like versions of Qt), are by no means open devices. Hackers cannot (easily or at all) rebuild the kernel, OS and application components, or even add functionality to the stack. These devices are not designed to accept logins, let alone reflashing. The “can opener” for these Linux-based mobile devices, like those based on proprietary OSes, is Java, even if you can download source code for the OS and portions of the application stack.

There do exist after-market resources to support hacking Linux-based phones. One such project is Harald Welte's Open-EZX (see Resources). This project, still in its early stages, strives to build a 100% open phone stack for Motorola mobile phones like the A780 and e680. The project's wiki is replete with warnings about rendering your phone unbootable and losing regulatory approval, but also with useful information on how to get a shell and how to cross compile for these devices (they're based on Intel XScale Architecture PXA processors).

Motorola's chief phone architect definitively disavowed support for such efforts. Why? Principally, liability issues stemming from its customers' concerns for the integrity and security of their mobile networks and the complex burden of supporting millions of devices with potentially divergent versions of the Open-EZX software stack. Then why call it Open-EZX? Because device OEMs like Motorola do want to encourage the evolution of developer communities around their devices and platforms. They just need to foster that evolution in a way that is amenable to carrier, operator and regulatory sensibilities. Today, that means offering SDKs to hand-picked ISVs.

Hopefully soon, through educational efforts and persistence, this very conservative and careful audience of network operators and government regulators will be more comfortable with mobile phones as computing platforms, not mere mono-function radio devices.