Embedded Linux

Jelena Ignjatovic, Middlebury College, Middlebury, Vermont

Mentor: Duane Edgington
Summer 2002
Keywords: RAM ARM glibc uClibc bash ash

ABSTRACT

This paper describes the techniques that can create an embedded Linux kernel and embedded
Linux applications small enough to fit into in 5.25MB of RAM, leaving up to 1.5MB free for
user application code. All the results discussed in the paper are based on the experiments with
the Intrinsyc Linux distribution designed for Intrinsyc CerfCube device, which is running the
Intel StrongARM 1110 processor with 32MB of SDRAM and 16MB of flash memory.

INTRODUCTION

Under the GNU General Public License every Linux developer is required to make their source
code free and publicly available. Following this rule, Linux developers such as Intrinsyc Inc.
may charge a fee for their software, but they are required to publicly provide their entire Linux
development environment together with their final Linux distribution. For this reason, a Linux
installation CDROM contains all the relevant parts of the development process starting with C
programs and compilation Makefiles and ending with the image of the Linux kernel and
application executables. Given all the components of an existing Linux package, a Linux user
can rebuild the final components or make changes and replacements within the original package
and create a new distribution that satisfies his particular needs. This result of the Linux GNU
Licence agreement is extremely important for the development of the huge variety of small
embedded devices running Linux. A small Linux device, which can be anything from server
appliance, data collection device, a scanner or an office automation product, is defined by a set
of different and very specific physical limitations such as RAM size, power consumption, or real
time requirements. For this reason, each embedded Linux distribution meets different and very
specific software requirements, and it is entirely applicable only to the specified target device.
However, despite the physical characteristics of different embedded targets, the RAM size
reduction appears to be a common requirement for most of the embedded devices. Unfortunately,
there is no common technique that can reduce the RAM size requirement of a given embedded
Linux distribution. For that reason, this paper considers how the components of different Linux
distirbutions such as Intrinsyc, µClinux, and debian can be selected and combined in order to
reduce the amount of RAM used by Linux-2.4.9 kernel, by Intrinsyc Linux application programs,
and, most likely, by any other ARM Linux applications.

HARDWARE PLATFORM

Intrinsyc CerfCube includes low power Intel StrongARM 1110 microprocessor @192MHz, 16
MB Intel StrataFlash memory, 32MB SDRAM, 3 RS232 serial ports, 5.0VDC power, 10 Base-T
Ethernet, and type I/II CF/CF+ Compact Flash.

The development platform used was an i686 host machine running Redhat Linux 7.2, which is
connected to the CerfCube through one of the serial ports. The CerfCube was also connected to
the network via its 10-Base-T Ethernet connection.

LINUX PACKAGES

Intrinsyc Linux distribution, which is provided on the original Intrinsyc CDROM together with
the actual CerfCube device, includes a set of tool packages and a set of target packages. The tool
packages are used to build the arm-linux-gcc compiler, which is used to compile the C programs
and object files that constitute the target packages.

Intrinsyc tool packages include the following:

binutils-2.10
gcc-2.95.
gcc-2.95.3-pb-icefix.p
glibc-2.1
glibc-crypt-2.1
glibc-linuxthreads-2
linux-2.4
Intrinsyc target packages include the following:

bash-2.04 initscripts-5.00 modutils-2.4.0 sh-utils-2.0

bluez-1.2 ioctl-0.0.1 ncurses-5.2 sysvinit-2.78
busybox-0.48 joe-2.8.color.5 net-tools-1.59 tcp_wrappers_7.6
dhcpcd-1.3.19-pl1 ld.so-1.9.9 pcmcia-cs-3.1.27 tinylogin-0.80
glibc-2.1.3 legacy popt-1.2 wu-ftpd-2.6.1
grep-2.4.2 less-358 portmap_4 xfree86-20010627
gzip-1.2.4 linux-2.4.9 procps-2.0.7 xvkbd-1.2
icewm-1.0.8-6 linux-mtd-20010926 readline-4.1 zlib-1.1.3
inetutils-20010404 mad-0.13.0b setserial-2.17

One of the alternative tool packages considered is uClibc 0.9.12 tool-chain consisting of
binutils-2.12, gcc-2.95-uclibc-20020524, uClibc-0.9.12, and Linux-2.4.9. This package is used to
build the arm-uclibc-gcc compiler.

The other alternative tool package considered is uClinux ARM-tool package which contains
already built ARM executables and arm-elf-gcc compiler. This set of executables was
complemented by the following RPMs from another uClinux source:

arm-elf-binutils-2.11-5.i386.rp
arm-elf-gcc-2.95.3-4.i386.rp
arm-elf-gdb-5.0-2.i386.rpm

Alternative target shell package considered is archived Debian ash shell ash-0.2-0 downloaded
from http://archive.debian.org/debian-archive/dists/Debian-1.1/source/shells/.

For development purposes the following RPMs were installed on the host machine in order to set
up DHCP and TFTP servers:

xinetd-2.1.8.9pre14-6.rpm
dhcp-2.0p15-4.i386.rpm
tftp-server-0.17-9.i386.rpm
linuxconf-1.24r2-10.i386.rpm

In order to establish the serial communication between the host and the cube, minicom was run
on the host machine. Additionally, the Intrinsyc iBoot bootloader1 was installed on the
development cube.

1
The Intrinsyc iBoot bootloader commands are summarised under the Appendix 3 of the original
Intrinsyc CerfCube for Linux Software User Guide.
For the purpose of installing and testing the NFS client on the cube, it is desirable to run NFS
server on the host machine.2
Intrinsyc Cerfcube (top, left, & bottom)

(top, left side & bottom)

2
The details related to NFS are summarised under the NFS section of the Guide document.
RESULTS

The following output contains the RAM memory usage information for the Intrinsyc CerfCube
running the Intrinsyc Linux kernel and Intrinsyc application programs outlined above. All of the
programs displayed in the output below were statically and dynamically linked to glibc libraries.

[cubeuser@CerfLinux cubeuser]$ ps v -A

PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND

1 ? S 0:04 51 318 37 224 0.7 init

2 ? SW 0:00 0 0 0 0 0.0 [keventd]

4 ? SWN 0:00 0 0 0 0 0.0 [ksoftirqd_CPU0]

5 ? SW 0:00 0 0 0 0 0.0 [kswapd]

6 ? SW 0:00 0 0 0 0 0.0 [kreclaimd]

7 ? SW 0:00 0 0 0 0 0.0 [bdflush]

8 ? SW 0:00 0 0 0 0 0.0 [kupdated]

9 ? SW 0:00 0 0 0 0 0.0 [mtdblockd]

10 ? SWN 0:00 0 0 0 0 0.0 [jffs2_gcd_mtd3]

37 ? S 0:00 32 248 1127 508 1.6 klogd

38 ? S 0:00 34 248 1135 524 1.7 syslogd

39 ? S 0:00 64 17 1506 680 2.2 inetd /etc/inetd.conf

46 ? S 0:00 1 248 1135 528 1.7 syslogd

51 ? S 0:00 32 248 1127 516 1.6 klogd -m 0

52 ? S 0:00 34 248 1135 532 1.7 syslogd -m 0

63 ? S 0:00 55 30 1133 572 1.8 portmap

73 ? S 0:00 76 17 1522 736 2.3 inetd /etc/inetd.conf

74 ? S 0:00 1 248 1135 536 1.7 syslogd -m 0

84 ? S 0:00 48 34 1137 624 2.0 /sbin/cardmgr

91 ? S 0:00 1 248 1135 536 1.7 syslogd -m 0

105 ? S 0:00 1 31 1048 504 1.6 /usr/sbin/dhcpcd -h cube

107 ? S 0:00 1 248 1135 536 1.7 syslogd -m 0

108 ? S 0:00 110 34 1261 460 1.4 /sbin/getty -L ttySA0 38

110 ? S 0:00 205 23 2088 856 2.7 telnetd

111 ttyp0 S 0:00 182 800 1235 796 2.5 /bin/sh /usr/bin/login -

112 ttyp0 S 0:00 348 800 1347 1096 3.5 -sh

117 ttyp0 R 0:00 165 63 2284 724 2.3 ps v -A

It is important to point out that the total of 30692KB of memory available is a portion of the
32MB of total RAM available, and it does not count 1229KB of code, 260KB of data, and 48KB
of ‘init’ memory.
The process status report above indicates process sizes given in terms of RSS values. RSS is
defined as the total amount of physical memory used by the task, in kilobytes.

After the original Intrinsyc target packages had been rebuilt with the arm-uclibc-gcc compiler,
the following output was generated:

[cubeuser@CerfLinux /]$ ps v -A

PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND

1 ? S 0:03 17 59 40 100 0.3 init

2 ? SW 0:00 0 0 0 0 0.0 [keventd]

4 ? SWN 0:00 0 0 0 0 0.0 [ksoftirqd_CPU0]

5 ? SW 0:00 0 0 0 0 0.0 [kswapd]

6 ? SW 0:00 0 0 0 0 0.0 [kreclaimd]

7 ? SW 0:00 0 0 0 0 0.0 [bdflush]

8 ? SW 0:01 0 0 0 0 0.0 [kupdated]

9 ? SW 0:00 0 0 0 0 0.0 [mtdblockd]

10 ? SWN 0:00 0 0 0 0 0.0 [jffs2_gcd_mtd3]

19 ? SW< 0:00 0 0 0 0 0.0 [loop0]

22 ? SW< 0:00 0 0 0 0 0.0 [loop1]

40 ? S 0:00 10 247 400 252 0.8 klogd

41 ? S 0:00 12 247 404 264 0.8 syslogd

42 ? S 0:00 14 17 514 300 0.9 inetd /etc/inetd.conf

47 ? S 0:00 1 247 404 268 0.8 syslogd

53 ? SN 0:00 9 247 400 248 0.8 klogd -m 0

54 ? SN 0:00 12 247 404 264 0.8 syslogd -m 0

65 ? SN 0:00 56 30 1089 580 1.9 portmap

75 ? SN 0:00 16 17 514 308 1.0 inetd /etc/inetd.conf

76 ? SN 0:00 1 247 404 268 0.8 syslogd -m 0

86 ? S 0:00 19 34 497 388 1.2 /sbin/cardmgr

94 ? SN 0:00 1 247 404 268 0.8 syslogd -m 0

99 ? SN 0:00 1 247 404 268 0.8 syslogd -m 0

102 ? S 0:00 0 32 391 288 0.9 /usr/sbin/dhcpcd -h Cube

105 ? SN 0:00 1 247 404 268 0.8 syslogd -m 0

153 ? S 0:00 101 23 1008 472 1.5 telnetd

154 ttyp0 S 0:00 72 555 92 328 1.0 /bin/sh /usr/bin/login -

155 ttyp0 S 0:00 168 555 152 544 1.7 -sh

160 ttyp0 R 0:00 159 63 2224 696 2.2 ps v -A

The summary of the two given outputs is given in the graph below. The graph illustrates how the
RSS size of the chosen ARM executables linked to glibc libraries significantly decreases after
these executables are recompiled and linked to uClibc libraries.

ARM executables built with uClibc and glibc tools

1200
How much RAM do they use?
1MB
1000

800

600
uClibc
glibc
400

200

0
init bash inetd dhcpd
telnetd
syslogd cardmgr

It is possible to further reduce the amount of RAM used by the kernel and user applications if
Linux kernel is configured to use less than 32MB of RAM. The following graph illustrates how
the amount of used and cached memory decreases depending on the amount of RAM
assigned to the system on kernel configuration.
 Configuring the Linux kernel
32

24

Cache
16
Used Memory
RAM
8

0
32 MB 8 MB 6 MB 5 MB

The following graph illustrates how the RSS size of the chosen ARM executables significantly
decreases depending on the amount of RAM assigned on kernel configuration3.

3
All the displayed executables are compiled with uClibc tools.
 Used Memory vs. Available RAM

600

0.5MB
500

400
32MB
300
8MB
6MB
200 5MB

100

0
init bash inetd cardmgr dhcpd
Once the kernel is configured to use less than 32MB of RAM, it is possible to further reduce the
amount of RAM used by the kernel and user applications. For instance, some of the system
deamons and loggers that appear in the previous outputs can be disabled. Additionally, the
smaller ash shell can replace the space consuming bash shell. Assuming that the target device
should provide TCP/IP network protocol, NFS client, and compact flash support, it is possible to
modify the original Intrinsyc kernel and file system to run on 5.25MB of RAM. The following
output is generated as a result of suggested modifications.

$ free

total used free shared buffers cached

Mem: 3340 2996 344 0 4 1240

-/+ buffers/cache: 1752 1588

$ ps v -A

PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND

1 ? S 0:03 226 59 44 44 1.3 init

2 ? SW 0:00 0 0 0 0 0.0 [keventd]

4 ? SWN 0:00 0 0 0 0 0.0 [ksoftirqd_CPU0]

5 ? SW 0:00 0 0 0 0 0.0 [kswapd]

6 ? SW 0:00 0 0 0 0 0.0 [kreclaimd]

7 ? SW 0:00 0 0 0 0 0.0 [bdflush]

8 ? SW 0:00 0 0 0 0 0.0 [kupdated]

9 ? SW 0:00 0 0 0 0 0.0 [mtdblockd]

10 ? SWN 0:00 0 0 0 0 0.0 [jffs2_gcd_mtd3]

19 ? SW< 0:00 0 0 0 0 0.0 [loop0]

22 ? SW< 0:00 0 0 0 0 0.0 [loop1]

62 ? SN 0:00 151 17 514 96 2.8 inetd /etc/inetd.conf

94 ? S 0:00 22 32 391 84 2.5 /usr/sbin/dhcpcd -h Cube

99 ttySA0 S 0:00 469 96 391 84 2.5 -sh

112 ? SW 0:00 0 0 0 0 0.0 [rpciod]

113 ? SW 0:00 0 0 0 0 0.0 [lockd]

122 ttySA0 R 0:00 344 63 2220 604 18.0 ps v -A

DISCUSSION

Deamons & Loggers

Given a commercial Linux package, it is possible to simply reduce the total amount of RAM
used by Linux kernel and Linux applications by disabling the unnecessary application programs
such as deamons and system loggers. For example, syslogd deamon, which reads and forwards
system messages to the appropriate log files, is not essential on an embedded system. For
instance, on a device that runs independently for a considerable amount of time, the constantly
increasing log file can possibly disable the whole system. Similarly, it is reasonable to disable
the minilogd deamon, which replaces syslogd once syslogd is disabled. Likewise, in the case of a
data logger embedded device that does not use NFS at all times or does not support compact
flash hot swapping, it is not necessary to always run deamons such as portmap and cardmgr.
portmap deamon provides mapping between RPC (Remote Procedure Call) program numbers
and DARPA protocol port numbers, so portmap must be running in order to make RPC calls
used by NFS services. If the NFS server is running, the client system then contacts portmap on
the server with a particular RPC program number. portmap on the server then redirects the client
to the proper port number to communicate with its intended service. For this reason, it is required
to always run portmap on the NFS server. However, there is no need to always run the portmap
on an NFS client such as CerfCube. If portmap is disabled after the client performs an NFS
mount, the client will still be able to access the mounted directory. Similarly, cardmgr is needed
only on compact flash card insertion, and after the flash card is inserted cardmgr can be disabled.
In addition, if TCP/IP support is required, it is not necessary to run multiple copies of the inetd
deamon, so the duplicates can be disabled by editing the /etc/rc.d/rc.sysinit initialisation script.
Libraries

