Mobile Phones: the Embedded Linux Challenge

An overview of the suitablilty, viability and liability of Linux on mobile phones.
Radio Interface

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.

Real Time

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.

Small Footprint

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.

______________________

Comments

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

kirazoyun

Anonymous's picture

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

www.kirazoyun.net

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.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState