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:
Linux Tiny: this build option/patch set was introduced during 2.6 and results in otherwise mainstream kernels with footprints well under 2MB. Linux Tiny also features other space-saving patches, like SLOB, a space-efficient replacement for the SLAB allocator; tools for tracking memory allocation, counting in-line function use and for comparing function sizes across builds; and kgdb configurations for systems without serial ports (see Resources).
ARM Thumb and MIPS16: embedded CPU architectures like ARM and MIPS offer special execution modes and small word instruction sets that shrink application size by generating and executing smaller code and data. These methods and modes are best employed to shrink user-space code, but in doing so require special mode/size-specific library and system call versions to accommodate 8/16-bit instructions and operands where standard implementations expect a full 32 bits. More recently, silicon suppliers and maintainers of appropriate architecture trees of the Linux kernel have begun building and maintaining special versions of their trees to accommodate these hyper-efficient execution modes. Even if mainstream kernel builds do support such execution modes, such support will likely be all or nothing, making it difficult or impossible to support mixed mode systems and integration of prebuilt (binary) third-party code. To learn more about ARM Thumb or MIPS16, see Resources.
XIP—Execute in Place: if you have truly parsimonious RAM requirements and can spare a little Flash (and perhaps more performance), you can configure the Linux kernel and/or individual applications to run directly out of Flash. Instead of copying compressed images from NOR Flash (or other types of ROM), there exist several schemes to support execution of uncompressed program images directly in place (XIP). Note that because Flash access cycles are usually slower than those for DRAM, XIP programs can run much more slowly than with RAM-based execution; although, kernel XIP can be used to speed up boot time by removing the need to copy and decompress the kernel image to RAM. To learn more about about User Space XIP with CramFS and on raw NOR Flash kernel XIP, see Resources.