The total amount of RAM used by a Linux distribution can be somewhat reduced, if the
unnecessary components of the distribution are excluded. However, the same goal can be
achieved in a more complicated, but, at the same time, much more effective way -- by changing
the building components of the entire distribution. The main building components or the main
elements of a tool-chain of each Linux distribution are binary utilities (assembler and linker), C
compiler, C library, and Linux kernel. Among the common tool-chain components, C library is
the most relevant for the RAM usage of the Linux applications. The shared C libraries are loaded
directly into RAM, so their size significantly determines the total RAM usage. Instead of glibc
library package included in Intrinsyc Linux distribution, several small library packages such as
uClibc, sglibc4, dietlibc, newlib, or libc5 are recommended for building the embedded Linux
systems. However, in order to use these packages to build a Linux tool-chain, one has to match
them with the appropriate binary utilities and appropriate C compiler gcc package. A typical
tool-chain is built according to the diagram below. The binutils package is built first, so that the
other packages can use the binutils. The arrow 1 indicates that after binutils are built the libc?5
include files are hacked in preparation for the first pass gcc build suggested by the arrow 2. After
the first pass gcc compiler is built, the library is compiled using gcc as the arrow 3 indicates.
Finally, the arrow 4 points towards the second pass gcc compiler, which is now built targeting
the newly built shared libc? library. According to this diagram, in order to create a complete set
of building tools, one has to implement all the transitional steps marked by the arrows 1-4
between the tool packages below.

Tools

binutils

libc?

gcc

Unlike the other small libraries, uClibc provides not only a library package, but it also includes
the binary utilities and gcc package for tool-chain development. The uClibc tool-chain can be
installed on the host machine and used to rebuild the target packages. If one wants to rebuild the
Intrinsyc target packages from Intrinsyc CDROM, then they have to use the package Makefiles
from the same CDROM. Each of these Makefiles specifies how a particular target package
should be compiled. For that reason, each Makefile defines arm-linux-gcc as the default compiler
and the path to the Intrinsyc tool-chain as the default development tool path. For the purpose of
recompiling all the Intrinsyc code with uClibc tools, one may need to rename arm-linux-gcc to
arm-uclibc-gcc (and any Intrinsyc tool to its uClibc equivalent) within each Makefile within each
CerfCube package. This seems to be extremely tedious, and, it is much simpler just to rename

4
slibc is a small glibc-compatible C runtime library subset suitable for embedded systems.
5
libc? could be uClibc, glibc, or any other library.
the tools from ‘arm-uclibc-*’ to ‘arm-linux-*’ and ‘trick’ the Makefiles by giving them altered
tool path to these renamed uClibc tools. In addition, it is necessary to remove the glibc library
package from the list of packages that get installed on the cube. In that way, the root file system
is built with empty /lib directory. The /lib with all the uClibc shared libraries can be manually
inserted into the root file system after /bin, /sbin, and all the other root directories are built. The
content of the inserted /lib directory (all the .so files and the links to .so files) can be the same as
the content of the tool-chain library /lib – the shared libraries from the tool-chain can be simply
copied into the target /lib. The /usr/lib can be inserted in a similar way.

Unfortunately, within the Makefiles referring to glibc based cc tool, there is no possible ‘arm-
uclibc-cc’ equivalent in the considered version of the uClibc tool-chain, so the executables
created according to such Makefiles may have to remain linked to glibc libraries. In order to
enable such executables to run, it is possible to include a few shared glibc libraries into the target
/lib directory.

ash

Apart from trimming and rebuilding the target packages to reduce the RAM requirement, another
alternative worth considering is package replacement. The ash user shell can be installed as
/bin/sh, it executes scripts somewhat faster than bash, and it depends on fewer libraries.
Although bash has more features and, therefore, may seem to be the preferable users’ choice, ash
uses roughly twice less RSS memory than bash. bash is a required part of Intrinsyc file system,
because ash does not completely support the Intrinsyc initialisation shell scripts. However,
/bin/sh can be linked to ash, so that the amount of memory used by sh is significantly reduced, as
the results summarised above suggest.

Configuring the Kernel & Reducing the Caches

Depending on the system requirements, a Linux kernel configured for a particular hardware
platform, can be re-configured, so that the physical requirements such as RAM or flash size can
be changed and features such as TCP/IP, NFS or PCMCIA support can be added or removed. For
the purpose of reducing the RAM memory usage, it is reasonable to redefine the amount of RAM
available to the kernel, so that the kernel allocates its limited memory resources more efficiently.
The kernel .config file usually gives the option of setting the RAM size to standard values of
32MB, 16MB, or 8MB. However, it is possible to edit the appropriate memory configuration C
function, so that RAM size can be set to any desired value. Changing the RAM size significantly
reduces the kernel memory footprint, and, primarily, the size of cached memory. The results
displayed above suggest that the same Linux kernel can reduce the size of caches from 5480KB
given 32MB of RAM to only 1240KB if configured to use only 5.25MB of RAM6. Apparently,
the 5.25MB of RAM does not seem to leave much room for possible user application leaving
only ~350KB of free memory. However, depending on the application load, the size of cache can
be further reduced down to ~10KB giving away ~1200KB to the user application7.
ARM compiler

Apart from glibc based arm-linux-gcc compiler and uClibc based arm-uclibc-gcc, an alternative
ARM compiler that can be used to generate ARM executables is arm-elf-gcc from µClinux
distribution, based on newlib small libraries. The considered µClinux arm-elf tool-chain includes
only static newlib libraries and no shared libraries8, so the executables built with arm-elf tools are
bigger in code size than their arm-linux equivalents. However, they may consume less memory
than executables linked to shared libraries. A simple arm-elf ‘Hello World’ executable is about
fifteen times bigger in code but consumes twice less memory than its arm-uclibc equivalent. On
the other hand, the bash executable built with arm-elf is about three times bigger, but it
consumes the same amount of space, regardless of the compiler. With reference to these results,
arm-elf-gcc and newlib may not be the best tools for building the entire file system. However,
these tools may be worth considering as an alternative for building a user application that could
be added to the system.

CONCLUSIONS & RECOMMENDATIONS

The considered Linux packages are a combination of robust well-documented stable distributions
and alternative open source packages. Packages such as uClibc do not offer as detailed
documentation as GNU or Intrinsyc, but once implemented, they can generate great results. If the
lack of documentation is a problem, then reading and editing the simply coded Makefiles seems
to be helpful. Another problem related to package replacement within a given distribution is that
it is often necessary to ‘fill the gaps’ within a package in order to use such package as a
replacement part within the existing distribution. For example, in order to build the arm-elf-gcc
compiler from the µClinux sources, it may be necessary to combine arm-elf RPMS and a

6
It would be possible to redefine the kernel using 5MB or only 4MB of RAM, but in that case
the compact flash support would not be feasible. If the cardmgr is initialised, the kernel footprint
exceeds 5MB of RAM on system boot-up.
7
In addition to the ~350KB of free memory, this sums up to ~1550KB available for the user
application.
8
Both newlibc and dietlibc ARM packages contain no shared libraries. dietlibc supports shared
libraries only on i386 architectures.
different arm-elf tool-chain distribution. Similarly, if a few executables from arm-linux tool-
chain are missing from the arm-uclibc tool-chain, these executables can be copied and added to
the arm-uclibc set of tools. The same applies to glibc and uClibc libraries.

If the alternative unstable open source packages are implemented, it is extremely important to
keep track of the package updates. For example, if a tool-chain such as uClibc has just been
released, then that may be quite useful for a Linux user trying to include the uClibc library
package into some other functional tool-chain or for a Linux developer trying to build the entire
tool-chain from scratch.

The considered small Linux that can fit into 5.25MB of SDRAM supports the following features:

• TCP/IP network protocol

• telnet and FTP9

• Network File System: NFS

• serial port

• compact flash

Such Linux system leaves up to 1.5MB for user applications, and, therefore, it can be potentially
used as a data logger, which can be deployed for long periods of time (e.g. months) while using
as little battery power as possible to keep the SRAM10 constantly refreshed. However, depending
on the nature of the logged data, some additional requirements may arise. For example, the influx
of logged data can impose a real-time requirement. The considered small system running on
5.25MB of RAM is slightly slower than the Linux running on 32MB of RAM, so it may not be
suitable for a real-time user application. If this particular Linux is used as a data logger, the
amount of RAM assigned on kernel configuration may have to be increased to support bigger
buffers and caches, which can continuously log data at the desired speed. In order to increase the
buffer memory size alone, it is possible to manually adjust the virtual memory parameters within

