Mobile Phones: the Embedded Linux Challenge

Motorola has been building radio sets for nearly a century. They and other handset manufacturers like NEC, Nokia and Panasonic leverage their hard-won RF know-how to build their popular phone product lines. New entrants and also new designs from existing suppliers, however, must overcome a range of designs challenges before they can build handsets that meet the requirements of carriers, operators and regulators, and do so cost effectively.

In today's crop of Linux-based smart phones, the GPRS interface resides in an encapsulated “modem” device that can contain an additional CPU core, a DSP and RF hardware to support wireless communications. It really behaves like a modem—many smart phones communicate with these embedded processors via AT modem commands over a dedicated serial port. Offloading the radio function makes it easier to build a smart phone, but it impacts costs by adding components to an already heavy BOM.

Some experimental designs today remove the modem and expose the baseband interface to the application OS (as with Nucleus in mid- and low-tier phones), but doing so exposes Linux to hard real-time requirements that stretch beyond the limits of recent advances in Linux real-time (preemption and open-source real time—see below). GSM and also CDMA wireless protocols predicate signal frame times in the 800–900 microsecond range. For x86/IA-32 and PowerPC processors with 500MHz–1.5GHz CPU clocks, submillisecond worst-case response is now commonplace, but with clock-scaled ARM processors running at 0–200MHz, hard real-time interrupt response and preemption are still marginal.

A separate challenge arises from the use of legacy telephony stacks ported “as is” to Linux. This software was written and optimized for legacy phone OSes like Nucleus and REX. These proprietary multilayer stacks were implemented with unique thread contexts for each layer, and when ported to Linux can exhibit 20–30 microsecond context switch latencies layer to layer. As such, just traversing the stack with a single packet can consume a large portion of available compute time, leaving few CPU cycles for other tasks.

If Linux is going to participate in cost-down mid- and low-tier phone designs, it will need both more spritely context switching and/or optimized and open native ports of key GPRS and CDMA protocol implementations.

During the past five years, Linux has progressed toward offering significant native real-time responsiveness. Today, Linux is replete with native real-time options, including capabilities like the preemptible kernel, O(1) scheduler, FUTEXes and the recent Open Source Real-Time Linux Project (now merged into preemption patches maintained by Ingo Molnar—see the on-line Resources). There also exist dual kernel and virtualization technologies like RTLinux, RTAI, Adeos and proprietary Jaluna OSware that offer RTOS-like responsiveness by virtue of embedding an actual RTOS into the Linux stack.

OSDL MLI members and others in the community would prefer to see native Linux solutions do real-time response. For exposed RF interfaces, and time-sensitive and QoS capabilities like multimedia and voice processing, the consensus is that Linux needs continual nudging in the direction of native RTOS-like responsiveness. In mobile designs, Linux must meet deadlines and switch context with agility in systems whose clocks can scale erratically to conserve battery power, jumping from 200MHz peak performance down to 40MHz (or even 0MHz) and back in response to system policies and peripheral inputs.

Today's smart phones can ship with 128MB of Flash and 64MB of RAM. However, a phone OS need not seek to occupy every last byte of available storage. Every byte used by the OS and middleware is a byte not available to OEMs for value-added content. On the plus side, embedded Linux can theoretically deploy in a footprint of 1MB or less; real phone configurations are much larger.

Embedded developers, platform providers and maintainers of the Linux kernel itself provide a range of configurations and tools to shrink the platform footprint: