uClinux as an Embedded OS on a DSP

Why the combination of a DSP and uClinux works especially well for the embedded Linux gadgets turning up everywhere in the consumer electronics market.

Recently, several large consumer electronics companies announced a collaboration called the Consumer Electronics Linux Forum (CELF) to develop further the Linux platform for use in digital home electronic devices. The founders of CELF--Matsushita Electric, Sony, Hitachi, NEC, Royal Philips Electronics, Samsung, Sharp and Toshiba--are focused on the advancement of Linux as an open-source platform for consumer electronics devices. As such, they actively are supporting and promoting the spirit of the Open Source community.

The advantage of embedded Linux is it is a royalty free, open-source, compact solution that provides a strong foundation on which an ever-growing base of applications can run. Linux is a fully functional operating system, with support for a variety of network and file-handling protocols--an important requirement in embedded systems because of the need to compute anywhere, anytime. Modular in nature, Linux is easy to slim down by removing utility programs, tools and other system services that are not needed in an embedded environment. The advantages for companies using Linux in embedded markets are faster time to market and reliability. For those developers, the combination of a digital signal processor (DSP) and uClinux may be of particular interest.

What's the Difference Between Linux and uClinux?

Because Linux is similar to UNIX in that it is a multi-user, multitasking OS, the kernel has to take special precautions to assure the proper and safe operation of up to thousands of simultaneous processes from different users on the same system. The UNIX security model, after which Linux is designed, protects every process in its own environment with its own address space. Every process also is protected from processes being invoked by different users. Additionally, a virtual memory (VM) system has additional requirements that modern CPUs have to fulfill, including dynamic allocation of memory and mapping arbitrary memory regions into the private process memory.

Some devices, such as Analog Devices' Blackfin Processor, do not provide a full-fledged memory management unit (MMU), because developers targeting their application to run without the use of an OS normally do not need an MMU. Additionally, MMU-less processors such as the Blackfin are more power efficient and often are significantly less expensive than the alternatives.

To support Linux on such devices, a few trade-offs have to be made:

  • No real memory protection (a faulty process can bring down the complete system)

  • No fork system call

  • Only simple memory allocation

  • Some other minor differences

Memory protection is not a real problem for most embedded devices. Linux is a stable platform, particularly in embedded devices, where software crashes rarely are observed.

The second point is a little more problematic. In software written for UNIX or Linux, developers often use the fork system call when they want to do things in parallel. The fork call makes an exact copy of the original process and executes it simultaneously. To do that efficiently, it uses the MMU to map the memory from the parent process to the child and copies only those memory parts to that child it writes. Therefore, uClinux cannot provide the fork system call. It does, however, provide vfork, a special version of fork in which the parent is halted while the child executes. Therefore, software that uses fork system calls has to be rewritten to use either vfork or threads. uClinux supports threads because they share the same memory space, including the stack.

As for point number three, there usually is no problem with the malloc support uClinux provides, but minor modifications sometimes have to be made.

Most of the software available for Linux or UNIX can be compiled directly on uClinux. The rest usually require only some minor porting or tweaking. Only a few applications do not work on uClinux, with most of those being irrelevant for embedded applications anyway.

Developing on uClinux

When selecting development hardware, developers should choose carefully with regards to price and availability. They also should look for readily available open-source drivers and documentation.

A uClinux Blackfin Processor development environment consists of the GNU Compiler Collection (GCC cross compiler) and the binutils (linker, assembler and so on) for the Blackfin Processor. Additionally, some GNU tools such as awk, sed, make and bash, plus Tcl/Tk are needed, although they usually come as part of basic desktop Linux distributions.

After the development environment has been installed and uClinux distribution decompressed, development may start. First, the developer uses the graphical configuration utility to select an appropriate board support package (BSP) for his target hardware. Developers using their own hardware should make themselves comfortable with development on the EZ-KIT Lite or STAMP hardware (schematics and production files available here). After that, they can start writing their drivers and making a BSP by copying an existing one and modifying a few parameters.

