Boot Speed

Often users are very interested in improving boot speed of an embedded Linux board. Its important to realize that the Gateworks Board Support Packages are designed to be 'developer friendly' and do not focus on time to boot.

Boot Speed criteria

There are different criteria that fall into the 'boot speed' category from the point of time where a board has power applied:

• time until an LED lights
• time for splash screen to appear
• time for a shell prompt
• time for the board to respond to network activity
• time for GUI to be available
• time for some specific application to be available

Depending on what criteria above you are most interested in, your approach will differ.

Factors which contribute to boot speed

There are several key factors that contribute to boot speed:

• cpu performance
• storage device read performance
• bootloader configuration
• Linux kernel static size (the larger the kernel, the more time it can take to load from the storage device)
• Linux modules (using Linux modules reduces the size of the kernel, but increases the time needed for the devices serviced by those modules to be available. Sometimes this is a good trade-off if want the functionality of a driver but don't need it available immediately)
• Userspace init - you may want to configure what services are started and in what order
• boot architecture - using a full-fledged u-boot is likely not needed for end users, you may want to invest time in bypassing it and booting the kernel in a more direct fashion

Methods to Reduce boot time

Once you understand what your desired goals are you can examine reducing time to boot using several techniques to address the factors that contribute to boot speed above. Each one of these techniques has a level of difficulty and a cost (in implementation time and experience needed) vs a payoff (of boot time saved). The following items are presented in order of the least amount of work for the biggest savings in boot time.

CPU performance

In most cases upgrading to a faster CPU will reduce your boot time, however usually updating to multiple cores does not.

In practice, the boot time of a Ventana has very little effect from moving from an IMX6DL (dual-core 800Mhz) to an IMX6Q (quad-core 1GHz) when booting to Android (accounted for less than 1 second decrease in boot time) but did shave off a few seconds when evaluating OpenWrt.

Storage Device Performance (no code changes)

Storage device performance is a function of the storage device itself, the bus speed it operates over, and the driver/controller that the CPU uses to manage it.

You can determine raw 'device' I/O transfer rates by using 'dd' on the raw device (not disk partition or filesystem as this would take into account filesystem overhead and utilize caching):

# evaluate read/write speed for /dev/sda device
time dd if=/dev/sda of=/dev/null bs=1M count=50 # read 50MB
time dd if=/dev/zero of=/dev/sda bs=1M count=50 # write 50MB

• devide 50MB by the amount of seconds that time reports for MB/s
• be sure to do this test on a non-mounted device
• you can extrapolate this method to a filesystem test as well if you take care to disable or flash disk cache so it doesn't affect your result

The following table show some performance values for typical devices when used on the Ventana platform:

bus	max bus speed (MB/s)	device	device max read/write specs (MB/s)	read (MB/s)	write (MB/s)1	boot to OpenWrt 2	boot to Android 3
sdhci (uSD)4,5	HS/25.0	Sandisk class4 HC	20.0 / 4.0	17.25	4.72	25	42
	HS/25.0	Generic class10 HC	20.0 / 10.0	16.54	8.53	24	45
	HS/25.0	Samsung PRO UHS-I HS	90.0 / 50.0	19.23	17.79	22	30
	UHS-I SDR104/104.0	Samsung PRO UHS-I SDR1048	90.0 / 50.0	58.14	28.24	20	25
ahci (SATA)	SATA3/600.0	Crucial M4 mSATA	440.0 / 50.0	81.97	39.68	22	23
ehci (USB2)6	USB2/60.0	058f:6387 Alcor Micro		16.03	3.24	35	1387
	USB2/60.0	048d:1327 Integrated Tech		23.36	11.76	37	38
gpmi (NAND)		256MB		9.09	6.50	25

1. Ventana uSD (4-bit SDIO) max transfer speed is about ~19MB/sec - even if your card speeds exceed this rate, you won't achieve anything higher here through 4-bit SDIO
2. Time to OpenWrt login prompt (ENET available about 5 secs later)
3. Time to Android Launcher (Android animated splash shows up in about half of this time)
4. 'write' speed only affects first boot time and installing new apps
5. SD card speed 'class' defines the 'write' speed, not the read speed. Be careful to use cards that have a specified read speed and verify that they do in fact meet the manufacturers spec.
6. booting from USB adds several seconds while the bootloader waits for the UMS device to be ready. Some USB memory sticks don't conform to the USB spec as well and require an even longer time than the 1s maximum (requiring the setting of usb_pgood_delay in the bootloader to 2000ms or more)
7. Obviously not all USB Mass Storage devices are created equal - this is a very low cost and its suspected it doesn't not consistently perform and well as it did during raw read/write tests
8. UHS-I data rates up to 104MB/sec are supported on certain Ventana boards (see mmc for more info)

The above values are all with a completely 'un-tuned' bootloader and OS (see below) for ways to easily shave off 5 to 10 seconds off the above values

Bootloader environment tuning (no code changes)

Because the goal of the Gateworks BSP's are for ease of development you will find several tunable parameters that will save several seconds off your boot time:

• bootdelay - a value of 3 causes the bootloader to wait for 3 seconds for a user to break out into the bootloader shell. If you don't need this, set this to 0 and shave 3 seconds off your boot time:

  setenv bootdelay 0
  saveenv
  

• bootdevs - The Ventana bootloader will check for boot devices in the following order: usb, mmc, msata, flash (from most removable to least removable). Waiting for a USB device to be ready and scanning its partition table takes several seconds that can be saved if you have no desire to boot from USB. Similarly scanning a uSD card can take a second or 2 depending on the device. If you are booting to flash, you can save several seconds by setting bootdevs to flash:

  setenv bootdevs flash
  saveenv
  

• console - unsetting this will cause the Linux serial console to not be used which believe it or not can save several seconds (by default lots of debug information is sent out the serial port by the kernel):

  setenv console
  saveenv
  

The above items, used together for booting to FLASH can save about 9 seconds of a typical boot.

Linux kernel size and use of modules (kernel configuration tuning)

Keeping the Linux kernel size small affects both the amount of data (kernel size) that must be loaded from the boot media by the bootloader (which can take 1 or more seconds on slower media) as well affects the amount of time needed for the kernel to statically initialize various devices and drivers.

Removing support in the kernel for drivers and features that you know you do not need can sometimes save several seconds. Recall that the goal of the Gateworks BSP is to be 'developer friendly' so we typically include a lot of functionality in an attempt to cover a wide variety of use cases.

Additionally, if you require some functionality but do not need it to be available immediately you can build it as a module and have it loaded after whatever is critical to your application is available. For example, if your goal is to minimize time from power-up to serving web pages from your device then all your networking support is critical as well as your web server application, but you can load modules to support USB input devices later perhaps.

There is no magic answer to how you should configure your kernel as it depends completely on your needs and relates to storage media. If you are using a slow processor you may end up saving time using a larger uncompressed kernel if the time to uncompress exceeds the time need to load a larger kernel from your storage device. Today, this is rarely the case and the desire is typically to reduce storage size or increase storage read rates.

OS Level tuning

Typically the init system can be modified to change the order various devices and services are enabled, or remove non-essential items completely.

For OpenWrt, removing non-essential services (make menuconfig) will greatly reduce your overall init time.

Android also has an init process but it can take a bit more experience to tune this.

Linux Initial Ramdisk

A popular trick to speed up boot times is to use a Linux initial ramdisk. This is a filesystem with just enough support to meet your boot criteria and move other features that can be deferred to a later stage. That later stage can re-mount a read/write root filesystem if needed.

When using an initial ramdisk it can be loaded with (or even appended to) the kernel itself, so the overall size of what is being initially loaded increases along with the overall complexity but it may get you to your boot criteria quicker depending on your needs.

Bootloader tuning

Similar to kernel configuration tuning, there may be features of the bootloader that you do not care about that increase boot time. Obvious tricks involve removing the bootdelay or tuning the bootscripts but there often are features that can disabled at build time as well. For example, if you are booting from micro-SD and don't need NAND support, you can remove it and bypass NAND initialization and detection.

Be sure to understand how the bootscripts work and tune them as needed. U-Boot executes the 'bootcmd' bootscript to load the OS. On Ventana boards the default bootscript scans USB Mass storage devices first for a bootable OS, then micro-SD, then mSATA, and last NAND flash. If you boot only to NAND flash disable the other devices to save several seconds of un-necessary device initialization and enumeration.

Quite often also the 'bootdelay' variable is set to 3 or more which adds 3 or more seconds to the boot to allow someone to break into the bootloader. Setting this to 0 will completely disable the ability to break out and save this time - of course you don't want to do this during development when you may need the bootloader.

Bypassing the main bootloader (U-Boot Falcon mode)

There are typically several levels of boot loaders in modern systems.

For example, the IMX6 processor used on Ventana starts with a Primary Boot Loader (PBL) (this is firmware inside the IMX6 which can not be modified), a Secondary Program Loader (SPL) which configures DRAM and loads the main bootloader, then the OS kernel itself.

While the SPL is typically always needed (technically you can skip this if you have what is referred to as a 'bare metal' application that does not need an OS), you may not need the features that the main uboot offers.

The Ventana SPL supports Falcon mode. For information on what is supported and how to use it see: ventana/bootloader/falcon-mode

Boot Speed Perception

Illuminating LEDs

How fast your device responds to a power on event, is a user perception. Often its desired to give the user some immediate feedback to pressing a power button or flipping a switch. This may be indicated by the 3.3V LED present on most Gateworks products or you may be looking to enable a software-controllable LED within a power switch. You may want to add some code or a script to the bootloader to accomplish this.

Video Display Splash-screen

For devices that have a display, often you want to throw up a splash-screen as soon as possible. This can be done in the bootloader, although the existing support for video display is very rudimentary there. By default the Ventana bootloader will throw up a Linux 'tux' logo if the display device is supported and detected by the bootloader. Adding support for additional display devices, disabling the display in the bootloader, or changing the graphic displayed requires some code changes in the bootloader.

Additionally, the Linux kernel has static splash-screen support. This is also very rudamentary and kernel code changes can be made to specify the graphic that is displayed.

Typically a static splash is displayed in the bootloader, possibly replaced or left in place by the kernel, then a dynamic animated splash is enabled in early userspace init, which is finally replaced by the final GUI once init is complete.