| uClinux: World's most popular embedded Linux distro? |
a guest column by John Drabik (Sept. 24, 2002)
Despite claims to the contrary, uClinux may well represent the world's first, most mature, and most commercially successful embedded Linux distribution. While other embedded distributions rely on upscale processors to get reasonable performance, uClinux uses solid code, a firm guiding hand, and actual product experience with deeply embedded systems. The results are smaller code, better performance, and lower cost -- all of which is applicable to both MMU-less and MMU-enabled systems.
Introduction and early history
uClinux (pronounced 'you see linux') grew out of the work of Jeff Dionne, Kenneth Albanowski, and later, Michael Durrant, at a company known as Rt-Control, in Toronto, Canada. The first release of uClinux was for then-popular Motorola 68000 processors; but an early focus on cross-platform development along with an easily-understood model quickly led to ports for other chips. Most were highly integrated microcontrollers, such as ColdFire, ETRAX, ARM7, ARM9, and i960. The basic techniques were sound, the results excellent, and the code was useful on MMU-enabled processors too -- even x86, sometimes with the MMU turned off for better performance.
The unique (occasionally bizarre) needs of small processors and the rapid success of uClinux led to a number of other related software developments, including the uC-libc library, which replaces the Linux libc and/or glibc libraries for many applications, in a tiny fraction of the space (occasionally less than 1% the size of glibc). Now, uClibc is maintained by CodePoet (Erik Andersen), with input and funding from Arcturus, SnapGear, and others. Thanks to CodePoet, uClibc supports shared libraries when run on MMU-enabled devices. It is also header-compliant with glibc; the subset of implemented functions tries to be fully compliant with the API of glibc, for portability.
SnapGear (formerly Moreton Bay, acquired by Lineo, and later spun off) added bFLT dll support. In the vast majority of cases, statically linked bFLT programs use less space than those using shared libraries and glibc. Other contributors include RidgeRun (ELF shared library support), and a number of smaller organizations and interested Linux experts. A common thread among many of the uClinux developers is the use of uClinux on actual embedded products, instead of a software-only focus that sometimes fails to take into account product, cost, or market realities.
uClinux was originally created based on Linux kernel version 2.0.33 in 1997, and was released to the community in February 1998. It reached full stride with the 2.0.34 kernel. uClinux offers the powerful networking and other advantages of Linux, with excellent device driver support, and with manageable kernel code base changes to handle the restrictions of MMU-less processors. The 2.0.38 release was the most widely used embedded Linux distribution until fairly recently -- testament to the stability and ease of use of uClinux. Anecdotal evidence suggests that actual, deployed uClinux-based devices outnumber those based on the embedded Linux distributions of Lineo, MontaVista, and Red Hat combined.
Supporting the Linux kernel 2.2 and beyond
Linux kernel version 2.2 represented a large code change effort, with relatively minor advantages for MMU-less devices. The discussion about how and whether to support Linux kernel version 2.2 arose around the time Rt-Control was acquired by Lineo. Among other things, it was unclear how to incorporate MMU-less support into Lineo's Embedix SDK (itself a fairly new and unproven product at the time). As a result, uClinux development slowed. Discussions continued on how the two kernel code sets -- Embedix with kernel 2.2, and uClinux with kernel 2.0 -- might be merged, but those efforts stalled due to SDK issues. Eventually, efforts to merge the two codesets stopped and uClinux remained at the 2.0.3x kernel versions.
It turned out to be rather easy to port drivers that might be needed for devices on MMU-less designs, from kernel version 2.2 to version 2.0. In many cases, rework was necessary anyway, due to the memory model of MMU-less devices, and related fork() and mmap() issues. Furthermore, many Linux programmers, aiming at desktop systems, were writing things a bit 'fat' for the likes of uClinux-based products. It must be remembered that the uClinux kernel, as small as 200 KB or so (including TCP/IP), was half the size of V2.2 kernels; it's not uncommon for a complete 2.0.x based router product to occupy less than 1 MB of storage, including support code. At the time, memory size was severely constrained in small products due to heavy market demand across the industry and resulting high prices. uClinux met the challenge, and adoption rates rose accordingly.
In late 2000, Linux kernel 2.4 work was in full gear. The enhancements of Linux kernel 2.4 were compelling enough to warrant the effort to port it to MMU-less devices. Conscientious preparations paid off; less than a week after the official release of the standard 2.4 kernel, the first uClinux 2.4 code was released.
Since then, most new uClinux development has been with the 2.4 kernel, though there continues to be strong interest in the 2.0 code base and development work. At the same time, the general market slump provided an unexpected benefit to embedded devices; it was easier to get cost-competitive, but larger, memory devices. Today, some companies find it difficult to locate older, smaller devices because chip vendors push the somewhat higher margin large devices. As a result, products using uClinux can add many new features, yet still benefit from the small kernel and libraries, to make effective use of the larger memory space available.
A unique focus
 One of the truly unique aspects of the Rt-Control group which created uClinux was the breadth of expertise. The group included hardware designers, kernel and toolchain experts, system developers, and business managers with Linux product experience. For example, they designed and delivered the tiny (1.0 x 2.5 in.) uCsimm single-board computer, which turned out to be exactly what was needed for a large number of real-world embedded applications such as multi-axis robotic controllers. Rt-Control engineers were also involved in a number of other embedded product designs, using 68K, ColdFire, ARM7, and ARM9 processors which depended on the flexibility and small footprint of uClinux.
 Around the same time, the folks at Moreton Bay were designing hardware for their NETtel routers (pictured at right), which were based on uClinux. These successful products were a major design win for uClinux. Moreton Bay contributed code for a number of processors including ColdFire.
While at Lineo, former Rt-Control engineers moved ahead with the popular and cost-effective uCdimm product (pictured below), ColdFire designs, and others; all were MMU-less, and all based on uClinux. They also started to work more closely with the former Moreton Bay team. The result was another industry first -- full solution stacks for Linux-based residential gateway (RG) products, from both groups. The Moreton Bay group was deploying completely integrated RG gateway and router products, while the Rt-Control engineers focused on delivering stacks for use by OEMs. The results were equally impressive and successful for both.
 Were it not for in-house hardware, software, and system development and the associated needs of actual products, uClinux might well have followed general Linux trends blindly. Certainly other embedded Linux distributions were trapped in that pattern, perhaps because it wasn't quite clear just which pieces might actually be needed in a given embedded system. Instead, the Rt-Control and Moreton Bay engineers, by now increasingly engaged with customers needing full embedded system and option analyses, were able to draw on their experience with the rapid development of real embedded devices.
The result is an operating system which, while retaining compatibility with conventional Linux, provides stunning cost and time-to-market advantages relative to commercial RTOSes. Porting occurs in a fraction of the time, and at far lower expense, than any commercial RTOS, yet retaining all of the advantages of Linux.
-- Continue to Part 2: Recent events, and a promising future --
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed