Reducing boot time is a matter of doing one of the following: reducing what happens during boot or delaying activities so that the boot-up time is broken up and the system appears to start more quickly. This section looks at what to do from a kernel and root file system perspective.
Reducing Kernel Boot-Up Time
The kernel boots rather quickly, even with no attempts to make it go faster. In the example, an unmodified kernel for a 400Mhz arm board boots in about seven seconds from power-up, and three of those seconds are spent by the boot loader waiting for the user to interrupt the boot process (the measurement was done on a device still used for development). This means the device is ready to run user programs in about four seconds. This also means speeding up the kernel boot process is a series of changes that reduce the speed in the quarter- to half-second range; with effort, you can reduce the time to about two or three seconds, which is in the range of a digital camera. Also notice that the choice of root file system is the largest predictor of boot time for the kernel. In the example, using a JFFS2 file system takes a breathtaking six seconds to mount for 50MB flash storage. When using a read-only file system, the mount time is in the subsecond range. If you need to have a large, solid-state drive, consider getting hardware that has flash memory that appears as though it’s a standard block-based device, similar to a USB memory stick.
Uncompressed Kernel Image
Most boot loaders expect the kernel to be in a compressed format. The boot loader uncompresses the image during the boot process: this process takes time, and sometimes a kernel that is uncompressed starts booting faster. You have to measure on your target system to be sure, because the time to uncompress varies greatly and there’s no rule of thumb about what performs faster. If you have U-Boot as your boot loader, you need to create an uncompressed U-Boot image. Do so with the following command:
This command is very similar to the command used to create a compressed kernel image file. It uses the uncompressed object file (Image) instead of the compressed one (zImage). Of course, this file is larger. That’s a classic engineering tradeoff: size for speed. Because creating an image like this is fairly easy, you should test what works best on the target system if flash space isn’t at a premium.
No Console Output on Boot
No doubt you’ve watched the messages go by during the boot process. Producing these messages costs time, because the system must interact with a much slower I/O device to print out the data. If that slow device is a serial connection, the messages themselves can produce a delay of close to a second. On the target board, try the following commands:
Or copy the contents of the dmesg command to your development host, and use the wc command. wc -c counts the number of characters in the file. Divide this number by the baud rate of the serial port, and you can estimate in seconds the time to get this output written to the console. For example, if wc –c returns 18530 and the baud rate for the serial port is 115200, the kernel spends almost a fifth of a second waiting for output to be written to the serial port. When the output rate of the port is 9600 baud, the delay is nearly two seconds. The time differences are less for a VGA console, which is about twice as fast as a 115200 serial line, but this is still wasted time.
To remove these messages, add the parameter quiet to the kernel command line. Unlike when you disable printk, the messages are still generated, but they aren’t displayed to the console during boot time. Using quiet instead of removing printk from the kernel means you can easily return to the more verbose output without recompiling the kernel; you just need to change the parameters passed to the kernel by the boot loader.
Deferred initialization works by delaying the initialization code for kernel modules that have been compiled into the kernel. After the kernel boot, you write into the /proc/deferred_initcalls, and the remaining initialization code runs. This feature makes sense when there are peripherals that you won’t be using immediately under most circumstances. For a device that periodically collects data and uses the network to report batches of data, you can delay initialization of the network device so the device can begin collecting data as soon as possible. It’s important to note that the same time elapses, but some of the code is run later when time is less critical.
Using this feature requires you to apply a patch to your kernel. This patch has been tested with a kernel version that’s always a few releases behind the mainline kernel. You can download the patch by doing the following:
After you apply the patch, you need to modify the source files of the modules for which you want to delay initialization. Using the prior example, if the device’s network card (SMC91x) can be initialized later, you modify the driver like so:
The function call module_deferred_init queues up initialization calls until you request that they be executed. This is done through a file like so:
This then begins executing all f the initialization functions queued up through calls to module_deferred_init. This operation can occur only once; subsequent writes to /proc/deferred_initcalls will produce an error message indicating that the call was already performed. Recall that the proc file system doesn’t exist on disk but is a view into the kernel’s data structures. The /proc/deferred_initcalls file isn’t really a file in the traditional sense; when a write occurs on /proc/deferred_initcalls, the result is the execution of the initialization calls instead of that data being stored some place. Because the initialization of a driver requires poking at the hardware, this is a time-consuming process. Being able to bring up the essential devices for your target can produce a substantial time savings. The biggest drawback of this approach is that is requires modifications throughout the kernel and a knowledge of how the device is used so that you defer initialization of the correct set of drivers.
Linux Embedded systems Related Tutorials
Linux Embedded systems Related Interview Questions
|Linux Embedded systems Interview Questions||Red Hat Linux Essentials Interview Questions|
|Red Hat Linux System Administration Interview Questions||Ubuntu Certified Professional Interview Questions|
|IBM AIX Interview Questions||Solaris Interview Questions|
|HP-ux 11iv3 system administration Interview Questions||Red Hat cluster Interview Questions|
|Embedded C Interview Questions||Unix/Linux Interview Questions|
|Unix Shell Scripting Interview Questions||Solaris Administrator Interview Questions|
Linux Embedded systems Related Practice Tests
|Linux Embedded systems Practice Tests||Red Hat Linux Essentials Practice Tests|
|Red Hat Linux System Administration Practice Tests||Ubuntu Certified Professional Practice Tests|
|IBM AIX Practice Tests||Solaris Practice Tests|
|HP-ux 11iv3 system administration Practice Tests|
Linux Embedded Systems Tutorial
About Embedded Linux
Configuring The Software Environment
Target Emulation And Virtual Machines
Starting Your Project
Getting Linux For Your Board
Creating A Linux Distribution From Scratch
Booting The Board
Configuring The Application Development Environment
Kernel Configuration And Development
Using Open Source Software Projects
Handling Field Updates
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.