News Archive (1999-2012) | 2013-current at LinuxGizmos | Current Tech News Portal |    About   

Linux for the handset: a rising force

Aug 15, 2007 — by LinuxDevices Staff — from the LinuxDevices Archive — views

Foreword — This article traces Linux's transformation into one of the most popular mobile phone environments today. It was written by Jim Ready, founder and CTO of MontaVista — and arguably one of the most important pioneers in the market for off-the-shelf commercial embedded operating systems. Enjoy . . . !


Linux for the Handset: A Rising Force

by Jim Ready

Spread the word:
digg this story

Traditionally, the Linux operating system (OS) has been viewed as being too big, too slow, and without the real-time capabilities needed for mobile devices. But as 20 million Linux-based mobile handsets have shipped over the last two years it's difficult to ignore the fact that the Linux OS has quickly taken its place among the top four OS's for high-end “Smartphone” devices.

With its technology lineage coming from running on server-type devices, the success of the Linux OS may be surprising for some to see, especially as some time ago the before mentioned negatives were true. How these limits were overcome is a tribute to the combination of significant commercial efforts in concert with the Linux community and its Open Source foundation.

The following article explores the design approach by handset makers implementing Linux as well as provides an overview of the industry dynamics that have led to the current capabilities of Linux. It will also provide a review of the current Linux technical features suitable for mobile devices.

The Linux Evolution

Based on some positions it's as if Linux transformed itself into a mobile OS untouched by human hands, but the rapid evolution of Linux from its server starting point to one of the top mobile device OS's did happen miraculously. In reality, millions of dollars have been invested into technology and engineering development by major semiconductors including Texas Instruments, Intel, and Freescale, embedded Linux suppliers such as MontaVista Software, and even the device manufacturers. The Linux community (composed of both commercial and private interests) has also embraced, enhanced and in many cases mainstreamed the additional Linux capabilities.

To ensure that Linux would evolve continuously to meet both current and future requirements for mobile devices, a highly integrated and rapidly moving ecosystem has developed among all the interested parties. The result is a mainstream enhancement to the core Linux kernel and its associated software environment, both run-time pieces as well as development tools, that make Linux a competitive alternative, and the OS of choice for some, and a state-of-the-art OS for mobile devices.

A Horizontal Approach

In sharp contrast to the other Smartphone OS suppliers such as Microsoft with Windows Mobile, Symbian and PalmSource, the Linux “model” for use in mobile devices is horizontal. That is, Linux is not presented as a vertically integrated top to bottom solution for a mobile device supplied by one vendor. These suppliers clearly support a highly integrated software stack, incorporating not only an OS but also extensive middleware and application layer pieces. Arguably the price for such integration is lack of flexibility and loss of control; important points to remember when evaluating Linux as a possible mobile device OS candidate.

In contrast, those that have developed Linux-based devices have chosen a horizontal approach, and have filled in the middleware and application pieces by internal development. They have also turned to the Independent Software Vendor (ISV) community that surrounds Linux for mobile devices. The horizontal approach offers handset manufacturers the freedom to differentiate throughout the software stack while adding the functionality necessary to address the unique needs of the market. As a result, commoditization is prevented and the differentiation needed to address unique operator requirements is enabled.

Moore's Law Enables Linux Emergence

Underlying the rise of Linux as a serious mobile device OS alternative is the very same phenomenon that had driven the desktop technology for years: Moore's Law.

Moore's Law is the empirical observation, made in 1965 by Gordon Moore, one of the founders of Intel, that the number of transistors on an integrated circuit for a minimum component cost doubles every 24 months. While we have all seen the effect on our desktop PCs, Moore's Law applies no less to the semiconductor devices used in mobile phones. Coupled with advances in low power processors, by about 2003 it became clear that a mobile phone could be built that was at least theoretically capable of running Linux, from processor functionality (e.g. having an MMU and a large address space) as well as from execution speed (200-300 MHz). The question was whether Linux could be “trimmed” or engineered to meet the other constraints of the underlying hardware, including operation in a requirement heavy “embedded environment” and memory footprint reduction.

Linux requirements for RAM, if excessive, would be prohibitively costly. Fortunately, Moore's Law, when combined with the industry-driven technology push to make Linux a suitable embedded OS, laid the foundation for its expansion into mobile devices.

In particular, the following gaps between server Linux and the requirements of Linux on a mobile device were bridged:

  • Removal of Linux dependencies on RAM execution and reduce overall Linux RAM consumption
  • The availability of commercial quality, stabilized releases and support infrastructure along with a close working relationship with semiconductor makers to support the new silicon
  • The availability of cross development environments and associated tools since the device itself would not be a suitable development platform
  • Development of Linux-based “simulators” usually a spare PC with Linux since the hardware was under concurrent development with the software
  • Mobile-targeted processors are often completely new silicon so no support for the chips exists in the Linux source trees, requiring a port of Linux to the architecture

Rich Technology Tailored to the Needs of Mobile Devices

