Supporting Linux Without an
operations/control or data acquisition
MMU
Class #407
D. Jeff Dionne
With the advent of energy conscious,
inexpensive and full-featured micro
processors, embedded system
developers now have the opportunity to
capitalize on larger and more user
friendly embedded operating systems
capable of hosting various applications
and protocols. This progress has acted
as a catalyst to direct embedded system
development down two paths; full-
featured X86-like systems and simple
systems. The latter, simple embedded
systems have design requirements
typically focused on two essential
needs, minimized cost and optimized
performance. It is in this realm that the
decision to work with or without a
Memory Management Unit (MMU)
becomes a serious consideration. For
those embedded developers in the initial
design phase who have not yet selected
a processor, or had one thrust upon
them, the attraction to MMUless
technology means also selecting a
careful and realistic balance between
economics and feature set marketing.
After working almost exclusively in the
MMUless space for nearly three years, I
can empathize with those developers
who become tempted by the “forbidden
fruit”, wanting sophisticated applications,
interfaces and protocol stacks all heavily
dependent on memory optimization,
Java, C++, graphic web servers and
sophisticated GUIs. Eventually, the
point must be made that these
objectives really demand an MMU. This
is by no means intended to minimize the
functionality of an MMUless system, in
fact, quite the opposite. MMUless
technology is ideal for what is somewhat
coyly referred to as a “traditional” or
“simple” embedded system. Ideally this
domain is for a device such as simple
system, or a MP3 player or small VPN
router.
One of the common misconceptions
about the uClinux open source project
and MMUless development in general,
is that the only difference between
uClinux and Linux proper (or MMUless
and MMUfull development) is that the
memory management unit has been
simply switched off. Those embedded
developers who have worked in the
MMUless space understand that while
this is literally true, working in a flat
unprotected code space has its
challenges. Let’s take a moment to
examine the differences and motivations
behind working in an embedded MMU-
less environment.
Virtual Memory
Because the basic function of a MMU is
to map the logical addresses of memory
to the physical address, virtual memory
is not possible in a MMUless
environment. This alone creates a
number of obstacles for embedded
developers and is enough to scare away
the faint of heart. Using Linux as an
example, there are three primary
consequences and solutions to
operating without virtual memory.
First, processes loaded by the kernel
must be able to run independently of
their position in memory. This can be
achieved by "fixing up" address
references in a program once it is
loaded into RAM or by generating code
that uses only relative addressing
(referred to as PIC, or Position
Independent Code).
Another consequence occurs due to
memory allocation and deallocation
being within a flat memory model. Very
dynamic memory allocation can result in
fragmentation that may starve a system.
One way to improve the robustness of
applications performing dynamic
memory allocation is to replace
malloc() calls with requests from a
preallocated buffer pool.
Finally, since virtual memory is not used
in uClinux, swapping pages in and out of
memory is not implemented, as no
guarantee can be given that the pages
would be loaded to the same location in
RAM. In embedded systems it is, in any
case, most likely unacceptable to
suspend an application in order to use
more RAM than is physically available.
The role of the MMU to act as a level of
protection for software should never be
minimized. One of the largest difficulties
faced by the developer of an MMU-less
system is the result of invalid program
pointers triggering an address error and
potentially corrupting or downing a
system. Obviously, this is undesirable
and as such requires code to be
programmed and diligently tested to
ensure robustness.
Each step of development must be
carefully mapped out, an overview of
this cycle provides insight.
First, as one might guess, support within
the code for an MMU needs to be turned
off. To account for this change uClinux
provides new code for the memory
management subsystem of the kernel.
Essentially, uClinux provides basic
memory management functions within
the kernel software itself. For those
familiar with uClinux or a Unix like
system, this is the role of the directory
/mmnommu derived from and replacing
/mm.
New strategies also must be developed
for operations like releasing memory
after a process ends or allocating
memory to a new process.
Changes to the kernel are necessary to
run userspace programs. Some
program loaders, such as those for ELF
and COFF, require modifications. New
loaders are required for these formats
(i.e.: binfmt_flat). Futhermore,
since child processes run in the same
address space as their parents, the
behaviour of both may require
modification.
Forking
Within uClinux, the lack of memory
management hardware on a target
processor has meant that some
changes needed to be made to the
system interface. Perhaps the greatest
difference is the absence of the fork()
and brk() system calls.
A call to fork() clones a process to
create a child. Under Linux, fork() is
implemented using copy_on_write
pages. Without an MMU, uClinux cannot
completely and reliably clone a process,
nor does it have access to copy-on-
write.
In the case of uClinux, it implements a
version of BSD’s vfork() in order to
compensate for the lack of fork().
When a parent process calls vfork()
to create a child, both processes share
all their memory space including the
stack. vfork() then suspends the
parent's execution until the child process
either calls exit() or execve(). Note
that multitasking is not otherwise
affected. It does, however, mean that
older-style network daemons that make
extensive use of fork() must be
modified. Since child processes run in
the same address space as their
parents, the behavior of both processes
may require modification in particular
situations.
Many modern programs rely on child
processes to perform basic tasks,
allowing the system to maintain an
interactive "feel" even if the processing
load is quite heavy. Such programs may
require substantial reworking to perform
the same task under uClinux. If a key
application depends heavily on such
structuring, then it may be necessary to
either re-create the application, or an
MMU-enabled processor may also be
needed.
A hypothetical, simple network daemon,
hyped, will illustrate the use of fork().
hyped always listens on a well-known
network port (or socket) for connections
from a network client. When the client
connects, hyped gives it new
connection information (a new socket
number) and calls fork(). The child
process then accepts the client's
reconnection to the new socket, freeing
the parent to listen for new connections.
uClinux has neither an autogrow stack
nor brk() and so user space programs
must use the mmap() command to
allocate memory. For convenience, our
C library implements malloc() as a
wrapper to mmap(). There is a compile-
time option to set the stack size of a
program.
Background Debug Module (BDM) or
others like, JTAG. These protocols give
developers access to the internal status
of the processor and allow for base level
debugging.
uClinux, the open source project has
focused exclusively on the MMUless
space being able to provide the
functionality of a Linux operating system
into a tiny embedded environment. The
valuable experience gained by the core
team and the open source community
has proven that although MMUless
embedded design is more challenging,
there is immense value in an robust,
compatible MMUless operating system.
Furthermore, with newer and more
powerful MMUless processors arriving
on the market, the hardware industry
seems to agree that there is a definite
need for simple, traditional embedded
systems.

Debugging
Debugging an application in an
MMUless environment can also be more
time consuming. Typically, debugging
has to be done at arms length from the
hardware and frequently without a
console, over something simple such as
a serial port. Recently, some silicon
vendors have compounded the
obstacles in debugging. For example, a
lack of memory access alignment error
trapping creates additional debug work.
Without this error trapping built into
hardware, unaligned memory access
errors may pass through the system
without the system reporting it. The
system may still function indefinitely
though usually unreliably. Without this
trapping, developers need to forensically
examine all the code that could have
potentially run on the system to
determine the origin of the alignment
error prior to debugging the underlying
problem. On the other hand, silicon
manufacturers such as Motorola have
offered hardware debug options such as