Booting Linux from EPROM

This is a quick look at making Linux bootable from EPROM on a 486 single board computer.

This article describes one way to run
Linux in an embedded system with no hard disk. The application
described is an Operator Interface in a monitor and display system
developed by Boeing Flight Test. The airborne environment requires
something fairly rugged which can withstand common power
interruptions. To meet these requirements we decided to build the
operator interface without a hard disk.

Overview

The basic concept includes booting from a solid state disk
(SSD) in Erasable
Programmable
Read-Only
Memory (EPROM), copying a root
file system from EPROM to a RAM disk, loading the operator
interface software from a host and executing it. This article
focuses on the details of how the system works, and on development
techniques used.

The hardware selected is a VME-based Single Board Computer
(SBC) 80486 with 16M of RAM, a PC104 SSD cable of holding a 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.

System Operation

For booting, two options were considered:

booting DOS, then running the loadlin program (to
load Linux) from autoexec.bat

installing LILO and booting Linux directly

The advantage of the second option would be a slightly
shorter boot time. However, we implemented the first option,
because we wanted to use a 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 (see Listing 1,
ramdisk.c). Also, a new block driver was written to read from the
EPROM device (see Listing 2,
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 of the same size as the EPROM, 3.5MB in
this case (the DOS portion of the SSD takes 1/2 MB). Instead, to
allow a larger RAM disk, 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. Listing 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:

Power up and run memory tests

load DOS which executes AUTOEXEC.BAT

run the keyboard programming application

run loadlin—this reads a linux kernel from the DOS
disk & executes it

the linux kernel takes over

load the RAM disk from the EPROM disk

switch the root file system to the RAM disk

init will read inittab which executes dboot instead
of getty

the operator interface application is
started

Development

After the fun part—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:

/dev/hda1 - 80MB “full” Linux system

/dev/hda2 - 6MB EPROM development

/dev/hda3 - 20MB DOS partition

LILO was used to allow booting of either Linux or
DOS.

Programming EPROMs is a time-consuming task and to be avoided
as much as possible. As a result, most of the development is done
using the disk.

The first phase of disk image development was identifying the
required and the 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 something of a trial and error process. I
started with what I thought was needed, then tried running it. When
an error occurred because of a missing program or library, that
file was added. This process went on until the system ran
happily.

The bulk of this was done by copying files from the “full”
Linux partition to the 6MB partition, booting DOS and using the
loadlin line:

loadlin zimage root=/dev/hda2 ro

Once the system was fairly stable, the 6MB partition was
loaded into the RAM disk. This is very similar to how the RAM disk
is loaded from EPROM, but development went faster since EPROMs
weren't being programmed. To test the system without programming
EPROMs, the system booted DOS and ran loadlin with the line:

loadlin zimage root=/dev/hda2 ramdisk=6144 ro

Because of the modification to ramdisk.c, the /dev/hda2 disk image
is loaded into the RAM disk, then the root file system is switched
to the RAM disk. The process of refining the disk image continues
until everything is “perfect”.

Comment viewing options

hello,
I have a BaseMemory of 512KB.
I have A: drive of 2MB where DOS resides.
I have SRAM of 16 MB for other executables storage for my
DOS system.

I would like to know - where should i place the linux ,
so that my handheld(DOS OS) comes with that of linux ?
should i need to place my linux image in the Base Memory ?
SHould i need to place my linux image in the place of
DOS operating system ?

Do give some Good links or tutorials regarding a SBC
design with linux and about a normal embedded linux
based Handheld boot process along with the h/w .