In order to enable its use on mobile devices, considerable investments have been made in technology enhancements for Linux over the last few years. As expected, the primary focus has been on the top three limits identified above in “standard” (or server) Linux: performance, size, and real-time capabilities. Significant efforts have also been made to address apparent weaknesses in the software development environment supporting Linux applications. Finally, extensive work on developing and testing the device drivers required to support the myriad of hardware devices typically found on mobile handsets has been continuously supported by the semiconductor makers, Linux distribution developers, and mobile device makers.

The following is an overview of some of the most important of these major technology enhancements.

Performance

Boot time reduction

In many cases, a fast boot up is more than a nice-to-have feature. There can be operator or even governmental regulations that require an emergency call be made within just a few seconds. One obvious approach is to postpone loading the drivers or other run-time software until later in the execution cycle. Of course the developer needs to be aware of the interdependencies of the software being loaded at boot time. For example, it may be a requirement to have a “splash screen” appear very early in the booting process. But the splash screen image resides in the flash file system. Therefore the drivers for the flash file system must be loaded first enabling access which in turn allows the splash screen to be read and loaded into display memory. The final optimization results can be impressive with calls placed within 10 seconds from “power on” – more than two times faster than phones from Symbian or Microsoft.

Dynamic power management

With consumers increasingly relying on mobile handsets as a primary communication channel and with additional functionality such as cameras, multimedia, and more being added into these devices, the need for longer battery life and better use of available power can be a strong differentiator. Recent improvements to Linux include an advanced, comprehensive power management infrastructure (Dynamic Power Management) to address minimum “talk-time” and “stand-by” requirements to maximize the use of available power resources.

Of course, cell phone developers want a DPM that “just works” out of the box. They also want to be able to better control the operating state and device state on a per application basis. Cell phone developers understand the power and performance characteristics of the applications they install at the factory. They want a simple, uniform way to configure across different architecture end products. Linux DPM gives mobile device developers precisely this level of control and flexibility.

Developers can have particular applications run at different power levels to provide power savings while the product is in use, instead of just getting most of the power savings from standby and sleep states, which are only entered when the device is not being used.

With DPM, developers are able to turn off power hungry devices, such as USB controllers, LCD controllers, and wireless network adaptors when the application running does not use that particular device. For example, an mp3 player that does not need the USB controller could use the DPM capability to stop supplying power to an unused USB slot.

The ultimate capability of per-device power management is to put devices and their power domains into low power states and still be aware of interrupts while the system is running. Huge power savings can be gained by placing devices and power domains into low power states while the system is still operational.

Memory Type Allocation

Developers of mobile devices can use Memory Type Allocation (MTA) to locate a program's text and data segments in specific memory devices. Shared library text and data segments can also be targeted to specific memory devices.

Critical processes such as frequently executed code can be placed in backed-up RAM. For example, glibc, the Linux run-time library, or the command “ls”, could be located entirely in a single specified memory device or a set of memory devices. glibc data can target a fast static RAM bank for instance, while other less frequently referenced libraries and programs could be located in slower RAM. Some banks of RAM can also be powered down in a sleep state, saving power, while applications that need to be run immediately on wakeup can reside in a powered RAM bank.

MTA gives Linux developers the flexibility to configure Linux specifically for the mix of memory devices (RAM, fast RAM, battery backed-up RAM, ROM, Flash etc) found in the device.

Size

Integrated support for ARM “Thumb” instruction set

For ARM-based mobile devices (a substantial percentage of devices), there is a special instruction set optionally available called Thumb. This additional mode of execution on the ARM processor is specifically designed to support very compact code generated by compliers. The technology touches both the toolchain, since the complier needs to make use of the Thumb mode capability in generating code, as well as the Linux kernel, which needs to properly save and restore the state of applications running Thumb instructions. Stack frame layout, register usage, and calling sequences need to support the Thumb capability as well.

Closely tied to the complier is the run-time library, and in the case of ARM, uClibc, which is a compact version of the gnu toolchain's run-time library glibc, is complied using the Thumb mode capability. In addition, a comprehensive set of run-time packages is also supplied having been built under the Thumb mode. All of these enhancements contribute to a reduction in the memory footprint required to run Linux and its applications.

Execute in place

RAM is a system resource that on mobile devices is always in short supply. The amount of RAM contributes directly to the cost or bill of materials (BOM) and the absolute amount of RAM can also negatively affect the battery life. In general, Flash memory is cheaper (although considerably slower) than RAM, making the increasing utilization of Flash memory a preferred goal. With the traditional Linux approach, applications are loaded into RAM from the filesystem and then executed from RAM. In classic embedded systems the application was stored in a sort of read-only memory (EEPROM, ROM, etc.) which was part of the processor's memory address space. As long as the application was written to be executed from ROM, this approach saved RAM.

The use of read-only memory is desirable for Linux as well. An obvious use of Flash memory is ROM memory, when the Flash is mapped into the processor's address space and the applications “execute in place” (e.g., run from Flash) rather than loaded into RAM for execution. It is fairly simple to employ Flash memory for applications which have been developed to execute from ROM. However, just as applications need to be written with ROM execution in mind, the Linux kernel, which traditionally was presumed to be executed from RAM, needed to be enhanced for it to be capable of execution. These enhancements have indeed been made and are now part of the standard capability of the Linux kernel. Execute in place capability is a configuration option at system-build time.

