Home > Articles > Operating Systems, Server > Linux/UNIX/Open Source

Do it Yourself Embedded Linux

  • Print
  • + Share This
Embedded systems are all the rage, especially the Linux-powered devices on the market. Marcel Gagné tells here why Linux's open-source model, easy customization, and popularity with developers make it an ideal choice for embedded systems.
Congratulations to Marcel, who recently won the Linux Journal's 2001 Readers' Choice Aware for favorite column. Marcel's column, "Cooking with Linux," appears there monthly.
From the author of

This article originally appeared in the Java Developer's Journal "Linux Focus" Issue.

The world is abuzz with the promise of embedded systems, and hopes are riding high on the immensely popular Linux operating system. Its open-source model, easy customization, and popularity with developers make it an ideal choice for embedded systems. The recent flurry of Linux-powered devices on the market boggles the mind:

  • Linux-powered intelligent golf carts with a GPS system built in

  • A Linux watch complete with X Window display

  • A super-cool car audio MP3 player

Access to the source means that devices can be built with highly specific characteristics taken into consideration without a great deal of generic overhead. You can build what you need and only what you need. Another plus: virtually anyone can enter the embedded Linux development world.

Before I even start down this road, I'd like to begin by saying that embedded systems are nothing new (not in information technology time lines, anyway). Customized processors exist in a vast array of devices in and around the average home. Do you have a personal organizer (like a Palm Pilot or Visor)? Video game unit? Digital camera? Tech toys, you say, but we can get quite a bit more mundane than that. How about a VCR or a microwave oven? After only a few years, we've all but forgotten what an amazing feat of technology a cell phone is. Even our cars come with embedded computers.

Embedded systems were considered one of the great black holes of the (at the time) upcoming (and now long past) Y2K crisis. While many companies could refer to the source code for their financial applications, manufacturing systems, and so on, it became a bit more foggy when it came to embedded systems. In the end, the most optimistic industry watchers were declaring that the real Y2K threat lay in embedded systems. While we all survived more or less intact, I do have a VCR that can only be programmed within the time frame of a single day because I can no longer set the date. It's a minor beef since I generally don't tape too many shows, but it highlights one of the problems with embedded systems to date and why embedded Linux is so exciting.

In a nutshell, the problem is that there are too many different embedded system technologies out there, too many proprietary chips and languages, and not enough standardization. Each chip is developed for separate applications. This makes extended development and support extremely expensive on many counts, such as the manufacturing process. When we buy a proprietary embedded system, we bank on one and only one vendor to support us throughout the life of that device. We also bank on never having to upgrade, maintain, or modify anything on that system. It's literally carved in stone.

Linux changes all this, and the change is a powerful one that's being watched at all industry levels. Witness the creation of the Embedded Linux Consortium, a nonprofit vendor-neutral organization whose sole purpose is supporting embedded Linux technologies. Should you still have any doubts about the industry's interest in these developments, witness some of the names on ELC's roster: IBM, HP, Lineo, Red Hat, Motorola, Palm—an impressive list.

Should you feel the need to get involved in this Linux microrevolution, rest assured that you don't need the backing of a major corporation and millions in venture capital funding. The tools are out there, free for the taking. Saying that creating embedded systems necessitates some miniaturization of the code may sound like a case of the bleeding obvious, but there's an art to building what you need and nothing more. It requires a desire to get your "hands" dirty with kernel builds and more than a little restraint.

For developers building tiny Linux applications BusyBox is a great place to start. BusyBox, originally created by Bruce Perens (now maintained by Erik Andersen and sponsored by Lineo), bills itself as "the Swiss Army Knife of Embedded Linux." As soon as you start exploring it, you'll understand why. It's a single small executable that packs over a hundred common Linux commands into a single package. This approach helps fix one of the great problems with creating a tiny embedded Linux, namely the relatively large executables that are created when linking against the GNU C libraries.

To be fair, I should point out that large is a matter of perspective. A 100K program is no big deal when you have a 4GB drive; however, in the world of an 8MB chip, it won't take long to use up that precious memory if every program is that "small."

Let's try this, shall we? Head on over to the BusyBox Web site at http://busybox.lineo.com, and pick up the latest source. Contrary to many warnings, you can try this at home.

Once you've downloaded BusyBox, extract the source and build the executable on your system. Here are the steps based on release 0.47:

tar -xzvf busybox-0.47.tar.gz
cd busybox-0.47
make 

This builds the binary with all tools activated. I mention this because BusyBox is quite modular in its design and allows you to build in only the functions you're looking for. This is done by editing the Config.h file you'll find in the source directory. Here's a sample from that file:

//
// BusyBox Applications
#define BB_AR
#define BB_BASENAME
#define BB_CAT
#define BB_CHMOD_CHOWN_CHGRP
#define BB_CHROOT
#define BB_CHVT
#define BB_CLEAR
#define BB_CP_MV
#define BB_CUT
#define BB_DATE
// #define BB_DC 

