Unlike many realms of human endeavor, when it comes to designing embedded systems, the goal is often to use as few resources as possible. In embedded systems, less is more, in many ways. Using less resources means less cost, less heat generation, more battery life, more reliability — and best of all, a more successful product.

During the past year, Linux has rocketed to prominence as one of the two or three most popular operating systems for new embedded system designs. Since “Embedded Linux” as a product is less than one year old, and given the common perception of Linux as a full-function server or desktop OS that requires hundreds of megabytes of disk space, it's no surprise that one of the most common questions about embedded Linux among developers is “How much RAM memory and disk space does an embedded system require to run Linux?”

There are two reasons why it's difficult to answer that question with a few simple numbers. First, Linux is open source. As a result, developers possess the tools to eliminate unnecessary functionality to match the requirements of a given configuration. Secondly, embedded systems are incredibly diverse, so there are almost as many required Linux configurations as there are unique embedded systems (and that's in the tens of thousands).

Understanding that embedded systems tend to be highly individualized, it's still nice to establish some general guidelines. The following data on RAM and disk (typically Flash ROM, in embedded apps) size requirements, provided by Lineo, are intended to represent miminum typical resource requirements for Linux in embedded applications. But remember, as the saying goes, “actual mileage will vary!”

Tim Bird, Lineo CTO, advises that “in making competitive comparisons between embedded systems, be sure to make those comparisons fairly.” “For example,” says Bird, “a vendor may state that their products work in 100 KB of RAM, when in fact that number is meaningless — it does not include any networking, system libraries, or other core components necessary to create a working system.” The following Lineo size estimates apply to complete working Linux systems (including networking capabilities), based on products offered by Lineo and its subsidiaries:

• Rt-Control provides uClinux, a version of Linux for microcontrollers such as the Motorola 68k/ColdFire line, i960, ARM7, and ETRAX chips. uClinux is able to run full-featured in under 200 KB of RAM memory, with a 1 MB ROM chip (which serves as the boot “disk” from which the Linux image loads). [Editor's note: there are some limitations in the multitasking provided by uClinux, due to the lack of MMU. See writeup.]

• FirePlug focuses on specialized Linux-based projects such as their Linux firewall. They build these using ThinLinux, which loads from as little as 2 MB of Flash disk and runs within 8 MB of RAM memory.

• Embedix, Lineo's flagship product, can load a complete multitasking, networked Linux operating system from 2 MB of ROM/Flash and run in 4 MB of RAM memory.

According to Bird, these numbers reflect “generous minimum requirements for a complete working system.” Bird adds that even less space may be necessary in some circumstances. On the other hand, adding special drivers and applications requires increased system resources.

MontaVista's Bill Weinberg takes a different tack on the question of low-end embedded Linux size. “Let me speak directly to the footprint issue itself,” says Weinberg. “With the exception of entire systems-on-chip, when customers choose a 32-bit processor capable of running Linux, they're not going to then proceed to starve that CPU with too little memory and storage.” “In other words,” continues Weinberg, “the 'tiny' kernel is quickly becoming a mythical beast of the past, in light of today's low costs of 32-bit processors, RAM, and Flash.”

Weinberg contends that realistic low-end requirements for Linux are in the range of 4-8 MB RAM space, and a couple of megabytes of Flash. “Embedded product developers are increasingly focused on adding value through enhanced software-based functionality, rather than expending a lot of effort to squeeze out features in order to save a meg or two of memory,” adds Weinberg. With RAM and Flash memory prices in the range of a dollar per megabyte, and dropping continuously, that approach seems well justified.

Red Hat CTO Michael Tiemann, on the other hand, differs from the approach of both Lineo and MontaVista. Red Hat offers an alternative small-footprint operating system to Linux, called eCos. Regarding the difference between eCos and Linux, Tiemann explains that “they're like a motorcycle and a house trailer (or SUV). Let's say you take your trailer, towing your motorcycle, on a vacation. You drive to a mountain in the trailer. But when you want to drive up onto the mountain, you don't use the trailer, you switch to the motorcycle. eCos offers developers an opportunity to stay within the open source realm when the application isn't appropriate for Linux.”

As for guidelines on which to use when, Tiemann advises “if you require less than around two megs of RAM, you probably don't need Linux. However, Linux is really a lot happier running with 4 or even 16 megs. So, in the range of two to four megs, it depends on the particular application.” Interestingly, given the perception of Red Hat as “the Linux company”, Tiemann recommends that developers of low end embedded systems try first to use eCos, and fall back on Linux only if eCos can't meet the need. “If you're coming at this question (of eCos vs. Linux) from a truly embedded perspective,” says Tiemann, “I think a better way to think about it is 'can I use eCos?' Then, if you come up with a reason why it's impossible to use eCos, use embedded Linux.”

That opinion doesn't appear to be shared by many. MontaVista's Weinberg, for example, characterizes eCos as “a mix of size and capability targeted at deeply embedded systems with a series of APIs that cover their varying needs, but that ignores customers' actual reasons for considering embedded Linux: openness, reliability, and compatibility.”

“First,” argues Weinberg, “although Red Hat makes eCos source available, it lacks real open source momentum. Second, although eCos mimics certain Linux/POSIX APIs, it's really 'just another RTOS' — it doesn't offer the process model, memory management/protection, and security options that have given Linux its mainstream audience. Finally, users aren't looking for an additional fabricated standard (EL/IX) to 'unify' embedded Linux with eCos. Why should they, when the accepted standard is Linux itself?”

---

Do you have comments or questions on this article? Talkback here

 
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.