Mobile Phones: the Embedded Linux Challenge

Although delivering Linux-based smart phones is no mean feat, it is still easier and more viable than putting the open-source OS on lower-tier phones. Why? Because smart phones, with higher prices and more ample margins, have more room in the BOM (Bill of Materials)—room for hardware dedicated to key phone functions (multimedia, display control, baseband RF and so on) and for software to enable that hardware. Often the application OS (Linux, WindowsMobile and so on) runs on a dedicated application processor, with additional CPU and DSP cores handling voice, multimedia and RF functions. Smart phone buyers are also typically early adopters, eager for the latest technology and more tolerant of some marginal behaviors, especially of shorter battery life in technology-rich devices.

Smart phones, however, represent only about 6% of the total phone market. If the Linux industry and developer communities want truly ubiquitous phone-based deployment, a Linux phone platform also must be able to support the technical and economic requirements of the broader middle-tier or feature phone space. These handsets don't sport all the technical goodies of smart phones, and the underlying hardware doesn't come with all the support hardware either. A cost-down BOM means that Linux on the application CPU is directly exposed to the vagaries of software support for voice, data, RF and graphics. Place that burden on a single CPU running between 0–200MHz as needed for energy management, in a much more modest memory footprint, and Linux can't make the middle-tier cut.

Social projects aimed at bridging the digital divide also envision open-source phones for low-income populations in developing countries (think tiny Ubuntu). But just as the $100 desktop is proving elusive, so likely will the free Linux-based cell phone.

Over time, the specs for middle- and even low-tier phones might rise to meet Linux base capabilities, but margins also get much thinner on these same devices. Battery technology is not improving at an appreciable rate, meaning that applications can't make up the difference with faster clocks either. So, if Linux is going to break out of the smart phone trap, it must acquire a series of new capabilities and enhance and unify many existing ones to meet the challenge.

OSDL kicked off a new initiative (see the OSDL MLI sidebar) to foster Linux adoption on mobile telephony handsets. As its first order of business, MLI is cataloging gaps and requirements to make Linux a more apt phone platform OS. The following list and discussion is representative of input from MLI participants and other interested parties, especially handset manufacturers and phone silicon suppliers.

Today, if a portable device manufacturer wants to offer a Linux-based and power-managed device, he or she faces a boggling choice among variously divergent paradigms (Table 2).

OEMs can look to the desktop where notebook-centric schemes like ACPI and APM dominate, and indeed occupy most discussions of Linux power management on the kernel mailing list. For non-x86/IA-32 notebook hardware, OEMs can turn to PMU for Apple PowerPC hardware. Embedded OEMs deploying ARM-licensed silicon can leverage the ARM Ltd. IEM framework, or work with the various power management schemes present on silicon from dozens of ARM licensees (FreeScale, Intel, NEC, Samsung, TI and others). There also exist unique and further divergent energy conservation protocols from MIPS and MIPS licensees, from FreeScale for its CPU lines, from IBM for Power Architecture, from Renesas and Hitachi, and so on across the silicon supplier universe. OEMs also can choose schemes like MontaVista's DPM and other embedded Linux supplier solutions.

Although choice is a good thing, too much choice can lead to fragmentation. In response to this power management smorgasbord, members of OSDL MLI and other embedded industry consortia have expressed a desire to see either a unified cross-processor power and energy management scheme, or a mainstream high-level “umbrella” that covers embedded, desktop and even blade-based thermal management.