Notice the last line where C++-style comment characters have been added (//). I've undefined the build flag for the dc command (a Reverse-Polish desk calculator). In all, 107 defines can be undefined to create as small a binary as your needs require.

What do you do with this executable once you've built it? How do you use it? To test your build, simply type the command ./busybox, followed by the command you wish to execute. For instance, BusyBox comes with a simple telnet client. If I wanted to use it to connect to my remote development system, I'd type the following:

./busybox telnet devsys 

Of course, you don't want your users typing something this pedantic if all they want is to do a file listing with ls. What you can do, however, is create symbolic (or hard) links to the BusyBox executable. Let's work with my telnet command above:

ln busybox telnet 

To use the telnet command and connect to my development system, I need to type only ./telnet devsys.

Sometimes the best way to start is by looking at the work of someone else in the same environment. The BusyBox site contains links to tools that projects are currently using. One of those sites is a personal favorite of mine, tomsrtbt, which stands for "Tom's floppy which has a root filesystem and is also bootable." At least that's what the man claims. Tom is Thomas Oehser, by the way, and his little Linux provides a bevy of tools on a single floppy diskette. Granted, tomsrtbt uses a formatting trick to squeeze 1.7MB from a floppy diskette space rather than the normal 1.4. Even so, the results are a great demonstration of what can be done with a small-footprint Linux. To get your own copy of tomsrtbt, visit the Web site at http://www.toms.net/rb.

The site contains both a development version and a stable release. As I write this, the latest stable distribution is tomsrtbt-1.7.185.tar.gz. Once you've downloaded the file, extract it to a temporary directory. From there, you can use the install script to create your diskette. Start by putting a blank diskette in your drive, and then:

tar -xzvf tomsrtbt-1.7.185.tar.gz
cd tomsrtbt-1.7.185
./install.s 

That's all there is to it. Almost. You'll want to change a few things, particularly if you're on a network. For instance, the default installation boots to a preconfigured set of network addresses, including DNS entries that aren't likely to match your environment. To customize tomsrtbt for your own network, edit the settings.s file in the tomsrtbt distribution directory. The following lines represent my changes to the network parameters so that tomsrtbt can exist on my network:

DOMAIN=mycompany.com
IF_PORT=10baseT
DNS_1=192.168.22.10
IPADDR=192.168.22.4
NETWORK=192.168.22.0
NETMASK=255.255.255.0
PASSWD=xxxx FD=/dev/fd0u1722
FN="b 2 60" 

The original network numbers are in the network 192.168.1.0, and the domain is rb.com.

Once you've booted, log in as root (you can even remove the diskette at this point) and start exploring. If you wander over to the /usr/bin directory and do an ls -l, you'll notice something interesting. Several of the files have the same size, date, and time stamp. You'll also notice that one of these identical files is called busybox.

This little diskette is a great tool in itself. It supports SCSI and PCMCIA, and it contains a host of handy tools. Whenever I go off-site to do some work, I carry a tomsrtbt with me for emergencies (not to mention a known quantity on an otherwise unknown network). One of the other great things about it is that it understands your hard drives and lets you mount them. For instance, if I boot from the floppy on a Windows workstation, I can mount the C: drive and navigate it from my little Linux. From the root prompt, I'd do this:

mkdir /mnt/cdrive mount /dev/hda1 /mnt/cdrive 

From there, I can navigate the hard drive and make backups with tar, cpio, or ftp files to another server. I also carry other tiny distributions that have been put together for very specific purposes. At any given time, you'll find LOAF, Trinux, and tomsrtbt in my arsenal.

If you'd like to create your own specialized boot diskette, consider visiting BYLD (originally developed by Erich Roncarolo) at its SourceForge site, http://byld.sourceforge.net. You'll find a package that's designed to allow you to create customized single floppy Linux distributions. You decide your own applications and build to your needs, whether it's a router, firewall, or rescue disk. To try your hand at a personal tiny Linux, download the source and extract it to a work directory. I decided to try out the latest beta release:

tar -xzvf byld-1_0beta3.tar.gz cd byld-1.0beta3 

If you haven't already done so, load your loop module:

insmod loop 

There's a lot to cover here, and I have no room to go into it, but if you're feeling impatient, start building your floppy right now:

./BuildRoot SingleFloppy 

Among other things, you'll see BYLD putting together and compiling BusyBox to stand in for a number of basic Linux commands. Once this process is over, do the following:

./MakeImage 

At this point, the program creates a temporary loop device filesystem (in case you wondered why we were loading the driver), writes out the image, compresses it, and prepares the final product:

./WriteImage 

As you may have expected, this writes the whole thing out to your floppy. I haven't done any customization to the source in any of this. This is where the experimenting comes into play. When I tried to build my first diskette, I decided to go easy on myself and simply use the existing kernel from my Red Hat 6.2 system. Nice enough idea, but I went over the 1722KB limit for a boot diskette. Because I really wanted to have my very own single-floppy Linux, I decided to comment out some of the packages from BusyBox in the BYLD directory. After several other attempts (I broke down and deleted a handful of programs from the root/sbin directory), the WriteDisk process told me that my image was now smaller than the maximum of 1722K. I hit Enter and waited for my diskette to be created.

Note: You may or may not already have a 1722K diskette device defined on your system. If it doesn't exist, you can create one like this:

mknod /dev/fd0u1722 b 2 60 

Just as Linux has changed the face of the computing world in the last few years, it will also change the way we interact with the devices in and around us. Intelligent televisions, microwave ovens, refrigerators, security systems, and just about anything else you care to put your mind to will start appearing in the near future. The open-source development model should make it possible to drastically reduce development costs, thus making the arrival of new technology that much closer. Not only that, but Linux has been ported to numerous processor types. We may find that old hardware suddenly has a new lease on life as we reprogram it to perform new functions.

Go ahead. You can try this at home.

Resources

  • + Share This
  • 🔖 Save To Your Account