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).
Table 2. Available Power Management Schemes
|APM—Advanced Power Management||The most widespread technology for Linux, but not 100% compatible with more ubiquitous ACPI.|
|ACPI—Advanced Configuration and Power Interface||The most ubiquitous x86/IA-32 notebook power management scheme (backed by Intel, Toshiba and Microsoft). Very BIOS-dependent.|
|PMU—Macintosh PowerBook Power Management Unit||Power management scheme very specific to G3/G4 PowerPC systems from Apple.|
|Longrun||Mostly transparent hardware-based power management specific to Transmeta Crusoe.|
|DPM—Dynamic Power Management||MontaVista 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 Management||ARM 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.
|PasswordPing Ltd.'s Exposed Password and Credentials API Service||Apr 28, 2017|
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- From vs. to + for Microsoft and Linux
- IGEL Universal Desktop Converter