October 2014
48
T
OOLS
& S
OFTWARE
is generally not a hard disk. Operating sys-
tems are loaded out of non-rotating memory
media like NOR- or NAND-flashes and SD/
μSD/CF cards. The boot medium strongly
influences the timing of the system startup
sequence. What are the differences between
the types and resulting performance effects?
The NOR-flash is a fast memory, linearly
mapped into the address space. Depending on
the hardware design it is 8/16/32/64 bits wide
attached to the CPU with fixed defined access
speed. It is the fastest type of all. NOR-flash
types offer the beauty that the boot-monitor
(e.g. U-Boot) is running directly out of it. An
initial load or copy process into RAM is not
required. Most RTOSs for example, are able
to run directly out of flash, which adds addi-
tional system safety. The RAM is free for data,
whereby the OS and application still resides
in the flash, hence these important code ele-
ments cannot be damaged by a program error.
NOR-flashes however offer compared to
NAND-flashes far less memory capacity
per chip space and are much more expen-
sive. Because of that they lose attraction in
cost-sensitive designs, but nevertheless they
are still used in environments requiring fast-
est startup times. The typical data rate is 10-80
MByte/sec and allows fastest access to boot
and program code. Yet NAND-flashes are
block-oriented devices and therefore not lin-
early seen in the address space.
Accesses to these memories have to be orga-
nized by dedicated drivers. Due to the organi-
zation and the 8-bit interface they are slower
than the classical NOR-flashes. NAND-flash
components are much cheaper compared
to NOR-flash memory and have their main
market in consumer electronic devices. Thus
the NAND technology is very attractive for
embedded designs, but especially in indus-
trial rugged designs exposes the application
to issues like long term availability or product
lifecycle management.Similar considerations
apply to SPI-NOR-flashes, which are NOR
flashes connected via a serial protocol inter-
face (SPI). Due to its non-linear organization,
the program code must first be transferred
from NAND-flash or SPI-NOR-flash to RAM
before the U-Boot or the OS can be executed.
A typical transfer rate here is 10-14MByte/
sec. Similar to NAND are CF cards. CF cards
are typically read by the boot monitor in PIO
mode, at typically 5MB/sec. SD/μSD cards
are connected with a 4-bit wide structure and
offer with >20MB/sec transfer rate the best
performance of the block-oriented medium.
As an example, we have measured the startup
times from reset to completely running an
application for different environments using
the RTOS Microware OS-9 loading a con-
trol application: NOR-flash, 0.3sec; SD-Card,
1.5sec; NAND-flash, 2.4sec.
Another strong influence on the boot timing
is the use of a compressed or uncompressed
OS image. The decompression time must
be compared with the load time for a larger,
uncompressed image and properly analyzed
for an optimization. Another decision crite-
ria is keeping the kernel small, because the
OS drivers (with DMA and IRQ handling) are
faster than the Booter (simple polling drivers),
so that the components are loaded faster. Or
using the variant “as we are already loading,
load everything in one chunk”. As the boot
devices are too different in read performance,
there is no generic statement possible, which
way to go to get the most promising approach.
As concluded earlier, the initial system design
has a strong influence on the boot perfor-
mance, and if there are options on different
boot media available, individual tests are
required to find the optimum. Several tests
showed up to a 25% time difference, e.g. for
a Linux System a speed-up from 24 to 17 sec-
onds, by using an uncompressed image (-3
seconds) loaded from SD Card (-4 seconds)
instead of compressed image on NAND flash.
As already described, the different boot media
have strong effects on the timing of a system
start. Other annoying thieves of time are the
initialization sequences of Ethernet and USB
interfaces. For initialization Ethernet com-
munication starts an auto negotiation on the
physical layer (PHY). Typically this takes
between 1 and 3 seconds, if a cable is con-
nected. Without a cable connected, it waits for
a timeout, e.g. 5 seconds before it proceeds. If
this happens within the kernel startup process,
where no process scheduling is possible and
nothing else can run at the same time, then it
delays the system start until the action is fin-
ished. To achieve better boot results, it is by
far better to start the network at a later point,
so that it can run with normal scheduling in
the background. To initialize the USB com-
munication the USB bus must be scanned
for the connected topology with all the hubs
and devices. This might take up 10 seconds
with nearly no CPU usage. It makes sense to
start the USB stack as early as possible, so that
it can run in the background during other
devices and services are starting
Most embedded systems (at least during the
development) have a serial line for the system
start message and the shell prompt. As the
serial line is attached to a PC by a terminal
program, a first and very simple tool to ana-
lyze the startup timings is the terminal pro-
gram itself. Most of the terminal programs
(like TeraTerm) can use timestamp logging.
Each received line gets a timestamp on arrival.
Here we see the duration between the mes-
sages. Most times the message itself tells a lot
about where it comes from. Example:
[Wed Sep 05 13:53:07.491 2012] NAND read:
device 0 offset 0x200000, size 0x400000
[Wed Sep 05 13:53:08.171 2012] 4194304 bytes
read: OK
It explains that reading 4MB from the NAND
flash takes about 0.7 seconds. To get a mean-
ingful time stamping, the baud rate should be
as high as possible (>=115200Baud). Hint:
As USB serial adapters are buffering the data
internal and sending them as bulk blocks to
the system, it can happen that multiple lines
are getting the same time stamp. It is of advan-
tage to use the internal serial line of the PC
(if it is still available), to achieve a better time
resolution, as the internal serial line directly
reads the data without any delay like the USB
has due to the buffering.
AdaCore: conference on reliable,
safe and secure software
AdaCore announced that, along with partner
Altran, it will be a major sponsor of the inau-
gural High Integrity Software Conference tak-
ing place in Bristol, UK on October 23rd 2014.
HIS 2014 is a brand new UK conference for
sharing information about key challenges and
recent developments in high integrity soft-
ware engineering.
ETAS debuts at InnoTrans
ETAS will be making its first-ever appearance
at InnoTrans, the International Trade Fair for
Transport Technology, where the company
will present innovative solutions for develop-
ing, testing, and integrating real-time-capable
software designed for rail vehicles. ETAS RTA
Solutions represent professional, made-to-or-
der consulting and software engineering for
real-time applications.
N.A.T.: firmware v2.15 for NAT-MCH
and NATview v2.13 now available
N.A.T. make version 2.15 of the firmware for
the NAT-MCH-Family of products as well as
the improved and extended version 2.13 of
the JAVA based GUI NATview available to
customers. The NAT-MCH family of products
consists of: NAT-MCH, NAT-MCH-PHYS
and NAT-MCH-PHYS80.
Product News