9
MBARI Software Engineer Brent Roman succeeded in making the telnet and FTP components
of the Intrinsyc system much smaller than the telnet and FTP components considered here. He
manipulated with ncurses cross-libraries in order to achieve this and his telnet and FTP
components could possibly be added to this system. Therefore, there is still room for
improvements of the considered small Linux.
10
Regarding the power consumption, the actual size of the built in physical SDRAM component
is considered here. The physical SDRAM is likely to be 8MB or a multiple of 2MB.
/proc/sys/vm/buffermem file11. However, there is no equivalent file that regulates the cache size
parameters, so, in order to manipulate with the cache sizes, some kernel hacking may be
necessary.

If both the real-time user application and the networking capability are required, then the revised
and minimized Intrinsyc distribution could also be used in a distributed computing system. For
example, such system can include two CPUs. One of these CPUs can be a ‘front-end’
networking processor and the other can be a ‘back-end’ application processor. In this system, a
device such as the CerfCube may be implemented as the front-end networking processor
assisting some other main CPU. For example, NET+ARM12 system-on-chip, which is similar to
the CerfCube in its architecture and network capabilities, has already been implemented as the
described ‘networking processor;’ the system-on-chip is used to off load all the real-time
networking and I/O activity from another application processor. Such distributed computing
alternative with two CPUs seems worth considering for a data logger regarding the real-time
data-logging requirement. However, a system based on separate networking and application
units is likely to require more RAM then a system with the single processor. Both this distributed
computing alternative and the previously considered idea of making bigger caches indicate that
the RAM size has to be increased in order to support a real-time user application. Unfortunately,
this sort of tradeoff between the RAM size reduction and the real time improvements seems to be
inevitable.

ACKNOWLEDGEMENTS

I would like to thank my Mentor Duane Edgington for giving me the opportunity to work with
embedded Linux and for giving me the opportunity to interact with MBARI Software
Engineering team. I would also like to thank Duane Edgington for allowing me to improvise and
experiment, for providing me with all sorts of written materials, a bunch of Embedded Linux
Journals, and a couple of real CerfCube-s. Also, I really have to thank Mike Risi, “my acting
Mentor,” for answering my numerous everyday questions, for providing me with compact flash
cards, and for explaining all about the CerfCube, NFS, deamons, and very many other details. I
would also like to thank Brent Roman for thoroughly answering my sporadic questions, as well
as to thank Karen Salamy, Danelle Cline and Paul McGill for giving importance to my project
and explaining how my CerfCube Linux can be used for a functional LP2 seismic data logger
device.

11
The details regarding /proc/sys/vm/buffermem file are explained in The Linux Documentation
Project: Securing and Optimizing Linux: RedHat Edition -A Hands on Guide
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec69.html
12
NET+ARM runs uClinux kernel on the ARM7 RISC processor.
References & Links:
Fischer, Todd Who needs excess baggage? Dr. Dobb's Journal (May 2002)

Lombardo, John (2002) Embedded Linux New Riders Publishing; 1st edition

Rubini, Alessandro Are You Ready To Build Your Own Linux Kernel? Linux Magazine (November 1999)

Weinberg, Bill Embedded Linux for Intel SA-1110 handheld and wireless applications Electronic Engineering
Design Magazine (May 2002)

Welsh, Matt, Kalle Dalheimer, Matthias, Kaufman, Lar (1999) Running Linux O'Reilly & Associates; 3rd edition

Linux Performance Tunning: Kernel Tuning http://linuxperf.nl.linux.org/general/kerneltuning.html

dietlibc shared libraries - a libc optimized for small size http://packages.debian.org/unstable/devel/dietlibc.html

NET+ARM® Ethernet-ready System-on-Chip http://www.netsilicon.com/EmbWeb/products/netarm.asp