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 Sequence1 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 Startup6 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

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

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.

 Bootchart - a tool for performance analysis and visualization of the Linux boot process. Resource utilization and process information are collected during the userspace 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.

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.

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.

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.

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.

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

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.

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, its 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 subtaskslike event processing, resource management, image processing, power managementare 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.

10

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.

11

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.

12

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 its 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

13

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

14

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

15

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%.

16

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/ols2006v2pages-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

17