Flutterby™!: CompactFlash Linux Install for Embedded Applications

by:Dan Lyke [edit history] started: 2003-04-07 23:36:33.476901+02 updated: 2003-07-18 22:48:27.959161+02

For work, I needed to build an embedded system to monitor a stepper controller. Since we're not doing a gazillion of these, and since a Linux development environment is easy to work in, the slight additional cost of using a Via Eden board, with extra computing capacity, seemed like a reasonable thing to do. But we wanted it diskless, for less moving parts to break, and I wanted to know what every process running on the machine was, because I didn't want things writing log files to disks I didn't know were filling up, or things like that. This is how I configured that machine to run off of a small CompactFlash card.

We bought the Via Eden from iDot, and used the ACS Control CompactFlash to IDE adapter to host the card.

Although the target system was built completely from scratch, the host systems used to create this installation were running the Debian distribution of Linux. A few files might be in paths specific to that installation.

Put the CompactFlash card on a computer running Linux. I have done this by either plugging it into a PCMCIA adapter, or by using the ACS ontrol CompactFlash to IDE adapter. Note that you can't "hot-plug" the latter, so the machine must be turned off, the CompactFlash card installed, and then booted. This makes the PCMCIA solution far preferable.

This is probably also easy with a USB card reader, I just haven't done it yet.

For the purposes of this note, we will assume that the card ends up at the device /dev/hde. If it goes somewhere else (/dev/hdc is an obvious choice if it's the bus master in the secondary IDE bus), replace all references with that.

Make sure the card isn't mounted. Some systems will attempt to automount the card. If it is, unmount that partition.

Use fdisk to delete the existing partitions, and create a new partition. Change its type to "83", or "Linux". We're going to create an "ext2" type filesystem on it. Write the new partition table and quit.

Run mkfs.ext2 /dev/hde1 to create a filesystem on the partition you just created. Run install-mbr /dev/hde to install a new master boot record on the card.

You can now mount the partition. Since someone was trying to push a standard of mounting CompactFlash cards on /mnt/film, that's where I've mounted it.

mount -t ext2 /dev/hde1 /mnt/film

Note that you may have to manually specify the filesystem type, some automounters will mount anything not specified as FAT or VFAT.

Build the target filesystem on it. For my purposes, this meant:

mkdir /mnt/film/boot
mkdir /mnt/film/bin
mkdir /mnt/film/dev
mkdir /mnt/film/dev/cciss
mkdir /mnt/film/etc
mkdir /mnt/film/lib
mkdir /mnt/film/opt
mkdir /mnt/film/proc
mkdir /mnt/film/sbin
mkdir /mnt/film/tmp
mkdir /mnt/film/var
mkdir /mnt/film/usr
mkdir /mnt/film/usr/bin
mkdir /mnt/film/usr/lib
mkdir /mnt/film/etc/init.d
mkdir /mnt/film/usr/www

Make a lilo.conf file for your install. This is just like you'd normally configure a lilo.conf except that you need to specify which disk to operate on:

disk=/dev/hde

And you need to explicitly tell it that this will be the first BIOS disk once it's installed:

bios=0x80

Copy this into /mnt/film/etc/lilo.conf.

Untar and configure the Linux kernel you'll be using. In the root level Makefile, set

INSTALL_PATH=/mnt/film/boot

In ./arch/i386/boot/install.sh I changed the last line to read:

/sbin/lilo -b /dev/hde -C /usr/src/viaeden/linux-2.4.19/arch/i386/boot/lilo.conf

And I copied /mnt/film/etc/lilo.conf to that lilo.conf location. Then you can

make dep
make bzlilo

Finally,

lilo -v 3 -r /mnt/film -C etc/lilo.conf

And the card should be bootable. Yes, there are steps in this that could be cleaned up.

"cd" into /mnt/film/dev and create the devices. Most of the critical stuff can be gotten with:

MAKEDEV std
MAKEDEV ttyS0
MAKEDEV hda
MAKEDEV hde
MAKEDEV console
mknod psaux c 10 1
MAKEDEV audio


I used BusyBox to have the basic Un*x utilities available. Yes, you could just as easily set up your program to be /bin/init, but it's so handy for debugging to be able to ls and cat and grep that it's hardly worth going further. There are some mechanisms for installing it, I just did a make and then a cp -r ./busybox-0.60.5/_install/* /mnt/film/ to install it.

I also talked to this machine via Ethernet, so installing net-tools was in order. Find the distribution on the 'net, do a ./configure --prefix=/mnt/film, then make and make install.

At this point it's time to make friends with ldd. This tells you what libraries an executable needs, and if your own executables don't need extra libraries, the net-tools will. Thus far I've found that:

cp /lib/libcrypt.so.1 /lib/libc.so.6 /lib/ld-linux.so.2 /mnt/film/lib/

is a good start. The only remaining thing is to get your /etc/init.d/rcS script set up. Rather than a complex "init" system, BusyBox just runs this script at the end of the boot.

First, you want to mount the "proc" filesystem:

mount -t proc /proc

Next you want to remount the root filesystem as read-write. You'll probably pull this out before your system goes live, but it's nice to have some scratch as you play. However, even more importantly for scratch, you'll want some scratch disk for your applications to play with. I did a:

mkfs.ext2 /dev/ram0

And then gziped /dev/ram0 into a file that I could install on the boot, like so:

gunzip < /sbin/diskimage.gz | dd of=/dev/ram0
mount /dev/ram0 /tmp

This way I didn't have to copy over all of the mkfs dependencies.

The rest of my script is just devoted to configuring the ethernet interface and starting the various daemons. A suggestion: If you don't put a small editor on the box, you're kinda left with what you can do with grep, cat, sed and redirected echoes. I don't know sed, and after a few tries grep and grep -v combinations become horribly annoying, so I found that using backticks, as in:

ifconfig etho `cat /etc/ipaddress`

where the file /etc/ipaddress has one line with the IP address you want the config file to contain, makes a few things a lot easier.

For daemons, I used webfs as a web server. I started with thttp, but I was communicating with my controller daemon via "fifo"s, and something about the CGI handling in that just hosed my sockets. webfs ran my CGIs fine.

by:Dan Lyke started: 2003-04-08 00:01:55.874692+02 updated: 2003-07-18 22:48:27.959161+02

Comments will probably be found at the Flutterby entry that pointed to this.