DirectFB a small footprint graphics subsystem

The standard graphics system supplied with Linux is the X Windows system. Although very capable, its memory footprint makes it a less-than perfect fit for the smaller memory space found in mobile devices. A more memory-friendly alternative is the DirectFB package, a graphics system specifically designed to operate in small memory configurations. DirectFB provides hardware graphics acceleration, input device handling and abstraction, integrated windowing systems with support for translucent windows and multiple display layers, using the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. DirectFB has been ported to many mobile-oriented processors and is available with Linux distributions targeted for mobile devices.

Real-Time Features

The “Holy Grail” for embedded Linux has been to improve the “native” real-time capabilities of Linux. “Native” meaning within Linux, as opposed to adding a real-time sub-kernel in order to provide real-time response. For mobile devices in particular, improved real-time capability has a number of implications. The first is that many advanced features, such as audio and video-type applications require real-time response guarantees by the system in order to ensure smooth playback. Human eyes and ears are very sensitive to small delays in processing this kind of data and easily perceive jitter in video and noise in audio playback if the playback is not fast enough. The second benefit of real-time capability is the ability to produce a mid-range handset in which both the application and radio software stacks run on the same processor. It clearly requires real-time capability to control the radio at the rates required for correct and reliable operation.

Recent advances in Linux have closed the gaps that existed between the traditional RTOS (Real-Time Operating System) technology and Linux. Major development efforts over the past few years have resulted in a fully-preemptible Linux kernel, thus allowing for greatly improved application-level real-time responsiveness. The foundation for this new capability in Linux is based on the following three factors:

  1. No Spin Locks: Spin locks have been seamlessly converted to the new mutex. Spin locks, which are used in server Linux to protect critical sections, also disable preemption. Consequently one of the keys to lower preemption rates is removing spin locks through a non invasive process, the simple replacement by the new mutexes.
  2. Priority Inheriting Mutexes: A mutual exclusion object (mutex) allowing the highest priority of all the waiters on a mutex to increase the priority of the mutex owner. These mutexes are used to protect the internal critical sections found within the Linux kernel. In addition they are based upon the priority inheritance protocol, which is designed to mitigate the problem of priority inversion, a well known side effect of less sophisticated mutual exclusion primitives.
  3. Interrupts in Threads: The process of servicing interrupts in thread context instead of interrupt context has been added to Linux. Linux also disables interrupts (and thereby preemption) when in interrupt context, which can lead to long interrupt disable times and poor real-time response. Moving the threads out of interrupt context keeps the interrupt context execution paths short thus increasing real-time responsiveness. Since interrupts can now lock the new mutex, they must also be in process context so they may sleep.

Platform-specific Enhancements

Arguably, a high-end smart phone may come configured with more built-in I/O devices than a typical desktop PC. Here's a pretty typical list: SDIO, display, touchscreen capability, input devices, audio, camera, Bluetooth, USB 2.0 with client and gadget Support, TV out, and wireless connectivity.

All of these devices need Linux device drivers, as well as middleware and application-level software. These drivers have been developed by cooperation among the semiconductor suppliers, the Linux distribution makers such as MontaVista, and the handset manufacturers. In addition, all of these devices require integration with middleware and application stacks, which are either supplied from ISVs or developed by the mobile device maker. Testing software has also been developed in order to ensure that the software drivers and middleware/applications work correctly together.

A Mobile Linux Distribution

Commercially supplied Linux distributions, such as Mobilinux from MontaVista, come with a complete development platform and run-time components for building a Linux-based mobile solution. These distributions integrate, test and support the extensive set of Open Source technologies that compose a viable Linux environment. A typical distribution, including its development toolset, is based upon tens of millions of lines of code from numerous Open Source projects, including Linux, of course, but many others as well.

Summary

Ideally suited for wireless handsets and mobile devices, Linux has quickly emerged as an optimized OS and development platform. A Linux-based commercial distribution is competitive with other proprietary solutions based upon its advanced mobile-oriented technology, broad hardware support, proven quality and solid development environment capability. When provided by a mobile-focused, commercial off-the-shelf supplier, Linux, along with its extensive ecosystem, provides mobile device makers the time to market benefits normally only found in proprietary development platforms along with the customizability and control of a standard, Open Source-based environment.

With more than 20 million handsets based on commercial Linux, its field-proven success gives developers considerable piece of mind that they are developing on a solid, high quality and reliable foundation.


About the author — Jim Ready founded MontaVista in 1999 to provide the Linux operating system to the embedded systems market, and to offer enbedded-system expertise to the open source Linux community. He has over 25 years of technical and entrepreneurial experience. As co-founder of Ready Systems in 1980, he pioneered development of the VRTX real-time kernel, the first commercially viable, real-time operating system (RTOS) product. He has a BA from the University of Illinois at urbana-Champaign, and an MA from the University of California, Berkeley.


 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.



Comments are closed.