Analysis Results

The factors, no mater hardware or software, all have influence on some phases in the boot times. But at some phases some factors only have minor influence.

With those changes can’t have many improvement of boot time reduction. So according to the section 5.3, there are some major factors which lead to great improvements at some phases.

The experiments are done on OMAP5912osk and PXA270 platforms. Both platforms have different architectures.

OMAP5912 have great improvement in boot time when modify the CPU and memory clock frequency. But PXA270 only have improvement at fewer phases when modify the CPU and memory clock frequency.

Different file-system types only major affect the phase 10, 11, and 12 of boot time in both platforms. When it is using kernel 2.6.15, the time phase 12 don’t affect by different file-system types. But kernel 2.4.20 will. Because the architectures are different, the higher CPU and memory clock frequency could get great improvement in phase 10, 11, and 12 with different file-systems type on OMAP5912 platform. But on PXA270 platform those two factors modifications don’t affect such more times of phase10, 11, and 12 when using JFFS2, Cramfs and Squashfs.

Compression algorithm could be change at both the kernel image and file-systems. But the kernel image with different compression algorithm only could be used at U-boot on PXA270 platforms. The decompression speed is very slow under U-boot stage. When using LZMA compression algorithm for the Squashfs, the times will be longer than original one using zlib. But when the system has the powerful processor, the Squashfs with LZMA algorithm could almost reach the same time as original with zlib algorithm.

Because only OMAP5912 could switch the internal cache on/off, the results of experiments are that only I-cache affects the time of U-boot and both I-cache and D-cache affect the time of the Kernel.

When changing to the new version kernel and U-boot on OMAP5912 platform, the new version kernel need more time for boot-up and new version U-boot need less time for boot-up. The kernel version 2.6.15 support more features by default and enhance the features from old version 2.4.20. So the large size of image also affect the boot time of the boot-loader. The U-boot version 1.1.3 optimizes the initialization process of U-boot and improves the methods of verification and movement of kernel image.

Boot time is related to the system architecture, software factors, hardware factors and related peripherals. So according to the analysis at section 5.4.3 and experiments results of section 6.3, there are some conclusions of this chapter:

OMAP5912, with Dual-core architecture, have more flexible bus architectures so the faster CPU and memory clock frequency could have great improvement in boot time. But after the frequency ratio of the CPU and the memory bus over 4:1, the improvement will slow down. Because of the flexible bus architectures, when using different type of file-systems, the modification of CPU and memory still could improve the boot time. Dual-core architecture also separates the peripherals

into two groups and this will reduce the initialization of boot time.

PXA270, with single-core architecture, major use system bus for all communication between processor and peripherals. So even using higher CPU and memory clock frequency, the improvements are limited. When it is at the phase needing frequently peripherals access, the boot-up speed is bounded by the bus architecture. Even using powerful single-core processor, there are many peripherals needed to be initialized by the processor. So it needs more time for booting up the system.

The kernel image configurations of these two platforms are all using the default configuration of the Linux kernel. But these two platforms supporting different peripherals and default inserted different device drivers. So the kernel initialization time at the kernel stage will much different of these two platforms.

Therefore in the thesis it is more focused on the factors related to each phases.

Chapter 6 CONCLUSION

More and more multimedia device are developed. The trend is using open source Linux kernel as system operating system. The boot time of such device are become longer and longer. So in this thesis we use two platforms, OMAP5912 and PXA270, to analysis the Linux system boot time. Because Linux is not a real-time OS, it needs extra DSP core or one more powerful processor to handle many real-time applications. We choose one Dual-core platform and on powerful single-core platform as our experimental platforms. Then we modify the hardware and software factors of boot time to see which factors play a major role in the boot time and the relationship between hardware and software factors.

According to the architecture analysis and the experimental results, we found that Dual-core architecture has benefits to reduce the boot time of systems.

Dual-core has more flexible bus architectures and separates the peripherals into two groups to reduce the initialization time of boot-up. The hardware factors improvements in Dual-core platform have better impact on software factors change.

According to the boot procedures analysis and experimental results, we could know that the boot procedures are most related to the memory device access.

Because all hardware related assembly code, software functions and device drivers are needed to execute between the main processor and memory devices.

The total boot times of the embedded Linux system are most bounded by the memory bus. However the platform selection is usually restricted, so how to achieve the boot time optimization under limited environments is more important.

In the thesis we point out which factor has major influence on which phase.

