This article describes one way to run Linux in an embedded system with no hard disk. The application I describe is an Operator Interface in a monitor and display system developed by Boeing Flight Test. The airborne environment requires something fairly rugged, and must withstand common power interruptions. To meet these requirements we decided to build the operator interface without a hard disk.
The basic concept used is to boot from a solid state disk (SSD) in EPROM, copy a root file system from EPROM to a ram disk, load the operator interface software from a host and run. This article focuses on the details of how the system works, and on development techniques used.
The hardware selected was a VME based Single Board Computer (SBC) 80486 with 16Meg, a PC104 SSD which could hold 4Meg EPROM, and some other PC104 boards. This SBC has built in bios support for using the SSD. The system uses a programmable keyboard and a standard VGA display.
For booting two options were considered: 1) To boot DOS then run the loadlin program (to load linux) from autoexec.bat, or 2) to install LILO and boot directly to linux. The advantage of the second option would be slightly shorter boot time. The first option was used because of the programmable keyboard -- the software for programming the keyboard runs under DOS.
A bit of kernel hacking was needed to make the system work. The ramdisk.c code was changed to load from any block device, not just a floppy (code fragment 1). Also, a new block driver was written to read from the EPROM device (epromdsk.c).
When deciding how to implement the EPROM device driver the first idea was to create an image of a disk in the EPROM. This would provide a ram-disk the same size as the EPROM - 3.5MB in this case (the DOS portion of the SSD takes 1/2 MB). Instead, to allow larger ramdisk, a compressed disk image is used. The compression used is simple - any sectors which are identical are only stored once. The primary advantage this gives is blank areas of the disk image don't need to take up EPROM space. Figure 1 shows the SSD disk compression used.
In order to automatically run the operator interface application a program was written to replace getty. This program (dboot.c) will run login for a given user and set the stdin, stdout, and stderr to the specified virtual console.
The boot sequence is:
After the fun stuff of figuring how to make an EPROM driver and how to boot the system, the more mundane task of putting together the EPROM disk contents had to be done. This was done using a development disk which was partitioned as follows:
LILO was used to allow booting to either linux system, or to DOS.
Programming EPROM's is a time consuming task, and to be avoided as much as possible. To this end, most of the development is done using the disk.
The first phase of disk image development was to identify required and desired items. The first step was to come up with a minimal system and then add the items required for the operator interface. Not being a unix expert, coming up with the minimal system ended up being somewhat trial and error. I started with what I thought was needed, then tried running it. When an error occured because of a missing program or library, that file would be added. This went on until the system would run happily.
The bulk of this effort was done by copying files from the "full" linux partion to the 6MB partition, and boot DOS and use the loadlin line:
Once the system was fairly stable the 6MB partition would be loaded into ramdisk. This is very similar to how the ramdisk is loaded from EPROM, but development is faster since EPROMS don't need to be programmed. To test the system without programming EPROM's, The system was booted into DOS and loadlin run with the line:
Because of the modification to ramdisk.c the /dev/hda2 disk image is loaded into the ramdisk then the root file system is switched to the ramdisk. The process of refining the disk image continues until everything is "perfect".
The process of programming (burning) the EPROMs starts out by tar-ing the small disk drive, then un-tar-ing it onto a clean (zeroed out) file system. By putting the file system onto a clean disk all unused sectors are zeroed out, and the disk compression works (see Figure 1).
To tar the disk image the "full" linux partition was booted, and the 6MB partition was mounted. By doing this the proc file system is not included in the tar. The following commands can be used:
This creates a file (eprom.dsk) which is a sector by sector image of the disk. The data to be programmed into the EPROMs is the compressed image. This is done with a program (med) which reads the disk image (eprom.img), runs the disk compression, and outputs a binary file (eprom.img) which will be programmed into the EPROMs.
The EPROM image is then moved to an EPROM programmer and the images are burned. The details of this are left to the interested reader to figure out.
Fortunately the SBC came with SSD utilities to help build the disk image. The DOS SSD disk has a bare minimum of files in it: the DOS boot files, command.com, autoexec.bat, the keyboard loading program, loadlin, and the zImage.
This article gave details on one way to run linux from EPROM without using a hard disk. The development of what goes on the disk is a large part of the job and methods need to be developed to minimize this effort. Using the EPROM disk is working well in our application.
Dave Bennett "works with computers" at Boeing in the Commercial Airplane Flight Test group. When not at work he enjoys the company of his lovely domestic associate, two cats, and a bunch of fish. Dave enjoys building things - a few of which are featured on the lame web page www.vogie.com. Dave can be reached at [email protected] or [email protected].
