THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

EMBEDDED NETWORK APPLINCES WITH LINUX

by Greg Ungerer

Start ę A Closer Look ę Why Linux? ę The Building Process ę Microcontroller Linux ę Porting the Application Set ę Debugging ę Future Looks Bright ę Sources and PDF

MICROCONTROLLER LINUX

As I mentioned earlier, the ColdFire family of processors is tailored for use in embedded systems. This does not make them lesser siblings in the microprocessor family tree, but rather a different branch, specialized for a different type of platform.

The main issue to deal with now is that standard Linux only runs on systems that have virtual memory (VM) support. That is, they have a memory management unit (MMU), whereas the ColdFire does not. Fortunately, a port of Linux exists in Motorola 68k series CPUs that do not have VM support, microcontroller Linux (ęC-Linux).

Microcontroller Linux is a port of a standard Linux kernel that doesnęt need any form of virtual memory. It offers the same API set as standard workstation Linux. This is important because you want to draw on the large base of software that works with Linux.

There are a few important differences to note. For instance, only the vfork() system call is supported for forking new processes. There is no memory protection between user processors or the kernel. There are limits for the allocation sizes of memory regions. And finally, there is a fixed size application stack (cannot be dynamically grown).

As it turns out, these can be worked around easily. In many cases, no special changes are required to port applications to ęC-Linux. By and large, these limitations do not affect the bulk of the API set (i.e., the system calls available to user-level applications).

One of the main side effects of not having virtual memory is that debugging can be more difficult. It is simple for buggy program pointers to overwrite and corrupt other processes, or even the kernel memory space. This can easily lead to system crashes that are hard to diagnose and track down.

PORTING ęC-LINUX TO A COLDFIRE PROCESSOR

It is worth mentioning some of what was involved in porting ęC-Linux to a ColdFire processor. There are a number of issues to tackle when porting an existing software system to a new processor architecture, especially with system-level software such as a kernel.

Initially, the effort is to get the kernel compiled into object code for the new processor. This is not as easy as it sounds! The Linux kernel contains copious amounts of in-line assembler. Even though the ęC-Linux kernel runs on 68k-based systems, there are a number of ColdFire processor differences, which means much of this assembler needs to be reworked. In particular, the stack pointer differences and lack of addressing modes caused problems.

Next, some attention needs to be paid to deciding on an appropriate memory layout for the system. All peripheral devices are mapped into the physical memory space of the processor. Likewise, all running application processes and the kernel are mapped into the same physical address space. So, a model for what goes where needs to be determined. The kernel needs to be modified with this in mind because it ultimately controls all the memory.

The next consideration is code modifications to support the ColdFire built-in support peripherals. This includes support for the interrupt controller and timer, critical components of any operating system kernel. Similarly, support needs to be coded for the essential external resources associated with the processor. In particular, the flash memory needs special support. It has several distinct functions, from being the system boot device to storing nonvolatile configuration information.

Support for the wider range of peripheral devices connected to the hardware platform is generally in the form of device drivers. A new driver is required to support the built-in ColdFire asynchronous serial ports. Other devices on common ColdFire-based boards, including the Moreton Bay NETtel, are easier to support. Linux has such a vast range of device drivers that common devices, like Ethernet controllers, are usually already there. Then, itęs only a matter of modifying the driver to cater for the memory addressing differences of the specific hardware platform.

Lastly, comes the application binary support. Having no virtual memory means that conventional binary file formats (such as ELF) are inconvenient to use on ęC-Linux and the ColdFire processor. The ęC-Linux group devised a new flat file format for binaries. Flat binaries contain the usual code and data portions of an application, but they also contain a set of relocation information. When a program is loaded for execution, it is relocated in the memory space allocated for it. This process is transparent to the application.

The ęC-Linux kernel porting process was a challenge. But with a solid base, the follow-up efforts to build the application set became easier.

PREVIOUS • NEXT