When you have a different embedded Linux system for your application, but some factors are fixed. For example CPU frequency is not higher, memory size is limited, or new kernel version is chosen, we could focus on the phases which is major bounded by these factors, such as to lower the CPU usage, to choose the higher compression ratio but fast compression algorithm, or remove the unused

functions in the new kernel version to achieve the boot time optimization.

Chapter 7 Future Work

We already know some factors are the major factors of the boot times. But the experiments of these factors are also limited by the platforms we chosen. Except these factors, we’ll try to analysis the influence of the MMU supported and different compiler modes.

The boot procedures should be also related to the MMU supported or not. The MMU supported should have the better memory utilization and easier software programming. But if the systems boot up phases need less memory requirements or not bounded by the memory, MMU supported or not should not serious affect the boot times. When the systems boot up need large memory requirements, the MMU supported should benefit the boot time of memory bounded phases.

Using different compiler modes to supports the 32-bit ARM or 16-bit Thumb instruction sets, it could provide the user to trade off between high performance and high code density so it will also affect the boot time of the systems. It could reduce the code size of user application program if supporting Thumb instruction in the kernel. But these modifications may affect the existing software module execution and let special 3^rd party applications unstable.

REFERENCES

[1] The Consumer Electronics Linux Forum, “Kernel Execute-In-Place,”

http://tree.celinuxforum.org/CelfPubWiki/KernelXIP [2] Jimmy Wennlund, “Next Generation Init System – InitNG,”

http://www.initng.org/

[3] Keun Soo Yim, Jihong Kim, and Kern Koh, “A Fast Start-Up Technique for Flash Memory Based Computing Systems,” Proceedings of the ACM Symposium on Applied Computing, 2005

[4] Tim R. Bird, “Methods to Improve Boot Time in Linux,” Proceedings of the Ottawa Linux Symposium, Sony Electronics, 2004

[5] Linus Torvalds, “The Linux Kernel Archives,” http://www.kernel.org/

[6] Wolfgang Denk, “Das U-Boot - Universal Bootloader,“

http://sourceforge.net/projects/u-boot/

[7] Rob Landley, “BusyBox - The Swiss Army Knife of Embedded Linux,”

http://www.busybox.net/

[8] Alessandro Rubini, Jonathan Corbet, “Linux Device Drivers, Second Edition,” O'Reilly Media, Inc., 2001

[9] Texas Instruments, “OMAP5912 Applications Processor (Rev. E),”

http://www-s.ti.com/sc/ds/omap5912.pdf

[10] Texas Instruments, “OMAP5912 Multimedia Processor OMAP3.2 Subsystem Reference Guide (Rev. B),”

http://www-s.ti.com/sc/psheets/spru749b/spru749b.pdf

[11] Texas Instruments, “OMAP5912 Applications Processor Silicon Errata (Rev.

I),” http://focus.ti.com/lit/er/sprz209i/sprz209i.pdf [12] Intel, “PXA27x Processor Family Developer's Manual,”

[13] Intel, “PXA27x Processor Family EMTS,”

[14] Intel, “Intel XScale Core Developer's Manual,”

[15] Intel, “PXA27x Processor Family Specification Update,”

[16] Catherine Dodge, Cynthia Irvine, and Thuy Nguyen, “A Study of

Initialization in Linux and OpenBSD,” ACM SIGOPS Operating Systems Review, Vol. 39, Issue 2, pp. 79-93, April 2005

[17] Alessandro Rubini, “Kernel Korner: Booting the Kernel,” Linux Journal Volume 1997, Issue 38es

[18] Kingsley Morse Jr., “Compression Tools Compared,” Linux Journal Volume 2005, Issue 137

[19] The Consumer Electronics Linux Forum, “Kernel Function Trace,”

http://tree.celinuxforum.org/CelfPubWiki/KernelFunctionTrace [20] The Consumer Electronics Linux Forum, “Printk Times,”

http://tree.celinuxforum.org/CelfPubWiki/PrintkTimes [21] Don Libes, “Exploring Expect,” O'Reilly Media, Inc., 1994

[22] ARM Limited., “ARM9EJ-S Revision r1p2 Technical Reference Manual,”

http://www.arm.com/pdfs/DDI0222B_9EJS_r1p2.pdf [23] Palm Inc., “Palm Tungsten E2 Datasheet,”

