Embedding Linux in a Commercial Product

Another feature of standard Linux is its virtual memory
capability. This is that magical feature that enables application
programmers to write code with reckless abandon, without regard to
how big the program is. The program simply overflows onto the swap
area of the disk. In an embedded system without a disk, this
capability is usually unavailable.

This powerful feature is not needed in an embedded system. In
fact, you probably do not want it in real-time critical systems,
because it introduces uncontrolled timing factors. The software
must be more tightly engineered to fit into the available physical
memory, just like other embedded systems.

Note that depending on the CPU, it is usually advisable to
keep the virtual memory code in Linux, because cutting it out
entails quite a bit of work. Also, it is highly desirable for
another reason—it supports shared text, which allows multiple
processes to share one copy of the software. Without this, each
program would need to have its own copy of library routines like
printf.

The virtual-memory paging capability can be turned off simply
by setting the swap space size down to zero. Then if you write
programs that are bigger than actual memory, the system will behave
the same way as it does when you run out of swap space; the program
will not load, or perhaps a malloc
will fail, if the program asks for too much memory.

On many CPUs, virtual memory also provides memory management
isolation between processes to keep them from overwriting each
other's address space. This is not usually available on embedded
systems which just support a simple, flat address space. Linux
offers this as a bonus feature to aid in development. It reduces
the probability of a wild write crashing the system. Many embedded
systems intentionally use “global” data, shared between processes
for efficiency reasons. This is also supported in Linux via the
shared memory feature, which exposes only the parts of memory
intended to be shared.

File Systems

Many embedded systems do not have a disk or a file system.
Linux does not need either one to run. As mentioned before, the
application tasks can be compiled along with the kernel and loaded
as one image at boot time. This is sufficient for simple systems.
However, it lacks the flexibility described previously.

In fact, if you look at many commercial embedded systems,
you'll see that they offer file systems as options. Most are either
a proprietary file system or an MS-DOS-compatible file system.
Linux offers an MS-DOS-compatible file system, as well as a number
of other choices. The other choices are usually recommended,
because they are more robust and fault-tolerant. Linux also has
check and repair utilities, generally missing in offerings from
commercial vendors. This is especially important for flash systems
which are updated over a network. If the system loses power in the
middle of an upgrade, it can become unusable. A repair utility can
usually fix such problems.

The file systems can be located on a traditional disk drive,
on flash memory, or any other media for that matter. Also, a small
RAM disk is usually desirable for holding transient files.

Flash memories are segmented into blocks. These may include a
boot block containing the first software that runs when the CPU
powers up. This could include the Linux boot code. The rest of the
flash can be used as a file system. The Linux kernel can be copied
from flash to RAM by the boot code, or alternatively, the kernel
can be stored in a separate section of the flash and executed
directly from there.

Another interesting alternative for some systems is to
include a cheap CD-ROM drive. This can be cheaper than flash
memory, and supports easy upgrades by swapping CD-ROMs. With this,
Linux simply boots off the CD-ROM and gets all of its programs from
the CD-ROM in the same way it would from a hard disk.

Finally, for networked embedded systems, Linux supports NFS
(Network File System). This opens the door for implementing many of
the value-added features in networked systems. First, it permits
loading the application programs over a network. This is the
ultimate in controlling software revisions, since the software for
each embedded system can be loaded from a common server. It is also
useful, while running, to import and export a plethora of data,
configuration and status information. This can be a very powerful
feature for user monitoring and control. For example, the embedded
system can set up a small RAM disk, containing files which it keeps
updated with current status information. Other systems can simply
mount this RAM disk as a remote disk over the network and access
status files on the fly. This allows a web server on another
machine to access the status information via simple CGI scripts.
Other application packages running on other computers can easily
access the data. For more complex monitoring, an application
package such as MatLab
(http://www.mathworks.com/products/matlab/)
can easily be used to provide graphical displays of system
operation at an operator's PC or workstation.