Booting Linux from EPROM
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.
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.
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
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”.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- August 2015 Issue of Linux Journal: Programming