What is Non-MMU or MMU-less Linux ?

What is Non-MMU or MMU-less Linux ?

by cawan (cawan[at]ieee.org or chuiyewleong[at]hotmail.com)

on 23/11/2012

In olden days, embedded system is always assumed as equivalent to microcontroller
based system design. On the other hand, the development of RISC based microprocessor
is still not mature in terms of technology and production cost. Hence, in those days,
MMU is something luxury to be implemented in both microcontroller or microprocessor.
However, in nowadays, MMU is almost a built-in feature in majority of RISC processors.
Of course, some low-end RISC processor such as ARM-M4 does not come with MMU, but it
is almost a legacy. In fact, the unit price of a standard RISC processor such as
ARM-A5 is almost closed to $5, therefore, there is no more substantial reason to use
those low-end RISC processors which are without MMU. Yes, this is from the angle of
embedded system, however, the existence of MMU in microcontroller is still an
argument. Due to the demand of low-cost in microcontroller, it is normally with much
lower clock speed, memory space support, number of register, and etc. So, it is a
little bit unreasonable to implement MMU in microcontroller. On the other hand, from
software perspective, code reusability is really a trend in reducing the time-to-market
of a product. Besides, the complexity of its features are getting higher and higher.
Try to imagine, is it a standard feature for an embedded product to access remote
shared folder which is hosted in a PC within the same network ? Is it a daunting
process to develop NFS or SAMBA by your own again and again in different platform ?
Yes, it is really terrible, and that's why we need a linux kernel. With the linux
kernel, then it is up to your cross-compilation skill to migrate those useful modules
such as FUSE, SAMBA, NFS and USB into your own platform in a short period of time.

Well, the discussion come to linux kernel now. As what we know, linux kernel is
designed for PC based platform, not embedded platform. In other words, linux kernel
expects to have MMU to run in proper. However, due to the power of open source, it
has been modified to run in non-MMU platform, and it is known as uClinux. In uClinux,
the memory address is directly mapped to the physical address, and there is no
protection among different processes. So, it is very possible for a process to
corrupt another process and causes the system crash. Anyway, let us assume the
uClinux itself is robust to run, and we focus our discussion in user application.
Majority of the user applications use fork() to spawn new child process. In the
process of fork(), the parent process will be duplicated to the new process.
After that, both of the process with run together. However, in most of the times,
the child process will eventually call execve(), and pass the process environment
to the new program. Yes, such action is really wasting the precious memory space.
So, in recent version of linux kernel, the fork() process has been rectified to
make use the concept of copy-on-write. Thus, the parent process will not be forced
to duplicate over to the child process, unless any write action being detected. Fine,
the fork() process is much optimized now. But, in order to perform copy-on-write,
MMU is necessary. So, fork() must be changed to support non-MMU platform. In uClinux,
vfork() is the alternative. With vfork(), the child process will borrow the address
space of the parent process. While the child process is running, the parent process
will be suspended until the child process calls _exit() or execve(). In this case,
only one process is running at a specific time. But, since they are both running in
the same process space, it is easily for a child process to corrupt the structure of
the parent process. The blame is reasonable because majority of the open source
applications are developed under the environment with MMU. In fact, they are valid
for "full" linux, but not for such "customized" linux. So, in order to run an
existing open source application in uClinux, heavy and serious modification is needed
for the attempt. Well, this is a very subjective issue to justify either is it worth
to spend times and resources in doing such modification. However, for the case of
developing new application, then uClinux is really a good choice. By implementing the
codes in proper, it should work well in uClinux. In fact, we suppose to say that the
codes can run in all uClinux compatible platform with minor modification such as the
redefinition of I/O addresses and etc. Anyway, such so called non-MMU or MMU-less
linux is really a legacy in embedded system. Instead, with a cost-effective RISC
processor in mid-range feature such as ARM-A8, it is no problem at all to support
full linux kernel. So, with full linux kernel, it is comfortable to perform cross
compilation of open source applications as usual again, and let them to work together
with our own codes.
 
pdf version:

http://www.scribd.com/doc/114197048/What-is-Non-MMU-or-MMU-Less-Linux