Figure 1: The Wind River Professional Services migration methodology (click to expand)

If the source code is too strongly interwoven into the current operating system's API, an API intermediate (or shim) layer should be inserted to communicate between the current operating system's API and the Linux API. If not, the application can be bundled with the current operating system straightaway and layered onto Linux (see Figure 2).

Figure 2: Applications may be redesigned, ported or reused, even with a legacy OS (click to expand)

This approach requires a hardware abstraction layer, or HAL, for the legacy OS, which may be hard to achieve if the OS does not use a HAL or if it is not documented. As an alternative, virtualisation technologies can be used to encapsulate the bundled OS and application. Ideally this virtualisation is also supported by the target CPU to keep performance on an acceptable level.

Linux-Specific Issues

There are also several Linux-specific issues that should be considered when migrating. The current real-time operating system tasks are grouped as Linux threads under a Linux process, so the separation in user space and kernel space has to be taken into account.

Depending on the required response time of the application and the CPU performance, the Linux kernel may be able to satisfy these without modification (with a response time of tens of milliseconds) or may require additional functionality such as the PREEMPT_RT kernel patches (with a response time of tens of microseconds).

If the application requires deterministic, 100% guaranteed response times in the range of single-digit microseconds, Linux may not be able to satisfy this by itself. Instead, a real-time scheduling mechanism, such as Wind River Real-Time Core for Linux, can be added. This controls the CPU and provides computing time to Linux only if there is no real-time thread or interrupt service routine that requires the CPU time.

The transition of a frequently used flat memory model with physical addresses to one with virtual addresses and pages protected by a memory management unit will also make some code changes necessary. The interprocess communication and synchronisation should be retained, provided there are no compatibility issues.

Linux has a strong user- and file-structure, so customization is likely to be required here as well. One way to deal with this is to write an application startup wrapper that sets up the environment and then starts the migrated application as a child process. This means fine-tuning of the RTOS task priorities is needed for the Linux process/thread model.

It also doesn't make sense to migrate device drivers, so if this is needed, a new implementation should be planned.

The increased demand for RAM and flash memory for Linux must also be considered when designing the hardware. A typical Linux kernel is around 1 to 2 megabytes, which results in a typical 8MB RAM requirement for a Linux system. For easier testing and debugging the code of a JTAG interface, serial and Ethernet interfaces should also be available, at least on the development board.

Booting Linux differs distinctly from real-time operating systems as it needs a boot loader and access to a mountable root file system containing all the necessary binary packages. This can reside on a flash, a directly attached disk or an NFS file server in the network.

Which Linux?

In principle there are four types of Linux:

1. Building Linux yourself (also called "roll your own," abbreviated as RYO) is the most original type of Linux. It provides total control but comes with the full responsibility for maintaining and supporting it. In addition to the substantial effort of maintaining it, there is high project risk; these do not contribute to the features or value of the end product.
2. Free Linux distributions such as Ubuntu, Fedora, OpenSUSE or Debian are frequently unsuitable for embedded projects due to their primary focus on the x86 CPU architecture and servers or desktop PCs.
3. Linux versions offered by hardware manufacturers are usually not up-to-date and are rarely maintained or supported long-term. They also lack the tight integration with development tools beyond the compiler and so are often inadequate even though they offer increased support for target hardware platforms.
4. Commercial Linux, such as Wind River Linux, offers the benefits of Linux with openness, source code and wide support, without the added development and debugging effort or limitations associated with RYO or hardware-vendor distributions.

Adding value

With careful planning and consideration of the issues involved, the migration to embedded Linux can have considerable success.

The application environment and the ongoing support requirements mean, in practice, that commercially available embedded Linux is often superior to the other variants such as self-built Linux. This allows the developer to focus on the application and the added value of the end device and minimises the short and long-term risks of the migration.

Hans Juergen Rauscher, system architect, networking, Central Europe, for Wind River, Germany, consults key telecom accounts about networking technologies and Linux.