http://www.palm.com/us/products/handhelds/tungsten-e2/tungsten-e2_ds.pdf [24] Chih-Chien Yang, “An Empirical Analysis of Embedded Linux Kernel 2.6.14 to

Achieve Faster Boot Time,” Master Thesis, National Chiao-Tung University, 2006 [25] Sony, “Sony Cyber-shot series DSC product specification,”

http://www.sonystyle.com.tw/intershoproot/eCS/Store/en/html/spec/dsc_spec.html [26] L.-P. Chang and T.-W. Kuo, “An Efficient Management Scheme for Large-Scale

Flash-Memory Storage Systems,” In Proc. of the ACM Sym. on Applied Computing (SAC), pp. 862-868, 2004

[27] J. Kim, J. M. Kim, S. H. Noh, S. L. Min, and Y. Cho, “A Space-Efficient Flash Translation Layer for CompactFlash Systems,” IEEE Trans. on Consumer Electronics, Vol. 48, No. 2, pp.366-375, 2002

[28] M. Wu and W. Zwaenepoel, “eNVy: A Non-Volatile, Main Memory Storage System,” In Proc. of the ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pp. 86-97, 1994.

[29] D. Woodhouse, “JFFS: The Journaling Flash File System,” In Proc. of the Ottawa Linux Symposium (OLS), RedHat Inc., 2001

[30] Aleph One Company, “The Yet Another Flash Filing System (YAFFS),”

http://www.aleph1.co.uk/yaffs/

[31] LILO (The Linux Loader), http://freshmeat.net/projects/lilo/

[32] GRUB (Grand Unified Boot Loader), http://www.gnu.org/software/grub/

APPENDIX

TIMING MEASUREMENT

In the embedded system, it is difficult to measure the timing of the system operation.

Most of features are supported by the SoC in the system, but the SoC just like a black box for the detail timing measurements. There are two kinds of methods to measure the time of embedded system operations. One method is by hardware instruments, and the other method is by software functions.

A.1 Instruments

The latest SoC, included more and more features, is difficult to know how it work inside the chipset by external measurement methods. But according to the signals between the processor and related peripherals and the software operation flow, we could find the operations of system boot-up. The oscilloscope and the logic analyzer are two hardware instruments to measure the external signals between chipsets.

A.1.1 Oscilloscope

The oscilloscope is used to measure the analog signal and the transition state of signals. For better accuracy, the sampling rate of the oscilloscope should be four times the frequency of the signal or the system bus. However the oscilloscope will be interfered by some random glitches, so the digital signals are not measured by oscilloscope.

The voltage level is the major item to decide the start point of boot time. Generally the voltage level would be measured by oscilloscope because the trigger point is at the transition state. We use Agilent DSO 54831B, which bandwidth is 600MHz and its sample rate is up to 4 GSa/s, to measure the first period of boot time.

The system power-on behavior is related to measure the first period of boot time, so the signal pins of chipsets related to system power-on are described below and will be captured by oscilloscope:

1. Vin point on the board: The voltage of system reach the minimum

requirement of reset circuit, then reset circuit will assert the reset signal to the MPU.

2. nReset pin of MPU: After the nReset pin is de-asserted (From low to high in most cases), then the MPU will start to do the hardware initialization.

3. RS232_TX pin on the board: After console portion in the MPU is initialized, then 1st mark will be sent out.

The Figure 38 shows the signals of Vin, nReset, and RS232_TX captured by Oscilloscope 54831B.

Figure 38: Power-on Sequence captured by Oscilloscope A.1.2 Logic Analyzer

The Logic Analyzer is used for digital signals measurements. It only could detect logic high and low level. The transition state of signal can’t be detected by it, but it also can reduce the interference of random glitches. Logic Analyzer could use to measure the long period the timing. But the length of the time depends on the number of signals you measured, the sampling rate used, and the memory depth of Logic Analyzer.

We use Tektronix TLA5202, which has 68 channels, 2GHz conventional timing rate and 512KB memory depth, for boot time measurement. For measuring the period of

boot time, the related signal pins captured by Logic Analyzer are described below:

1. nReset pin of MPU: After the nReset pin is de-asserted (From low to high in most cases), then the MPU will start to the do hardware initialization.

2. nRST_OUT pin of MPU: When MPU start to do hardware initialization, nRST_OUT to external peripherals is still asserted. After MPU initialization is finished, nRST_OUT is de-asserted and then MPU read 1^st instruction from the boot device.