Most of the development work consists of selecting the appropriate drivers and de-selecting kernel features not needed for the project in question. A selection of library features and user-space programs follows thereafter.

Figure 1. Graphical Kernel Configuration

The uClinux distribution provides a wide selection of utilities and programs designed with size and efficiency as their primary considerations. One example is BusyBox), a multi-call binary program that includes the functionality of a lot of smaller programs and acts like any one of them if it is called with the appropriate name. If BusyBox is linked to ls and contains the ls code, it acts like the ls command. The benefit of this is BusyBox saves some overhead for unique binaries and those small modules can share common code.

After everything is selected and successfully compiled, the Kernel and a RAM disc image can be loaded on to the target hardware with the help of the VisualDSP++. Once this is successful, further development can proceed. The next step is to use a serial or network-enabled bootloader instead of loading through the JTAG interface. A small circuit connected to a PC's parallel port and Blackfin's JTAG interface can be used to flash the bootloader initially to the target memory. But it is important to note that this workaround doesn't provide the debugging and emulation capabilities that VisualDSP++ does. Once the kernel is up and running, the free GNU Debugger (GDB) can be used to debug user applications.

The next step would be the development of the special applications for the target device or the porting of additional software. A lot of development can be done in shell scripts or with languages such as Perl or Python. Where C programming is mandatory, Linux's extensive support for protocols and device drivers provides a powerful environment for the development of new applications.

Figure 2 is an example of how easy an AC'97 audio codec could be wired to a Blackfin Processor, without the need for additional active hardware components.

Figure 2. AD1885 Wiring Diagram

Below is an example of a very simple program for reading from this codec, assuming an audio AC'97 driver is compiled into the kernel.

fd = open("/dev/dsp", O_RDONLY, 0); //open the audio device
int speed = 44100; // 44.1kHz
ioctl(fd, SNDCTL_DSP_SPEED, &speed)// set sample rate  
read(fd, buffer_rx, number_of_bytes); // read number_of_bytes into buffer
close(fd); // close device



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

MMU - Pagesize change effects !!

Karthik Balaguru's picture


I am using a pagetable base addr of 0x20026C0. I have configured for using Small Pages (that is bits[1:0] = 0b10 ) . But, I find that since the 4K page size is quite big. So, i am thinking to change the pagesize to 1K (Tiny Page Concept - bits[1:0]=0b11 ) and use the memory space efficiently.

But, my application uses 4K till now.

So, what are things that i need to consider(Takecare) if i change the 4K page size to 1K (Small page Modeil to Tiny Page Model) ?

What are the stuffs that will get effected because of changing the
Small Page concept to Tiny Page ? ( I am using Arm9 Core Processor).

How far will the current existing sourcecode get affected ?
Will the CMD(Linker Command File) get affected due to this ?

Further, Normally which is better & efficient - 4K or 1K page ?
Does this selection depend upon the modules used ? Which is efficient in terms of memory management, efficient data usage, speed of access ?

Kindly share your ideas / suggestions.

Thx in advans,
Karthik Balaguru

Re: uClinux as an Embedded OS on a DSP

Ralph's picture

Thank you for writing this article. You provide a very crisp overview of the motivations and issues related to development with Linux on Blackfin. I look forward to seeing more of your thoughts in writing.

Good and usefull document for

Srinidhi Kasagar's picture

Good and usefull document for uClinux/Blackfin developers

want more details

anil sati's picture

I am a software engineer told to work on a project with blackfin and uclinux , i am entirely new to this and i am in need of help about these subjects , if any could provide me with tutorials or articles with give insight to blackfin with uclinux it would be of great help

Thanking u

Anil sati

More Information

Darren's picture

All the information you need for this (including that latest releases of tools and source code) should be available at
and also in the documentation wiki at