Chapter 3 MULTIMEDIA DEVICE
3.4 Analysis
3.4.3 Bottlenecks
From boot time point of view, we would like to analysis which portion will be the bottleneck of each platform.
OMAP5912 has more flexible bus architecture, but the relationship between TC (Traffic Controller) clock and MPU clock, and Flash clock and TC clock will be the bottleneck of boot time. Max. TC clock is half of max. MPU clock so max. TC clock is 96 MHz. But max. MPU clock is 192MHz. Max. flash clock is 48MHz and it is always 1/6 of TC clock. MPU TIPB (TI peripheral bus) (public and
private) also has max strobe freq., 48MHz.
PXA270 use one system bus for many subsystems. So the system bus will be bottleneck. It also will be the bottleneck on peripheral bus. There are too many peripherals connected to peripheral bus, and these peripherals take more time when doing hardware initialization. Its memory controller also uses to connect to external ASIC. This will be the bottleneck of memory access when the external ASIC and PXA270 have busy communication.
Chapter 4 LINUX BOOT-UP
A computer system is a complex machine [16], and the operating system is an elaborate tool that orchestrates hardware complexities to show a simple and standardized environment to the end user.
Currently Linux is the most popular operating system because of its open source policy. For embedded systems, Embedded Linux is the cost effective operating system which refers to the open source Linux. We’ll introduce the normal Linux boot-up steps on PC and embedded systems, then boot factors and boot sequence of Embedded Linux will be discussed.
4.1 Overview
The PC is more widespread use than other platforms so Linux boot-up steps on the x86 PC will be introduced first. In order to be able to use the computer when the power is turned on, the processor begins execution from the system's firmware.
It is called the Basic Input-Output System (BIOS). BIOS functionalities are Power-on Self Test (POST), system configuration set-up and execution code from boot device. Then boot-loader located at boot device is loaded by BIOS services.
The boot-loader’s major features are basic hardware initializations, uncompression/execution of the kernel image. After boot-loader transfer control to kernel [17], kernel will do the whole system initializations and then execute the user space program from the file-systems. Then system is ready for user.
The embedded system is always resource constrained. There is no any BIOS on the embedded system. The BIOS is substituted by power-on strapped pins or internal boot ROM of the processor. Because the storage and memory are also limited, the boot-loader, kernel subsystems, file-system are modified to suit for embedded systems. The Linux boot-up steps on the embedded systems are from boot-loader execution, to kernel image copied to ram, uncompressed then execution and finally load program from root file-systems at user space.
4.2 Boot Sequences
The boot sequence could be divided into four stages: Hardware Initialization, Boot-loader, Kernel and User Space (Figure 7). For more detail analysis, each stage could be subdivided into more phases:
Figure 7: Boot Sequence main stages
4.2.1 Hardware Initialization
There are two phases in the hardware initialization stages (Figure 8):
z Phase 1: The time for the MPU reset
It is measured from Power-On (Vin stable) to signal MPU_Reset de-asserted.
From the Vin becoming stable (MPU_nReset low) to the signal MPU_nReset becoming high. When the power input of the MPU is stable, oscillator input of MPU is also stable then MPU exit reset mode.
z Phase 2: The time for the MPU initialization and the Peripheral reset
It is measured from signal MPU_Reset de-asserted to signal MPU_RST_OUT de-asserted.
From the signal MPU_nReset becoming high to the signal MPU_nRST_OUT becoming high. MPU exit reset mode then doing simple hardware configuration by reading power-on strap-pins or reading internal boot ROM. After finishing the configuration, then the nRST_OUT signal to other peripherals is de-asserted.
MPU read the 1st instruction.
Figure 8: Hardware Initialization
4.2.2 Boot-loader Stage
There are four or five phases in the boot-loader stages (Figure 9). When the kernel image is uncompressed at kernel stage, there are only four phases. When
the kernel image is uncompressed by the boot-loader, there are five phases in the boot-loader stage:
z Phase 3:
It is measured from the signal MPU_RST_OUT de-asserted to function env_relocate_spec() finished.
From the signal MPU_RST_OUT becoming high and to the last signal of Flash_CS for function env_relocate_spec() finished (the last signal Flash_CS rising edge before env_relocate_spec() finished). MPU read the 1st instruction to do simple hardware initialization then U-boot starts and prepares to execute the first function which access flash. Then the environment parameters of U-boot are relocated.
z Phase 4:
It is measured after the function env_relocate_spec() finished and before the kernel image checksum verify starting.
z Phase 5:
It is measured from the kernel image checksum verify starting to copy image to ram finished.
From the signal RS232_TX of function image checksum verify start to the signal RS232_TX of function copy image to ram over. U-boot verifies the checksum of kernel image. If the checksum is correct, then U-boot copies the kernel image from the flash to system memory.
4.2.2.1 Case 1-Kernel Uncompress Image
z Phase 6:
It is measured from copy image to ram finished to the function cleanup_before_linux() finished.
From the signal RS232_TX of function copy image to ram over to the signal RS232_TX of function cleanup_before_linux() finished. Boot-loader transfers the control of system to Linux kernel.
4.2.2.2 Case 2-Boot-loader Uncompress Image
z Phase 6’:
It is measured from copy image to ram finished to uncompress kernel image finished.
From the signal RS232_TX of function copy image to ram over to the signal RS232_TX of uncompress kernel image finished. Boot-loader uncompress the kernel image.
z Phase 7’:
It is measured from uncompress kernel image finished to the function cleanup_before_linux() finished.
From the signal RS232_TX of uncompress kernel image finished to the signal RS232_TX of function cleanup_before_linux() finished. Boot-loader transfers the control of system to uncompressed Linux kernel.
Figure 9: Boot-loader stage
4.2.3 Kernel Stage
There are three or four phases in the kernel stages (Figure 10). When the kernel image is uncompressed at boot-loader stage, there are only three phases. When the kernel image is uncompressed at the kernel stage, there are four phases in the kernel stage:
4.2.3.1 Case 1-Kernel Uncompress Image
z Phase 7:
It is measured from the function cleanup_before _linux() finished to before the uncompress kernel starting.
From the signal RS232_TX of function cleanup_ before_linux() finished to the signal RS232_TX of function Uncompress kernel start. Linux kernel gets the controls and prepares to uncompress kernel.
z Phase 8:
It is measured from the uncompress kernel starting to the uncompress kernel finished.
From the signal RS232_TX of function Uncompress kernel start to the signal RS232_TX of function Uncompress kernel over. Linux kernel image is uncompressed and prepare to start the kernel.
4.2.3.2 Case 2-Boot-loader Uncompress Image
z Phase 8’:
It is measured from the function cleanup_before _linux() finished to before start_kernel.
From the signal RS232_TX of function cleanup_ before_linux() finished to before start_kernel. Linux kernel gets the controls and prepares to start the kernel.
z Phase 9:
It is measured from the uncompress kernel finished to before file-system initialization/built.
From the signal RS232_TX of function Uncompress kernel over to the signal RS232_TX of function File-system built/fill super start. Linux kernel uncompress and execute routine start_kernel, Linux kernel doesn’t access the flash until the routine mount_root.
z Phase 10:
It is measured from before file-system initialization/built to before Invoke /sbin/init.
From the signal RS232_TX of function File-system built/fill super start to the
signal RS232_TX of function File-system built/fill super over. Root File-system is built by kernel.
Figure 10: Kernel stage
4.2.4 User Space Stage
There are two phases in the user space stages (Figure 11):
z Phase 11:
It is measured from Invoke /sbin/init to before RC script start.
From the signal RS232_TX of function Invoke init to the signal RS232_TX of function RC Script start. Linux kernel invokes the sysvinit tool: /sbin/init then init_main started for user space and prepares to run RC Script.
z Phase 12:
It is measured from RC script start to shell prompt output finished.
From the signal RS232_TX of function RC Script start to RC Script starts several daemons. Then RC Script is finished and shell prompt is enabled.
Figure 11: User Space stage
4.3 Impact Factors
In this thesis we would like to investigate the Embedded Linux boot process and find the related factors of reducing boot time. According to the platforms comparison and Linux boot procedure analysis , we induce that both hardware factors, including processor frequency, memory and I/O access speed, and software factors, including OS kernel, drivers, subsystems selection and compression algorithms, would affect the boot time. The major factors are as following:
4.3.1 Hardware Factors
1. Processor frequency: During boot process, there are greatly computing power requirements and complexity instruction operations. So faster processor frequency will help on the reduction of the boot time.
2. Internal cache: Increase the cache size will help on instruction operations in the processor. Different kinds of internal cache will help on different instruction operations.
3. I/O access speed: With more peripherals, faster I/O access speed will reduce the peripherals initialization times.
4. Memory access speed: During boot process, there are huge mount of data access requirements. There will be more reduction of boot time when faster memory access speed is adopted.
5. Board specific hardware: Some board specific hardware will affect the boot time. For example: reset timing requirements of different processors, reset circuit design. If there are many peripherals supported by the processor, then the initialization time of processor will be taken longer.
4.3.2 Software Factors
1. Boot-loaders: Different versions of U-boot have the different CFI drivers, different coding structure and different features support. The difference will affect the code size, flash access speed, and then will affect the boot time.
2. File-systems: There are two type file-systems for NOR flash: Read/Write and Read Only. The different type of file-systems takes different initialization times and built times.
3. Compression algorithms: Embedded systems are usually memory constrained. How to improve and reduced memory usage is more important for embedded system designer. Data compression [18] is the major method to reduce the flash memory usage. There are many compression techniques and which one has best compression ratio and fast decompression speed is what system needed. We will have some short review of following compression method: Gzip, Bzip2, LZMA. Then we have these algorithms test results in Table 1. The experimental environment is on the PC.
z Gzip: Gzip is short for GNU zip, a GNU free software file compression program. It is the most popular compression method of linux. It is not
the best compressor, but it has the faster decompressed speed. Linux kernel, file-system, and most application support this compressor in default.
z Bzip2: Bzip2 compresses most files more effectively than gzip, but it is slower. It is also support by Linux kernel. But it need more memory when decompress the data. For most embedded linux don’t support in default.
z LZMA: LZMA provides high compression ratio and very fast decompression, so it is very suitable for embedded applications. Its compression ratio is higher than bzip2 and much higher than gzip but its decompression speed is only higher than bzip2. Many cost-sensitive embedded systems would use LZMA.
Table.3 Compression Algorithm Test
Compression
Ratio (%) Original
Size (kB) Reduce Size (kB) Decompression
Time (ms)
63.59% 117460 74694 5586 GZIP
(-9) 52.96% 1902 1007 61
70.84% 117460 83210 24854 Bzip2
(--best) 56.33% 1902 1071 354
84.69% 117460 99473 8826 LZMA
(-7) 64.66% 1902 1230 193
4. Kernel version: There are two versions of Linux kernel: 2.4.xx and 2.6.xx.
The image size changed from 2.4 to 2.6 is increased. There are many new features supported in version 2.6.xx.
Chapter 5
EXPERIENMENTS
In this chapter we discuss the experimental environments and how to design the experiments for boot time analysis. Then the experimental results of each boot phase are provided. At the end of this chapter is the analysis of the experimental results.
5.1 Environments
The two platforms are used for the experiments. One is OMAP5912osk and the other one is MT Creator PXA270. Because some factors of the boot time are platform related, the factors of each platform are described below:
5.1.1 Factors of OMAP5912osk
In OMAP5912osk platform, according to the design of chipset and software supporting, the factors could be modified for boot time experiments are:
z Hardware factor
– CPU clock frequency: the range we used is 24, 48, 96, 192 MHz. The maximum frequency is 192 MHz.
– Memory bus clock frequency: the range we used is 24, and 96MHz. Because the chipset limitation, the maximum frequency is 96 MHz. The flash access speed is fixed to 1/8 of memory clock frequency.
– Peripheral and LCD clock frequency: the range we used is 24, and 48MHz.
Because the chipset limitation, the maximum frequency is 48 MHz.
– Cache on/off: the internal I-cache and D-cache of OMAP5912 could be turn on/off by software.
z Software factor
– Boot-loader: U-boot 1.1.1 and U-boot 1.1.3 could be used on OMAP5912osk. Version 1.1.1 only could be used for kernel version 2.4.xx and Version 1.1.3 could be used for kernel version 2.6.xx.
– Kernel: Linux kernel version 2.4.20 and 2.6.15 are used for boot time analysis.
– File-system: The file-systems used for root-fs of Linux are JFFS2, Cramfs and Squashfs. JFFS2 is Read/Write file-system. Cramfs and Squashfs are Read only file-system.
– Compression algorithm: Zlib and LZMA are different compression methods used for Squashfs. But LZMA for Squashfs are only supported in the kernel 2.6.xx.
5.1.2 Factors of PXA270
In PXA270 platform, according to the design of chipset and software supporting, the factors could be modified for boot time experiments are:
z Hardware factor
– CPU clock frequency: the range we used is 52, 104, 156, 208… and 520 MHz. The maximum frequency is 520 MHz.
– System bus clock frequency: the range we used is 52, 104 and 208MHz.
Because the chipset limitation, the maximum frequency is 208 MHz.
– Memory clock frequency: the range we used is 52, and 104MHz. The memory access speed is fixed to 1/1 or 1/2 of system bus clock frequency.
– Peripheral and LCD clock frequency: the range we used is 26, and 104MHz.
Because the chipset limitation, the maximum frequency is 104 MHz.
z Software factor
– Boot-loader: U-boot 1.1.2 and U-boot 1.1.3 could be used on PXA270.
– Kernel: Linux kernel version 2.6.15 is used for boot time analysis.
– File-system: The file-systems used for root-fs of Linux are JFFS2, Cramfs and Squashfs. JFFS2 is Read/Write file-system. Cramfs and Squashfs are Read only file-system.
– Compression algorithm: Zlib and LZMA are different compression methods used for Squashfs. But LZMA for Squashfs are only supported in the kernel 2.6.xx. Zlib, Bzip2 and LZMA could be used for kernel image compressed and de-compressed by U-boot.
5.2 Factors for Boot Phase
According to the Table 4, we know different factors changed could lead to obvious boot time changed. But more important is how these factors change affect the time of each phase.
Table.4 Total boot Time Reduction with different factors modification
OMAP5912 PXA270
RW FS/RO FS 10567/5475 13000/9017
Zlib/LZMA 5475/8015 9017/10141
According to the view of chapter 3 and analysis of chapter 4, the factors for each phase of boot time on both platforms could be assumed below:
z Phase 1: The time for the MPU reset. It is related to the chipset reset time requirement and related hardware reset circuit design on each platform.
z Phase 2: The time for the MPU to reset boot device and peripherals. It is only related to chipset specification. How long reset signal will be asserted by the reset_out pin of MPU.
z Phase 3: The time for U-boot doing simple hardware initialization and environments parameters relocated. It is related to MPU clock frequency, memory clock frequency, internal cache on/off and boot-loader version.
z Phase 4: It is related to the memory clock frequency and internal cache on/off.
z Phase 5: It is related to the MPU clock frequency, memory clock frequency, internal-cache on/off, boot-loader version, kernel version, which file-system is supported and which compression algorithm is used.
z Phase 6: It is related to memory clock frequency and internal cache on/off.
z Phase 7: It is only related to memory clock frequency
z Phase 8: It is related to the MPU clock frequency, memory clock frequency, kernel version, which file-system is supported and which compression algorithm
is used.
z Phase 6’: In PXA270 platform, if the kernel will be decompressed by U-boot, then it is related to MPU clock frequency, memory clock frequency, which file-system is supported and which compression algorithm is used.
z Phase 7’: In PXA270 platform, if the kernel will be decompressed by U-boot, then it is only related to memory clock frequency.
z Phase 8’: In PXA270 platform, if the kernel will be decompressed by U-boot, then it is only related to system bus clock frequency.
z Phase 9: It is related to system bus/memory clock frequency, internal cache on/off and kernel version.
z Phase 10: It is related to the MPU clock frequency, system bus/memory clock frequency, internal-cache on/off, kernel version, which file-system is supported and which compression algorithm is used.
z Phase 11: It is related to the MPU clock frequency, memory clock frequency, internal-cache on/off, kernel version, which file-system is supported and which compression algorithm is used.
z Phase 12: It is related to the MPU clock frequency, memory clock frequency, internal-cache on/off, kernel version, which file-system is supported and which compression algorithm is used.
5.3 Experiments Results
According to the factors in 5.1, there are many experiments done by different factors modifications. According to the experiments, the major factors related to boot time of each platform is as following:
5.3.1 OMAP5912osk
Firstly the experiments are done under the environment of U-boot 1.1.1 and Kernel 2.4.20.
Refer to Table 5 and Figure 12, time period of phase 3, 5, 8, 10, 11, and 12 are become much shorter with higher CPU clock frequency. These phases need more computing power than other phases.
Table.5 MEM: 24 / FS: JFFS2
Factor Time (ms)
CPU Freq. P 3 P 5 P 8
96 297.14 2208.49 1802.29
24 487.03 2976.77 4741.45
CPU Freq. P 10 P 11 P 12
96 696.26 2262.68 461.62
24 1304.75 5602.75 1155.35
Figure 12: CPU Frequency modified on OMAP5912
Refer to Table 6 and Figure 13, time period of phase 3, 4, 5, 6, 7, 8, 9, 10, 11, and 12 are all became much shorter with higher memory clock frequency. Except the phase 1 and 2 are related to board specific hardware, the other phases are related to functions execution. So increasing the memory clock frequency could
Refer to Table 6 and Figure 13, time period of phase 3, 4, 5, 6, 7, 8, 9, 10, 11, and 12 are all became much shorter with higher memory clock frequency. Except the phase 1 and 2 are related to board specific hardware, the other phases are related to functions execution. So increasing the memory clock frequency could