3. SDRAM_CLK pin of MPU: Used for checking when SDRAM Controller is ready.

4. nFlash_CSx pin of MPU: Used for checking when to access Flash.

5. LCD_PCLK pin of MPU: Used for checking when LCD controller is ready.

6. RS232_TX pin on the board: After console portion in the MPU is initialized, then console marks will be send out. Use these marks to measure the boot time of different boot phases.

The Figure 39 shows the signals of the boot sequence of OMAP5912osk captured by Logic Analyzer TLA5202.

Figure 39: Boot Sequence captured by Logic Analyzer

A.2 System Functions

There are many software methods to measure the boot times: Kernel Function Trace (KFT) [18], Printk-times [19], initcall-times, expect [20]. For the best accuracy and the least influence on the boot time, Printk-times and initcall-times are used for boot time measurement in this thesis.

Printk-times and initcall-times only could be used for kernel stage timing

measurement and are not supported at Linux kernel version 2.4.xx. By modifying the source code to output function names or marks on console and cooperating with oscilloscope and logic analyzer is another method to measure the boot time.

A.2.1 Printk Times

Printk-times is a simple technology which adds some code to the standard kernel printk routine, to output timing data with each message. While a crude status, this can be used to get an overview of the areas of kernel initialization which take a relatively long time. This feature is used to identify areas of the Linux kernel requiring work. This feature was incorporated into the mainline Linux kernel as of version 2.6.11. Before this version need additional patch to support this feature in kernel. But for version 2.4.xx, there is no patch to support this feature in kernel at ARM based architecture.

With Printk-times turned on, the system emits the timing data as a floating point number of seconds (to microsecond resolution) for the time at which the printk started.

The utility program shows the time between calls, or it can show the times relative to a specific message. This makes it easier to see the timing for specific segments of kernel code during boot.

For least influence on the boot time, this feature must be used dynamically. It could be done by putting the parameter “time” on the command line to enable it. After using Printk-times dynamically, we observe that not all kernel messages have the timestamp until the kernel commands have passed to kernel.

A.2.2 initcall-times patch

Matt Mackall provided an initcall-times [13] patch which measures times for the initialization of each driver during do_initcalls. This is a special tool to look at the time of initialization of buses and drivers. It times just the initcalls and is enabled by putting the parameter “initcall_debug” on the command line. The records of device initializations can be read by dmesg after boot and use grep to find time-consuming initializations

The default value of CONFIG_LOG_BUF_SHIFT is 14, so the kernel ring buffer size is 214B = 16 KB [16]. This is not sufficient to save all the messages with the additional information of initcall-times patch. The kernel ring buffer size must be

modified to 128 KB by setting to CONFIG_LOG_BUF_SHIFT to 17 to fit with the requirement of initcall-times patch.

A.2.3 Time Stamp

In order to measure further detailed time periods of the specific functions, modifying the source code to output function names or marks on console and hiding the other messages on the console are other methods for boot time measurement [24].

z Boot-loader: In the source code of U-Boot, we use puts to output U-Boot function names.

z Linux Kernel: In the source code of Linux kernel, we use printk(KERN_EMERG “ ”) to output kernel function names.

z User Space: In the source code of BusyBox, we use fprintf(stderr, “ ”) to output user space function names.

A.3 Inaccuracies

When we modify the source code and add some extra marks to output on console, there are some inaccuracies by the method.

Additional output console messages will make boot time longer. More messages output on console, then more time MPU need to take to handle these processes.

When the baud rate of console setting is 115200 bps, then 1 bit data sent by console is taken about 8.68 us. The logic analyzer enabling all memory depth could capture data about 5 sec at 10us sampling rate, about 10 sec at 20us sampling rate, and about 52sec at 100us sampling rate. When the boot time is taken longer, slower sampling rate will be used. But this will increase the inaccuracy of the sampling data. There are some methods to increase accuracy:

z During the time measurement of boot time, skipping the time of output console message will reduce the influence of boot times.

z When the baud rate of console setting is 9600 bps, then 1 bit data sent by console is taken about 104.16 us. Then we could use slower sampling rate for boot time measurement. But baud rate setting at 9600 bps will let output console messages taken long time. This boot time longer. When console print out more

z When the baud rate of console setting is 9600 bps, then 1 bit data sent by console is taken about 104.16 us. Then we could use slower sampling rate for boot time measurement. But baud rate setting at 9600 bps will let output console messages taken long time. This boot time longer. When console print out more