Mobile Phones: the Embedded Linux Challenge

An overview of the suitablilty, viability and liability of Linux on mobile phones.
The Smart Phone Trap

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.

Technical Challenges

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.

Power Management

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).

Table 2. Available Power Management Schemes

APM—Advanced Power ManagementThe most widespread technology for Linux, but not 100% compatible with more ubiquitous ACPI.
ACPI—Advanced Configuration and Power InterfaceThe most ubiquitous x86/IA-32 notebook power management scheme (backed by Intel, Toshiba and Microsoft). Very BIOS-dependent.
PMU—Macintosh PowerBook Power Management UnitPower management scheme very specific to G3/G4 PowerPC systems from Apple.
LongrunMostly transparent hardware-based power management specific to Transmeta Crusoe.
DPM—Dynamic Power ManagementMontaVista Software framework for driving ARM (especially TI OMAP and Intel XScale) CPU clocks and operating voltages among “operating points” in response to policy and system events.
IEM—ARM Intelligent Engery ManagementARM Ltd. Power management scheme for ARM core licensees with dynamic voltage and frequency scaling (compatible with but different from DPM).

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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

LG enV Touch is very similar

Anonymous's picture

LG enV Touch is very similar to the enV 3 but with two large screens – one connected to the touch screen and the other connected to a full QWERTY keyboard.
online tv


Anonymous's picture

The article suggests that YAFFS is compressed. This is not true.

YAFFS is not compressed

Anonymous's picture

The article suggests that YAFFS is compressed. This is not true.

YAFFS is not compressed

Anonymous's picture

The article suggests that YAFFS is compressed. This is not true.