world leader in high performance signal processing
Trace: » intro

View page as slide show

Intro to μClinux

Introduction to μClinux on the Blackfin Processor

Linux on microcontrollers: processors without a Memory Management Unit (MMU).

This presentation gives a technical overview of Linux usage on small embedded systems without a MMU.

It shows how the absence of virtual memory and (optionally) memory protection is handled by uClinux.

For embedded developers already familiar with Linux, it lists the the standard features of Linux which provide a strong advantage to Linux, while detailing the minor extra constraints that not supporting virtual memory means on these very small systems.

Controlling presentation

  • go to next slide : Space bar, Return, Enter, Right arrow, Down arrow, Page down, Click left mouse button outside of control area, Flash object, or movie
  • go to previous slide : Left arrow, Up arrow, Page up
  • Switch between slideshow and outline view : T
    • Do this now, to see additional controls/notes.

  • go to title (first) slide : Home
  • go to last slide : End
  • Jump directly to slide : Type slide number, then hit Return or Enter
  • Skip forward n slides : Type number of slides to skip, hit any “go to next” key except Return or Enter
  • Skip backward n slides : Type number of slides to skip, hit any “go to previous” key
  • Show / hide slide controls : C, Move mouse pointer over control area

Rights to copy

Attribution – ShareAlike 2.5

You are free :

  • to copy, distribute, display, and perform the work
  • to make derivative works
  • to make commercial use of the work

Check the detailed license requirements for conditions for this license to be met.

You have the above freedoms under the following conditions:

  • Attribution You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).
  • Share Alike If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.


  • μClinux project overview
  • μClinux implementation details
  • Using μClinux

μClinux project overview


  • μClinux distribution, a collection of userspace applications and libraries which makes a Linux distribution, specifically designed for embedded development
  • μClibc, a tiny C library, specifically designed for embedded development
  • Linux - a kernel which can be configured for virtual memory support (MMU on) or not (noMMU).
  • noMMU Linux - the same Linux kernel, with a specific option (out of 1677 possible options) turned off. When functionality of this option changes something, we will call it out specifically, and note it by using “noMMU Linux”
  • μClinux project - The combination of the μClinux distribution, μClibc,

The μClinux project

The Linux/Microcontroller project: Pronounced “you-see-linux”, the name μClinux comes from combining the greek letter “mu” or “μ” and the english capital “C”. “μ” stands for “micro”, and the “C” is for “controller”.

Because most (if not all) of the kernel and supporting packages are free software / open source, Linux distributions have taken a wide variety of forms — from fully featured desktop and server operating systems to distributions like µClinux - minimal environments (typically for use in embedded systems). Aside from certain custom software (such as installers and configuration tools) a “distro” simply refers to a particular assortment of applications married with a particular kernel, such that its “out-of-the-box” capabilities meets most of the needs of its particular end-user base.

Although there are currently over three hundred Linux distribution projects in active development, constantly revising and improving their respective distributions, all distributions (including µClinux) use the same Linux kernel from (although they may be different versions, and may have different patches applied). One can distinguish between commercially backed distributions, such as Fedora (Red Hat), SUSE Linux (Novell), Ubuntu (Canonical Ltd.), and Mandriva Linux and community distributions such as Debian, Gentoo or µClinux. The procedures for assembling and testing a distribution prior to release tend to become more elaborate the larger the user base is.

Like all Linux distributions, µClinux is built from the Linux kernel from and assorted other packages, and software including those from the GNU project. Since µClinux is optimized for size, it uses more compact alternatives (busybox, uclibc, etc) than a non-embedded or desktop distributions.

µClinux supports embedded processors which support :

  • MMU (protection and virtual memory support),
  • noMMU (no protection, no virtual memory) and
  • MPU (memory protection, but no virtual memory support).

uClinux history

  • 1998 (Linux 2.0), First release for the Motorola 68000 processor. Demonstrated on Palm Pilot III.
  • 1999: Motorola ColdFire support
  • 2001: Linux 2.4 support. ARM7 support
  • 2004: Included in Linux mainline (2.6)
  • 2004: support for ARM
  • 2004: site kicked off
  • 2007: Blackfin added to mainline (2.6.22)
  • 2008: Continues to grow in popularity.

