Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Linux Without MMU

Linux Without MMU

Ratings: (0)|Views: 403|Likes:
Published by melvin45

More info:

Published by: melvin45 on Nov 10, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Supporting Linux Without anMMUClass #407
D. Jeff Dionne
With the advent of energy conscious,inexpensive and full-featured microprocessors, embedded systemdevelopers now have the opportunity tocapitalize on larger and more userfriendly embedded operating systemscapable of hosting various applicationsand protocols. This progress has actedas a catalyst to direct embedded systemdevelopment down two paths; full-featured X86-like systems and simplesystems. The latter, simple embeddedsystems have design requirementstypically focused on two essentialneeds, minimized cost and optimizedperformance. It is in this realm that thedecision to work with or without aMemory Management Unit (MMU)becomes a serious consideration. Forthose embedded developers in the initialdesign phase who have not yet selecteda processor, or had one thrust uponthem, the attraction to MMUlesstechnology means also selecting acareful and realistic balance betweeneconomics and feature set marketing.After working almost exclusively in theMMUless space for nearly three years, Ican empathize with those developerswho become tempted by the “forbiddenfruit”, wanting sophisticated applications,interfaces and protocol stacks all heavilydependent on memory optimization,Java, C++, graphic web servers andsophisticated GUIs. Eventually, thepoint must be made that theseobjectives really demand an MMU. Thisis by no means intended to minimize thefunctionality of an MMUless system, infact, quite the opposite. MMUlesstechnology is ideal for what is somewhatcoyly referred to as a “traditional” or“simple” embedded system. Ideally thisdomain is for a device such as simpleoperations/control or data acquisitionsystem, or a MP3 player or small VPNrouter.One of the common misconceptionsabout the uClinux open source projectand MMUless development in general,is that the only difference betweenuClinux and Linux proper (or MMUlessand MMUfull development) is that thememory management unit has beensimply switched off. Those embeddeddevelopers who have worked in theMMUless space understand that whilethis is literally true, working in a flatunprotected code space has itschallenges. Let’s take a moment toexamine the differences and motivationsbehind working in an embedded MMU-less environment.
Virtual Memory
Because the basic function of a MMU isto map the logical addresses of memoryto the physical address, virtual memoryis not possible in a MMUlessenvironment. This alone creates anumber of obstacles for embeddeddevelopers and is enough to scare awaythe faint of heart. Using Linux as anexample, there are three primaryconsequences and solutions tooperating without virtual memory.First, processes loaded by the kernelmust be able to run independently oftheir position in memory. This can beachieved by "fixing up" addressreferences in a program once it isloaded into RAM or by generating codethat uses only relative addressing(referred to as PIC, or PositionIndependent Code).Another consequence occurs due tomemory allocation and deallocationbeing within a flat memory model. Verydynamic memory allocation can result infragmentation that may starve a system.One way to improve the robustness of
applications performing dynamicmemory allocation is to replace
calls with requests from apreallocated buffer pool.Finally, since virtual memory is not usedin uClinux, swapping pages in and out ofmemory is not implemented, as noguarantee can be given that the pageswould be loaded to the same location inRAM. In embedded systems it is, in anycase, most likely unacceptable tosuspend an application in order to usemore RAM than is physically available.The role of the MMU to act as a level ofprotection for software should never beminimized. One of the largest difficultiesfaced by the developer of an MMU-lesssystem is the result of invalid programpointers triggering an address error andpotentially corrupting or downing asystem. Obviously, this is undesirableand as such requires code to beprogrammed and diligently tested toensure robustness.Each step of development must becarefully mapped out, an overview ofthis cycle provides insight.First, as one might guess, support withinthe code for an MMU needs to be turnedoff. To account for this change uClinuxprovides new code for the memorymanagement subsystem of the kernel.Essentially, uClinux provides basicmemory management functions withinthe kernel software itself. For thosefamiliar with uClinux or a Unix likesystem, this is the role of the directory
derived from and replacing
.New strategies also must be developedfor operations like releasing memoryafter a process ends or allocatingmemory to a new process.Changes to the kernel are necessary torun userspace programs. Someprogram loaders, such as those for ELFand COFF, require modifications. Newloaders are required for these formats(i.e.:
. Futhermore,since child processes run in the sameaddress space as their parents, thebehaviour of both may requiremodification.
Within uClinux, the lack of memorymanagement hardware on a targetprocessor has meant that somechanges needed to be made to thesystem interface. Perhaps the greatestdifference is the absence of the
system calls.A call to
clones a process tocreate a child. Under Linux,
isimplemented using copy_on_writepages. Without an MMU, uClinux cannotcompletely and reliably clone a process,nor does it have access to copy-on-write.In the case of uClinux, it implements aversion of BSD’s
in order tocompensate for the lack of
 When a parent process calls
 to create a child, both processes shareall their memory space including thestack.
then suspends theparent's execution until the child processeither calls
Notethat multitasking is not otherwiseaffected. It does, however, mean thatolder-style network daemons that makeextensive use of
must bemodified. Since child processes run inthe same address space as theirparents, the behavior of both processesmay require modification in particularsituations.Many modern programs rely on childprocesses to perform basic tasks,allowing the system to maintain aninteractive "feel" even if the processingload is quite heavy. Such programs mayrequire substantial reworking to performthe same task under uClinux. If a keyapplication depends heavily on such

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->