jaimin-boot time optimization in embedded linux.pdf
DESCRIPTION
Boot time optimization techniques for LINUX.TRANSCRIPT
A
Seminar Report
On
Boot Time Optimization in
Embedded Linux
In
VLSI & Embedded System Design
Guided by
Suresh Sikka
Prepared by
Jaimin Thakkar
121060752027
C-DAC & Gujarat Technological University
Ahmedabad
C-DAC & Gujarat Technological University
Ahmedabad
CERTIFICATE
This is to certify that the seminar report entitled “Boot
Time Optimization in Embedded Linux” is prepared and
presented by Jaimin Thakkar bearing Enrollment Number:
121060752027, 2nd Year of III semester M.Tech (Electronics
and Communication Engineering) in VLSI and Embedded
System Design and her work is satisfactory.
JURY Course Coordinator.
(Suresh Sikka)
Acknowledgement
I am highly indebted to Suresh Sikka for their guidance and constant supervision as
well as for providing necessary information regarding the seminar & also for their support in
completing the seminar. I thank the Gujarat Technological University for providing the IEEE
Xplore subscription. I would like to express my special gratitude and thanks to Mr Rajesh
Sola for giving me such attention and time. My thanks and appreciations also go to my
colleague in developing the project and people who have willingly helped me out with their
abilities.
Abstract
Booting is a process that initializes all the systems and it is an essential process of
operating system to work. Because of this reason, system users have to wait until this process
finishes and it is very inconvenient. The time that a product takes to boot directly impacts the
first perception an end user has of the product. Regardless of how attractive or well designed
a consumer electronic device is, the time required to move the device from off to an
interactive, usable state is critical to obtaining a positive end user experience. This report
explains different methods to reduce Boot time by combination of modification in three main
software components (Bootloader, Kernel and Application) involved in booting process.
Table of Contents
1. Introduction
1.1 Boot Sequence……………………………………………………………………1
1.2 Measuring Boot-up Tim………………………………………………………......2
1.3 Technologies and Techniques for Reducing Boot Time…………………………. 3
2. Bootloader Speedup
2.1 Kernel XIP………………………………………………………………………..5
2.2 DMA Copy of Kernel on Startup…………………………………………………6
2.3 Uncompressed kernel……………………………………………………………..6
3. Kernel speedups
3.1 Disable Console……………………………………………………………….....7
3.2 RTC No Sync……………………………………………………………………..7
3.3 Preset loops_per_jiffy…………………………………………………………......8
3.4 Device Driver Initialization………………………………………….....................8
3.5 Threaded Device Probing………………………………………………………....8
3.6 Deferred Initcalls……………………………………………………………….....8
4. User-space and application speedups
4.1 Optimize RC Scripts…………………………………………………………….10
4.2 Init script………………………………………………………………………....10
4.3 Lazy process creation…………………………………………………………..…10
4.4 Application Init Optimizations…………………………………………………...11
4.5 Other Techniques…………………………………………………………….......12
5. Other Optimization Methods
5.1 Boot Time with various file systems…………………………………………….13
5.2 Suspend related improvements………………………………………………...…14
5.2.1 Software
Suspend/Resume………………………………………………………....14
5.2.2 Snapshot Boot……………………………………………………...…….15
Conclusion…………………………………………………………….............................16
References…………………………………………………………….............................17
Table of Figures
Figure 1 Booting mechanism.................................................................................................... 1
Figure 2 Comparison of normal and fast boot.......................................................................... 6
Figure 3 Comparison between different Configuration/Filesystem........................................ 14
Figure 4 Software Suspend / Resume Boot flow diagram...................................................... 15
Figure 5 Snapshot Boot flow diagrams................................................................................... 15
1
Chapter: 1 Introduction
1.1 Boot Sequence
Booting up a device involves numerous steps and sequences of events. It consists of
three main operations, “Boot loader”, “Kernel initialization,” and “Application Initialization”.
After power up, the boot loader initializes the system and starts the system process. Then it
copies the kernel image into memory. Once the kernel is loaded, the kernel initializes many
resources and loads H/W module into memory, then it mounts several file systems to the
several mount points.
Figure 1 Booting mechanism
Generally, a ROM BIOS stage is the process that CPUs and memories to initialize in
computing environment. This process is a first step of the boot process and first codes that
carry out when the power goes into computer; however, we will not deal with it since we are
focusing on initialization of software that stays in a main memory. There is a boot loader
seeking code that approaches Master Boot Record (MBR) of each disk, existing at the end of
the ROM BIOS. The MBR is formed with the Boot loader code, a partition table and a magic
number. The ROM BIOS finds a main partition referring to the partition table and finds
existence of a boot loader according to the magic number in the MBR of this partition.
If a boot loader exists, that boot loader will be loaded to the main memory and since
loading, the boot loader has a control of system. The boot loader loads a kernel image from a
disk to a main memory. Commonly used kernel image form IS 'bzImage'. 'bzImage' is
arranged by this order head.S code which activates virtual address by MMU, 'misc.o' code
2
which decompresses kernel and 'piggy.o' that IS the compressed kernel. Boot Loader
activates a MMU by jumping to starting part of head.S after loading the kernel image to
arranged starting address. After this code has been activated, CPU cannot reach to physical
address of the main memory and only through the virtual address, they can access.
Compression of the piggy.o will be decompressed by calling kernel decompressing code and
when its compression is decompressed, a kernel binary image exists within the memory;
however, that does not mean the kernel is carrying out immediately. Since the compressed
kernel image in the main memory is no longer used, it will be replaced by the decompressed
kernel to prevent wasting of memory space. After that, the boot process enters to
start_kernel() function also known as starting function of the kernel, with playing of
initialization code of each kernel components, calls init() function to kernel thread from
rest_init() function and then goes into idle state with infinite loop. Even though number 0
processes enter idle state, the booting is still not finished. 'init()' function that is called to a
kernel thread becomes number 1 process and also calls daemons and 'initcall()' functions.
When all the process is completed, finally it finishes booting through a shell program and
waiting for users to input.
We summarize three steps of the booting procedure as follows:
• Boot Loader
1. System initialization
2. Kernel image copy to RAM
• Kernel Initialization
1. Init kernel
2. Init device drivers
• Application Initialization
1. Run RC script
2. Run Applications
1.2 Measuring Boot-up Time
• Printk Times - simple system for showing timing information for each printk.
• Kernel Function Trace - system for reporting function timings in the kernel.
• Linux Trace Toolkit - system for reporting timing data for certain kernel and process
events.
• Oprofile - system-wide profiler for Linux.
3
• Bootchart - a tool for performance analysis and visualization of the Linux boot
process. Resource utilization and process information are collected during the user-
space portion of the boot process and are later rendered in a PNG, SVG or EPS
encoded chart.
• Bootprobe - a set of System Tap scripts for analyzing system bootup.
And "cat /proc/uptime"
• grabserial - a nice utility from Tim Bird to log and timestamp console output
• process trace - a simple patch from Tim Bird to log exec, fork and exit system calls.
• ptx_ts - Pengutronix' TimeStamper: A small filter prepending timestamps to
STDOUT; a bit similar to grabserial but not limited to serial ports
• Initcall Debug - a kernel command line option to show time taken for initcalls.
1.3 Technologies and Techniques for Reducing Boot Time
Following are the techniques which can be used for reducing time of three software
component of Booting Process. Some of these main methods are explained in following
chapters.
Bootloader speedups
Kernel XIP - Allow kernel to be executed in-place in ROM or FLASH.
DMA Copy Of Kernel On Startup - Copy kernel from Flash to RAM using DMA
Uncompressed kernel - An uncompressed kernel might boot faster
Fast Kernel Decompression
Kernel speedups
Disable Console - Avoid overhead of console output during system startup.
Disable bug and printk - Avoid the overhead of bug and printk. Disadvantage is that
we lose a lot of info.
RTC No Sync - Avoid delay to synchronize system time with RTC clock edge on
startup.
Short IDE Delays - Reduce duration of IDE startup delays (this is effective but
possibly dangerous).
Hardcode kernel module info - Reduce the overhead of loading a module, by
hardcoding some information used for loading the relocation information
IDE No Probe - Force kernel to observe the ide<x>=noprobe option.
Preset LPJ - Allow the use of a preset loops_per_jiffy value.
Asynchronous function calls - Allow probing or other functions to proceed in parallel,
to overlap time-consuming boot-up activities.
4
Threaded Device Probing - Allow drivers to probe devices in parallel. (not mainlined,
now deprecated?)
Reordering of driver initialization - Allow driver bus probing to start as soon as
possible.
Deferred Initcalls - defer non-essential module initialization routines to after primary
boot
Check what kernel memory allocator we use. Slob or slub might be better than slab
(which is the default in older kernels)
If our system does not need it, we can remove SYSFS and even PROCFS from the
kernel. In one test removing sysfs saved 20 ms.
Carefully investigate all kernel configuration options on whether they are applicable
or not. Even if we select an option that is not used in the end, it contributes to the
kernel size and therefore to the kernel load time (assuming we are not doing kernel
XIP). Often this will require some trial and measure! E.g. selecting
CONFIG_CC_OPTIMIZE_FOR_SIZE (found under general setup) gave in one case
a boot improvement of 20 ms. Not dramatic, but when reducing boot time every
penny counts!
Moving to a different compiler version might lead to shorter and/or faster code. Most
often newer compilers produce better code. We might also want to play with compiler
options to see what works best.
If we use initramfs in our kernel and a compressed kernel it is better to have an
uncompressed initramfs image. This is to avoid having to uncompress data twice. A
patch for this has been submitted to LKML.
5
Chapter 2: Bootloader Speedup
2.1 Kernel XIP
Bootloader is a program that runs just before an OS really starts its work. It initializes
a system and loads a kernel image into RAM. If we use NOR flash as a boot device, we can
shorten the boot time using kernel XIP. This is used in Uclinux and situates the kernel in the
available ROM or relative volatility memory, such as flash. In the case of the general kernel,
the kernel image is copied in the RAM. However, for a kernel XIP, the booting time is
reduced by decreasing the overhead needed to make a copy of the kernel image when the
kernel is booted up. However, this algorithm is less effective, and its code cannot be operated
during the writing and erasing of the flash memory.
The expected improvement from using this technique depends on the size of the
kernel, and the time to load it and decompress it from persistent storage. In general, time
savings of about .5 seconds have been observed.
Patches
Kernel 2.6.10 now includes XIP support:
ARM PATCH 2154/2: XIP kernel for ARM Patch. This patch allows for the kernel to be
configured for XIP. It is a good idea to have a generic and clean implementation supporting
all ARM targets. It involves:
Modifying the kernel entry code to map separate .text and .data sections in the initial
page table, as well as relocating .data to ram when needed
Modifying the linker script to account for the different VMA and LMA for .data, as
well as making sure that .init.data gets relocated to ram
Adding the final kernel mapping with a new MT_ROM mem type
Distinguishing between XIP and non-XIP for bootmem and memory resource
declaration
Adding proper target handling to Makefiles.
While at it, this also cleans up the kernel boot code a bit so the kernel can now be
compiled for any address in ram, removing the need for a relation between kernel address and
start of ram. Also throws in some more comments. And finally the _text, _etext, _end and
similar variables are now declared extern void instead of extern char, or even extern int. That
allows for operations on their address directly without any cast, and trying to reference them
by mistake would yield an error which is a good thing.
6
2.2 DMA Copy of Kernel on Startup
It's necessary to copy binary images, such as a kernel image, file system images, and
so on, from ROM to RAM on boot if XIP isn't used. In this case, using DMA transfer is very
efficient to save the time and CPU resources.
Fujitsu Prime Software Technologies measured the result of using DMA kernel copy
on FR-V processor and Kernel Version 2.6.6.
Figure 2 Comparison of normal and fast boot
In the normal boot case, the kernel image whose size is 1.7MB around is copied from
ROM to RAM by CPU at firmware init. On the other hand, DMA copy is used in the fast
boot case and it reduces about 180 milliseconds. It owes much to the potentiality of FR-V
processor, but it's worthy of consideration to use such a hardware assist feature for reducing
booting time.
2.3 Uncompressed kernel
Booting from an uncompressed kernel might improve the boot time. It will take
longer to read an uncompressed kernel image from background storage, but there is time
saved since no decompression is needed. So whether or not an uncompressed kernel is a win
with respect to boot time depends on the speed with which we can read from the background
memory and the speed of our processor (as a faster CPU will require less time to
decompress). So with a fast processor and slow background memory, compression might be a
win, whereas with a slow processor and fast background memory, compression might be a
loss.
Best strategy here is to empirically determine whether or not it is better for our system
to have an uncompressed kernel or a compressed one.
7
Chapter 3: Kernel speedups
3.1 Disable Console
We can save time during kernel boot by disabling the console output. Printk output is
usually directed to a serial port or a VGA console during boot. By disabling console output,
the time taken to output the characters (and perform things like software scrolling of the
display buffer) is eliminated.
To do this, just put the word "quiet" (without the quotes) in the kernel command line,
with no other arguments. This will suppress Printk output during booting. Note that Printk
messages are still buffered in the kernel and can be retrieved after booting using the "dmesg"
command.
Generally we can save 150 to 300 millisecond time in this method. With a serial
console, the time to output characters is dependent on the serial port speed. However, with a
VGA console, the time to output the characters is dependent on the speed of the processor.
Therefore, the slower our processor, the more savings we will gain from this technique.
3.2 RTC No Sync
One routine that potentially takes a long time during kernel startup is
get_cmos_time(). This routine is used to read the value of the external real-time clock (RTC)
when the kernel boots. Currently, this routine delays until the edge of the next second
rollover, in order to ensure that the time value in the kernel is accurate with respect to the
RTC.
However, this operation can take up to one full second to complete, and thus
introduces up to 1 second of variability in the total bootup time.
The synchronization in this routine is easy to remove. It can be eliminated by
removing the first two loops in the function get_cmos_time(), which is located in
include/asm-i386/mach-default/mach_time.h for the i386 architecture. Similar routines are
present in the kernel source tree for other architectures.
One tradeoff in making this modification is that the time stored by the Linux kernel is
no longer completely synchronized (to the boundary of a second) with the time in the
machine's realtime clock hardware. Some systems save the system time back out to the
hardware clock on system shutdown. After numerous bootups and shutdowns, this lack of
synchronization will cause the realtime clock value to drift from the correct time value.
Since the amount of un-synchronization is up to a second per boot cycle, this drift can
be significant. However, for some embedded applications, this drift is unimportant. Also, in
some situations the system time may be synchronized with an external source anyway, so the
drift, if any, is corrected under normal circumstances soon after booting.
8
3.3 Preset loops_per_jiffy
One of well-known method of kernel bootup time reduction is „preset_LPJ‟. The
value of loops_per_jiffy (LPJ) is normally calculated in the routine calibrate_delay() early in
the initialization sequence of the Linux kernel. The cost of doing this operation is
independent of the CPU frequency and is about 250 milliseconds on most hardware. The
value of LPJ should be the same for the same hardware operating at the same clock
frequency. Thus LPJ can be calculated once and used for subsequent boots, and the cost to do
the delay calibration can be avoided.
Basically, the patch allows us to specify a preset value for loops_per_jiffy at kernel
compile time or on the command line at kernel boot time. By using a pre-calculated LPJ
value, we can reduce loop overhead, and save bootup time.
3.4 Device Driver Initialization
To control HW units on system, the kernel device driver are needed. All device
drivers have initialize routines, and these are called during kernel bootup time. So optimizing
the device driver init routine will reduce kernel bootup time. The device driver can be loaded
into kernel as two ways, the static method and the dynamic method. During kernel bootup,
only static drivers are loaded, and dynamic drivers are loaded as modules after the bootup
sequence. So, if a device driver is not necessary on system init, it will be better using
dynamic loading rather than using static loading. By making device driver as module, we can
reduce device driver init time while booting. For example on Camera system, device drivers
that are not used on bootup sequence— USB, MPEG, STROBE, WDT, TV, etc. — as
modules, and loaded them at runtime.
3.5 Threaded Device Probing
Threaded device probing is a feature which allows drivers in the Linux kernel to have
their probes execute in parallel threads. One of the most time-consuming parts of the boot up
sequence is the probing by device drivers for their hardware devices.
This patch was created by Greg Kroah-Hartman and with it he was able to reduce the
bootup time of the kernel on one machine by about 400 milliseconds.
3.6 Deferred Initcalls
An "initcall" is the initialization function for a module which is statically linked into
the Linux kernel. Running of initcalls can consume a large amount of time during bootup.
However, some modules do not need to be initialized so early, in order for the embedded
device to become usable for its primary purpose. These initcalls can be run later, after first
boot (and possibly first use) has completed.
For example, many digital cameras have USB buses, which need to be initialized in
order for the camera to be used as a mass storage device (to download pictures to a desktop
9
computer). However, the USB buses do not need to be initialized for the primary use of the
camera, which is to take pictures. In order to be able to take a picture as soon as possible after
booting, initialization of the USB system in the kernel can be deferred until after the primary
boot sequence for the camera.
Using a short patch (available for kernel version 2.6.27) it is possible to avoid running
certain initcalls at bootup time. The way this patch works is that the developer selects some
initcalls that they want to defer and modifies the declaration of those initcalls.
When the system is booted, those initcalls are not called in their normal sequence.
When the system is done with primary boot, an application from user space triggers the
calling of the deferred initcalls, using a flag in the /proc filesystem.
When the flag is set, the deferred initcalls are run, and the kernel memory for the
"init" segment is finally freed.
Use:
To use deferred initcalls, first we need to identify the modules that are not required for
the primary functionality of the product, and which are taking too long to initialize.
Change the module init routine declaration for the initcalls we wish to defer. This is
done in the Linux kernel source code. For example, change:
“module_init(foo_init)”
with
“deferred_module_init(foo_init)”
After main init, do:
cat /proc/deferred_initcalls
This will cause the kernel to run all deferred initcalls. Also the .init section memory is
freed by kernel. The contents of /proc/deferred_initcalls will return 0 if deferred initcalls were
not yet run and 1 otherwise on subsequent reads.
10
Chapter 4: User-space and application speedups
4.1 Optimize RC Scripts
The init scripts of the existing Embedded Linux distribution are the shell scripts to be
executed with ‟bash‟. To reduce system boot time, some modifications to be applied to the
scripts and faster shell interpreter to be used.
BusyBox Optimization
Since ‟bash‟ and GNU utilities are very heavy applications, BusyBox is useful to
reduce system boot time. BusyBox combines tiny versions of many common UNIX utilities
(shellutils, fileutils, etc.) into a single small executable. The commands and utilities included
in BusyBox are divided into the classes: built-ins and applets. The built-ins are simply
invoked as functions, and applets are invoked by means of the ‟fork/exec‟ system calls. Also,
BusyBox scripts can use external commands and utilities.
Usage of the BusyBox built-ins is rather than the applets and external commands by
performance reasons, because the ‟fork/exec‟ system calls are very heavy and they make the
main contribution to shell inefficiency.
4.2 Init script
After kernel bootup, kernel executes init program which is located at /sbin/init. This
program does some tasks according to /etc/inittab script. For optimizing bootup time, it‟s
necessary to remove unused service on init script and to run only necessary applications. As
mentioned on before, this init script and applications are included in root file system,
CRAMFS. CRAMFS has an option which does not compress some area. By using this
option, we can reduce bootup time.
4.3 Lazy process creation
During system operates, many subtasks—like event processing, resource
management, image processing, power management—are executed. Many processes are
invoked for executing these tasks. When creating a process, system runs system call named
fork(). But invoking fork() wastes time about tens of ms. It is an overhead when used on
bootup time. So it is recommended to create processes when they are needed, not to create
them when booting the system.
11
4.4 Application Init Optimizations
This describes optimizations to a large application and to the kernel, to shorten the
time required to load and execute an application. The techniques described here are
applicable to a large number of embedded systems, which consist of large, single-application
programs.
Two main techniques are described here: 1) use of mmap vs. read and 2) control over
page mapping characteristics. These techniques are discussed below.
Using mmap() instead of read() for initial application data load
An application may load a large amount of data when it is first initialized. This can
result in a long delay as the file data is read into memory. It is possible to avoid the initial
cost of this read, by using mmap() instead of read().
Instead of loading all of the data into memory with the read system call, the file can
be mapped into memory with the mmap system call. Once the data file is mapped, individual
pages will be demand loaded during execution, when the application reads them. Depending
on the initial working set size of the data in the file, this can result in significant time savings.
(For example, if an application only initially uses 50% of the data from the file, then only
50% of the data will be read into memory from persistent storage. There is extra overhead
due to the cost of page-faults incurred in loading the pages on demand. However, this page
fault overhead is offset by the savings in the number of page reads (compared to the read()
case).
Eliminating redundant page copies
When pages are demand loaded to a memory-mapped file, the pages are kept in
memory as part of the kernel “file cache” and mapped into the requesting process's address
space. If the page is accessed via a write operation, then the page in the file system cache is
copied to a newly allocated memory page. (This is referred to as "copy-on-write"). The
copied page can be then be freely modified by the process which maps it.
Suppose, however, that a file is mapped or accessed by only one process. Then,
copying the page is redundant. In this case, we can convert the page in the file cache to a
private page immediately. By utilizing this assumption (only one user for the page), the cost
of the copy can be eliminated. This has the side benefit of reducing memory consumption as
well.
Reducing page faults
In some cases, an individual page in the process address space is accessed first with a
read operation, then with a write operation. This results in two page faults for the same page
(one to load the page and move it "through" the file cache, and the other to get a local copy of
the page.) By eliminating the page copy, and making the page private on the first access
(whether read or write), the second page fault can be reduced.
12
4.5 Other Techniques
Avoid udev, it takes quite some time to populate the /dev directory. In an embedded
system it is often known what devices are present and in any case we know what
drivers are available, so we know what device entries might be needed in /dev. These
should be created statically, not dynamically. mknod is preferable over udev.
If device has a network connection, preferably use static IP addresses. Getting an
address from a DHCP server takes additional time and has extra overhead associated
with it.
Moving to a different compiler version might lead to shorter and/or faster code. Most
often newer compilers produce better code. we might also want to play with compiler
options to see what works best
If possible move from glibc to uClibc. This leads to smaller executable and hence to
faster load times.
library optimiser tool:
o This will allow us to create an optimised library. As unneeded functions are
removed this should lead to a performance gain. Normally there will be library
pages which contain unused code (adjacent to code that is used). After
optimizing the library this does not occur anymore, so fewer pages are needed
and hence less page loads, so some time can be saved.
13
Chapter 5: Other Optimization Methods
5.1 Boot Time with various file systems
Root file system (RFS) is essential element for running kernel on embedded system.
There are many file systems, and these can be used as Linux root file system. Each file
system has its own functionality, various bootup methods with different bootup time. There
are many sub works to do for mounting file system. For example, decompressing the
compressed file system, copying itself from storage device to memory, searching the file
system contents, searching inodes, journaling, and so on. Therefore, the reduction of RFS
mounting time is very important.
To minimize mounting time, we should use the CRAMFS as root file system. The
CRAMFS is designed for simple and small file system, so it has smaller bootup time
comparing to other file systems. The CRAMFS reads only super block among entire file
system element while it mounting root file system. We can have relatively short boot time
using the CRAMFS. While the CRAMFS has a shorter boot time, it has some demerits. It can
be used only with read-only attribute, so it‟s recommended that use the CRAMFS only on
boot area, and use another file system on other area that needs to read and write operation.
But if we use special options for CRAMFS, specific directories would not be compressed, so
we can save the mount time.
Noboru Wakabayashi of Hitachi provided the following report.
On the OMAP Innovator he built the following file systems:
CRAMFS
CRAMFS with XIP
ROMFS
JFFS2
ext2 over RAM disk
He measured the time to initialize these file systems by logic analyzer. This was done by
modifying the busybox init program to make LED turn on red. When innovator power on, the
LED lights up green. So the time from the light turning from green to red was measured.
Also, he measured the time using KFI (from start_kernel() to to_usrspace()). Comparison
14
Results are shown in the following table.
Figure 3 Comparison between different Configuration/Filesystem
He remeasured the time to initialize "CRAMFS with XIP and PLPJ" using the "quiet"
option. The result is 280676 usec from start_kernel() to to_userspace(). The above result is
551735.5 usec. The time is reduced about 50%.
5.2 Suspend related improvements
Another approach to improve boot time is to use a suspend related mechanism. Two
approaches are known.
Using the standard hibernate/resume approach
Implementing snapshot boot
5.2.1 Software Suspend/Resume
The software Suspend / Resume Boot method is based on laptop use. When the
suspend function is operated, the system information is stored in the auxiliary memory and
the system is terminated. Then, at subsequent bootup, it performs a resume process to restore
the previous state without general loading. The information retained includes the memory, the
state of each task, and the device driver.
The system suspend/resume is also one of the power management method. System
suspend means that all power of the system break down except SDRAM, and in SDRAM on
which we store current system information like as cpu register, I/O map information. System
suspend means that there is no power in the system except SDRAM and the system
remembers its state in SDRAM like as cpu registers, I/O device status, runtime global/local
variables, etc.
When system receives specific events like as power button, the resuming procedure
will be started. The first thing for resuming is supplying power and initializing the CPU,
memory, etc. And next check if current state was in resume mode and restore all data which
was in SDRAM. If we use the suspend/resume method, reducing bootup time has good
15
efficiency, because only restoring system information from the memory is needed. Additional
works to do is initialize some devices like as LCD, Motor, CCD, Image Processing Devices.
Figure 4 Software Suspend / Resume Boot flow diagram
5.2.2 Snapshot Boot
Snapshot boot uses the existing system resume to reduce application startup time by
loading a fixed, pre-made system image to RAM. Snapshot boot uses boot loader/kernel
cooperation to minimize the system initialization needed prior to resume.
Snapshot boot is a fast boot method used to improve the software suspend/resume
boot method. The software suspend/resume boot method restores the previous system using a
snapshot image of its own memory. Therefore, it should be performed for the loading and
initiation of kernels. It can subsequently be restored using a snapshot image. The image of the
kernel is saved at the snapshot image, and the kernel control flow is also restored. Therefore,
it causes the overhead with loading kernel for performing to resume. Moreover, it needs to
perform the copy function twice to restore the snapshot image from the kernel.
Figure 5 Snapshot Boot flow diagram
16
Conclusion
The Software Suspend/Resume and Snapshot Boot methods reduce boot time
compared to the Normal Boot method; however, they cannot manage exceptional situations,
as they must generate a snapshot image for each ending.
By applying combination of above different methods in three main software
components “Bootloader”, “Kernel” and “Applications”, we can get reduced system Startup
time by 50%.
17
References
[1] Bootup time improvement for embedded Linux using snapshot images created on
boot time,
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&tp=&arnumber=5967499
&contentType=Conference+Publications&
[2] To setup and use XIP in the kernel and the CRAMFS filesystem,
http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP
[3] W.L. Park, W.J. Na, C.I. Park, “Improving Bootup Time using Delayed Devices
Probing,” Proc. of the KIISE Korea Computer Congress, 2006.
[4] Suspend To Disk For ARM, http://elinux.org/Suspend_To_Disk_For_ARM
[5] Standard hibernate/resume approach, http://www.kernel.org/doc/ols/2006/ols2006v2-
pages-239-248.pdf
[6] Booting Linux faster,
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6418839&contentTyp
e=Conference+Publications&
[7] http://tree.celinuxforum.org/CelfPubWiki/BootupTimeReductionHowto
[8] http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time