October 2014
46
T
OOLS
& S
OFTWARE
How to achieve fastest system startup
sequences with your embedded system
By Kei Thomsen,
MicroSys
This article discusses how
to achieve fast startup times,
especially in view of different
operating systems like a general
purpose OS or RTOS. Additionally
an overview is given on boot media
and their effects on startup behavior,
together with practical measurements.
To achieve quick boot timings with complex
embedded systems, sound knowledge about
the internals, the architecture of the operating
system and their interaction with the hardware
are required. Smaller real-time operating sys-
tems are a perfect means to meet such require-
ments. They are specifically designed to control
precisely the timing behavior of an embedded
system and they are clearly arranged and con-
figurable. Additionally smaller engineering
teams are not overwhelmed by complexity and
they can keep control of their development
process more easily.
By the configurability of a RTOS, the func-
tionality of the boot sequence can be opti-
mized according to the given hardware design.
Time-consuming load processes of hundreds
of drivers, libraries or system code which
might not even have been used are avoided.
On the other hand, compared to more com-
plex and feature-rich general purpose OSs for
embedded systems like Linux or Windows
variants, a more limited feature set has to be
taken into account. Other aspects influenc-
ing system startup timings are hardware ini-
tializing functions and the boot media and
method the operating systems are loaded
from. Fast boot is another term to express a
quick start of a system from power-on or reset
to show at least a system prompt on a screen
with loaded operating system, or have a win-
dow opened for the first user interaction. The
timings to get a system up and running vary
strongly by nature of the system, application
and target market. A Windows desktop user
might be used to waiting a couple of minutes
before he can use his system, whereas in many
deeply embedded environments the device is
required to boot up in fractions of a second. A
first conclusion is that for some applications
a minutes-long startup sequence can be toler-
ated, while in others it is a must to restart the
system in an instant. If time-critical functions
need to be considered related to the startup
behavior, the complete system design from
component to system software level (includ-
ing operating system) has to be the right fit
for that. Secondly the media the boot software
is loaded from has to be selected thoroughly.
Flash, SD & CF Cards, rotating media or a
network connection offer by nature different
timings and have a strong influence on the
cost structure of a system as well. Especially
for deeply embedded systems, longevity of
parts supply and maintainability might have
an influence as well. As a short summary, fast
boot has many aspects and a precise defini-
tion of it is not that easy. To be able to have
a more defined basis for comparisons we will
discuss the results of experiments we did on
an i.MX 53 ARM based platform supporting
different typical boot environments and oper-
ating systems. Generally we differentiate two
different types of operating system. On one
hand the standard OSs like Linux and Win-
dows and on other hand real-time operating
systems. Linux and Embedded Linux-Sys-
tems, representing standard OSs, are generally
complex, have an extensive kernel, including
many extensions, and the full functionality is
merely seen by experts. Booting a Linux sys-
tem means first loading and initializing the
kernel and drivers, and then starting a large
number of system services and additional
programs. Here again it needs a lot of knowl-
edge to understand the function and usage of
the services and programs. Optimizations to
achieve faster boot and startup times are not
as simple as they should to be. Another aspect
is optimizing a system after the functionality
has been defined and implemented, but the
startup time still requires to be tuned. The
question here is how to assure the warranted
system characteristics and properties by opti-
mizing the system?
To face this problem right at the begin-
ning, a very practical method is to plan and
implement a test system based on minimal
OS functionality. Avoid all the nice-to-have
features and develop the optimal functions
step-by-step. The required know-how and the
additional development resources are to be
considered accordingly. If it becomes obvi-
ous under the project work that new kernel
