RTC Magazine

Today Linux is the fastest growing embedded operating system in the world. Bringing Linux up on an embedded target and debugging it along with its associated applications presents new challenges for embedded systems programmers. These challenges, in turn, must be addressed by the designers and suppliers of tools for these programmers.

It is difficult to port Linux to a new platform without some method of accessing the system boot information console and the login console. On many headless targets there is either no good candidate for this functionality or such a candidate is not available at boot time. For example, cell phones simply do not have serial interfaces. In addition, the MMU-based memory model makes classic halt-mode debugging difficult or even impossible. Because all tasks share the same virtual address in Linux, classic breakpoint methods need modification. Debug register breakpoints (hardware breakpoints) are of little use.

A new debug topology combines halt-mode run control with run-mode debugging and DCC-based communications to effectively solve all of these issues. This method provides a test environment console that uses virtually no production resources. In addition, it combines the best features of halt-mode and run-mode debugging and provides the programmer with a feature-rich and effective way for him or her to get an embedded Linux-based project completed, on time and fully tested.

Linux in the Embedded World

Embedded designs are changing in nature and requirements. In the past, "embedded" usually referred to relatively small computer systems contained in a hardware product that showed almost no characteristics of a "computer". This hardware product contained tiny amounts of memory and, therefore, small and very efficient programs. These products usually had neither the means nor the requirement to communicate with other programmed products. If these machines contained operating systems at all, they were usually lean and not very feature-rich. "Small" and "fast" were the key drivers for these systems.

Today’s embedded projects are becoming more and more sophisticated, both in terms of features and underlying hardware. Most embedded systems include some type of connectivity, such as Ethernet or USB. Cheaper and faster processors and memory are increasingly becoming available for embedded systems. Many of today’s cell phones accept downloaded programs. Along with more software and connectivity comes the requirement for remote configuration and management. It is common to keep the phone book from a cell phone on a desktop PC.

With all of these software-based features being added to embedded products, software reuse is more necessary than ever. Developers must acquire operating systems, protocol stacks, http servers, remote management and communication software and many other software components in order to produce the required features. Writing these components can produce noncompetitive development costs. To be competitive, these components must be selected from those in general use. Fortunately, many of these components exist in the public domain and in the open source community.

In order to deploy the software components required, the design must be based on an operating system on which these components can run. That tends to limit the field to UNIX derivatives or WindowsCE. Many will argue that only a UNIX-conforming platform will get the job done. The most popular selection today is Linux.

Debug/Deployment Challenges

In order to use Linux, embedded engineers must first port it to their hardware. Then they must write and debug any custom drivers required for their application as well as write and debug the boot-up code. The final stage is to write and debug the applications that will run under Linux. This process offers several tool challenges that do not exist when using more classic operating systems such as Vxworks or other "flat address" environments.

Porting Linux to a new target requires a BSP or boot code just like any other solution. Once the boot code instantiates and attempts to launch the kernel, several new requirements surface. Linux is a large body of code; the first order of debugging a new port is to observe the kernel process while booting to determine what has succeeded, what has failed and where the process stopped. One common way of monitoring this process is to observe the system console messages. This is obvious, but not necessarily easy. Many embedded applications have no UART or other common port on which to attach a console. Even if the final product does have such a port, it may not be functional until new drivers are written and debugged. In this case, debug of the driver is going to be a serious challenge since the kernel may still have problems. Getting that first kernel message may be difficult.