Reasons for using uClinux

  • Linux kernel Built-in IP connectivity, reliability, portability, filesystems, free software…
  • Lightweight Full Linux 2.6 kernel under 300K, binaries much smaller with uClibc.
  • Execute In Place (XIP) Don't have to load executables in RAM. May run slower though.
  • Cheaper MMU-less arm cores are smaller.
  • Sufficient A large number of embedded systems applications can do without an MMU.
  • Faster Faster context switches: no cache flushes.

  • Full Linux 2.6 kernel features
    • stability, preemptible kernel, drivers…
  • Standard concept of kernel/user separation & protection
    • Kernel space is the domain of the kernel (wow!), device drivers and hardware interrupt handlers. The job of the kernel is to provide a safe and simple interface to hardware and give different processes a fair share of the resources, and to arbitrate access to resources/hardware.
    • User space is what all user (including root) programs run in. Many ideas are best implemented in user space, with perhaps the absolute minimum of kernel support. The only exceptions to this principle are where it is particularly complicated or inefficient to implement the solution in user space only. This is why filesystems are in the kernel, the kernel implementation is much faster (you *could* put them in user space implemented as daemons). Userspace code can not access the hardware, and must go through the kernel (so proper arbitration/sharing is done).
  • Full Linux API
    • Can use most Linux system calls with minor exceptions. All applications distributed with uClinux are validated with noMMU as well as MMU.
  • Full multi-tasking
  • Supported on many processors, which wouldn't be supported by Linux otherwise.

uClinux weaknesses

  • Less momentum than Linux. Much smaller community.

However uClinux development is still active: kernel and distribution. uClinux releases available for each Linux 2.6.x version, released just a few weeks after.

  • Deterministic support


  • Lightweight C library for small embedded systems, with most features though.
  • Originally part of the μClinux project. Now an independent project.
  • The whole Debian Woody (thousands of programs) was recently ported to it… You can assume it satisfied most needs!
  • Example size comparison (busybox example, static build): 311 K (μClibc) vs. 843 K (glibc) 37%!

The letter 'μ' is short for µ (the greek letter “mu”). μ is commonly used as the abbreviation for the word “micro”. The capital “C” is short for “controller”. So the name μClibc is sort of an abbreviation for “the microcontroller C library”. For simplicity, μClibc is pronounced “yew-see-lib-see”.

The name is partly historical, since μClibc was originally created to support μClinux, a port of Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, ARM7TDMI and Blackfin. These days, μClibc also works just fine on MMU Linux systems (such as i386, ARM, and PowerPC), but no one couldn't think of a better name.

Currently μClibc runs on alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.

uClinux limitations

  • Virtual memory = physical memory
    • can't stitch fragmented physical memory together
    • no over commit - more memory consumption
  • Fixed memory for processes:
    • stack can not grow,
  • Optional memory protection
    • userspace can write into/on top of kernel, and cause crash

uClinux for Linux Programmers by David McCullough.

uClinux implementation details

Although most of the content is specific to the Blackfin processor, it mostly applies to all processors supported by uClinux.

No memory management

  • No virtual memory
    • Programs addresses need to be preprocessed (“relocated”) before running to obtain unique address spaces.
  • No on-demand paging
    • Need to load whole program code in RAM (instead of just loading pages when they are effectively accessed).
  • Optional/Limited/No memory protection
    • Any program can crash another program or the kernel. Corruption can go unnoticed and surface later… difficult to track down! Design your code carefully. Be careful of data from the outside!
  • No swapping
    • Not really an issue on the tiny embedded devices

Better performance

noMMU Linux can be significantly faster than MMU Linux on the same processor!

  • MMU operation can represent a significant time overheard. Even when an MMU is available, it is often turned off in systems with real-time constraints.
  • Context switching can be much faster on noMMU Linux. On ARM9, for example, the VM based cache has to be flushed at each context switch.



Memory Management Unit
Memory Protection Unit
Global Offset Table - Used in executable formats.
Executable and Linkable Format A file format describing executables, object code, shared libraries and core dumps. The OS uses it to know how to load executables and shared libraries.
Position Independent Code Object code without absolute addresses, which can execute at different locations in memory.

The MMU's job

Memory Management Unit are included in many general purpose processors available today, however in some low cost variants, they are not. The MMU serves two main purposes:

  • Virtual addresses. Allows processes to run in their own virtual contiguous address space. No need for relocating process addresses. Possible to expand the address space of a running process. The MMU raises an exception when no physical address is available, making it possible to implement swapping to disk.
  • Address protection Actually done by the Memory Protection Unit (MPU) available in most MMUs. Prevents processes from accessing unauthorized memory addresses.

Note that some systems just have an MPU, but no MMU.


Much of the content of this material was borrowed from the excellent presentation from free-electrons and Michael Opdenacker.