See also:
Open Source
Engineering moves centre stageLinux is firmly established in the embedded market, but
migrating existing source code to the operating system is a
considerable undertaking.
Hans Juergen Rauscher explores the different steps necessary to
migrate, the technical requirements and possible pitfalls, and the
differences between buying an established Linux implementation and
developing and maintaining one internally.Why Migrate?Linux has
gained a firm position in the embedded market. This raises the
question of whether it is worth developing new products with Linux
and replacing an existing operating system with Linux. There is
effort and risk in any migration of an operating system, and the
technical difficulties and analysis and planning for migration to
embedded Linux require consideration and time.
The reasons for migrating an operating system differ radically from
company to company and even from one product to another. It can
offer new functionalities and technologies when the performance of
the current hardware and operating system has become inadequate. In
addition to the end-of-life for hardware and software components
making migration necessary, it is quite common to migrate to a new
system to save costs.
Why Linux?
Linux has established itself not only in corporate information
technology but in the embedded market. This is mostly a result of
the scale and availability of reusable source code, the broad
support of different types of hardware, the large number of
developers who use it, and an anticipated cost reduction. Linux is
highly flexible and offers complete control over development tools
and the operating system and associated packages.
Linux currently offers an operating system platform technology that
is also suitable for embedded systems. Hard real-time and
certification, which are vital in the industrial sector, are still
under development.
Software Components
Application software usually represents added value to an existing
product and represents a competitive advantage. It is usually the
first choice for project managers looking to migrate.
The necessary middleware - the software that makes running the
application possible - is often enhanced with desirable
functions, which makes migration even more attractive. However,
many middleware implementations use a lot of operating
system-specific functions, and this makes migration less sensible
than a new implementation.
How to Migrate
If Linux is chosen as the operating system for the migration, the
next step is to outline an efficient course of action. First,
determine the migration goal and assess the risk management. In
principle, there are three feasible methods of converting
applications to Linux. For the first approach, the majority of the
effort is spent on application redesign and provides an opportunity
for maximizing the value of Linux. Existing source code is suitable
for porting if the API (e.g.,
UNIX
or POSIX) and the internal structure of the application are similar
to Linux. As an example, the migration model used by the device
software firm Wind River is shown in Figure 1 below.
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:
- 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.
- 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.
- 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.
- 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.