With the rising need of automation and advent of faster and smaller processing technologies, embedded systems are being universally used across the industries. Because of their specialized application, embedded systems need to be designed with careful considerations. In a series of posts, we will discuss about the various techniques that goes in to the embedded system design starting with its general architecture.

What is an embedded system?

An embedded system is a computer system designated to perform a dedicated function. They are generally a part of a bigger system or sometimes they themselves form the entire system. There are many categories of embedded systems depending on their functionality, reliability etc.

Embedded systems constantly evolve with advances in technology and dramatic decreases in the cost of implementing various hardware and software components. Some embedded devices requires higher quality and reliability than other types of computer systems, for example a critical medical device malfunctioning at the time of surgery will result in a very serious problem but there are also embedded devices such as TV’s, games, and cell phones in which a malfunction is an inconvenience but not usually a life threatening situation.

Some examples of embedded system includes Ignition system, Engine control in Automotive, Set top boxes, PDA’s, Microwave Ovens in Consumer Electronics, Robotics, Assembly Control System in Industrial, Gateways, Mobiles etc in networking.

Components of an embedded system

Essentially an embedded system is a miniaturized computer. The following block diagram depicts a typical embedded system.


Embedded System Components

Modules in an embedded system

As with any computing device, it has the following components:


Processor is the brain controls the entire system. It holds the logic circuitry that responds to and processes the basic instructions that drives the system. It manipulates the control and data path to achieve the expected functionality. There are many application-specific and general-purpose microprocessors available. We will discuss in detail about the microprocessors in next post.


Memories are the components that support the processor to hold data temporarily or permanently for immediate use and or later use. Memories are of two types: non-volatile – capable of withholding data after power cycle and volatile – not capable for persistent data storage. Memories come in various technologies and sizes that can be chosen based on the specific needs of the system.

Inputs/Outputs – IOs:

An embedded system responds to events from the external world and results in certain action be taken. This is accomplished with the IOs – inputs and outputs. While a real external world event is in form of a continuous analog signal (temperature reading of a furnace) or a discrete digital signal (on/off state of a switch), the input presented to the embedded system is generally digitized. This digitization is achieved using ADC’s for the analog signal or comparator circuits for a digital signal or it might be presented digitally using channels like an external message to the system. Similarly the outputs in the digital form are converted to suit the real world using many available techniques to be discussed later.

User Interface:

While the IO’s typically refers to interaction between the embedded system and the controlled system, the user interface represents the interaction between the user and system. Various technologies are available to implement the User interface including LCD’s, touch panels, key pads, buttons etc. An intuitive design enables easier and enhanced control of the system and this is becoming more of a mandatory requirement rather than an option.

Power Supply:

Another most important consideration of the design is the power supply. The system may be powered directly from the power line or using a battery depending up on the nature of the use. Its design requires deep analysis and careful incorporation according to the system requirement. Improper designing of power supply may not only affect the system performance but may end up damaging the system also. Further nowadays with emphasis on a greener world, it is more important to design a power-efficient system.


The mechanicals include cabinet and connectors. Cabinet protects the system from various external factors and provides ambience to the internals. The connectors support the connection of the external signals into the system. Various factors determine the selection of the cabinet and connectors which are discussed in detail in the upcoming post.

Embedded systems Design

As with any design, the design of an embedded system is determined by various requirements including functional requirements, processing Capabilities, Power supply requirements, Environmental considerations and reliability requirements.

There are various models being practiced for embedded system design. Some of them are

  1. Big-Bang model: Essentially no planning or procedures in place before and during the development of a system.
  2. Code and Fix model: Product requirements are defined but no formal processes are in place before the start of the development.
  3. Waterfall model: Process for developing a system in steps, where the result in one step flows into the next step.
  4. Spiral model: Process for developing a system in steps, and throughout the various steps, feedback is obtained and incorporated back into the process.

Since choosing any of these models in highly implementation and implementer specific, we will not dwell in to these topics. Rather we will discuss about various considerations to be factored in selecting each and every component of the embedded system, starting with the processor in the next post.

With our understanding of Android Boot process and profiling of Android Boot Time Analysis, we will now start the actual process of Android boot time optimization.

There is no single solution to improve the boot time applicable to all platforms. The boot process is dependent on each peripheral involved right from DRAM speed, storage device performance, processor speed and also on the customer requirements and kind of application area being used etc. Termed as “Tooth paste effect” by Tim Bird, shortening a process somewhere here will end up lengthening something else over there.

Another important point to remember is that the configuration used for improving must be same as the finally deployment. For example, working on SD Card file system (For ease of programming) to improve the boot time and then finally deploying the result in a NAND file system, will lead nowhere as the data rates of NAND and SD Card will differ.

The following sections describe various techniques module by module for Android boot time optimization.


The boot loader performs a critical initialization that will affect the whole process – DRAM initialization. As the DRAM is going to host the text region and data section, an improper initialization will result in significant performance degradation.

Further the Boot loader copies uboot or Linux kernel image from a non-volatile storage medium such as NAND or SD Card. So the same has to be configured to run in the maximum possible frequency. DMA operations can be used to improve the data transfer through put.

Obviously the processor needs to be run in the highest possible frequency and with I-cache and D-cache enabled.

Unnecessary initializations like initializing display can be removed from the code. But in some applications, it will be required to display images immediately on boot up. For example, it may be required to show a company logo or to show battery status. In this case, it will not be possible to remove the display configuration.

Also the number of boot loader levels should be reduced if possible. This is possible depending on the processor implementation.


Using an uncompressed kernel “bImage” rather than a compressed “zImage” will avoid the delay to uncompress it run time. But this will increase the size of kernel image to be copied, there by significantly dependent of on the target system processor and data transfer speeds.

All the unnecessary driver modules should to be removed. A minimal set of device drivers can be built initially and other necessary drivers can be configured as modules and loaded later. A details study has to be made on the device initialization time, time required to copy the increased kernel image (in case of statically linked driver) or load time of a module over the file system.

File systems

Generally a non-removable media is used as the root file system. Sometimes a ramdisk image can be used as a root file system with certain functionalities there by reducing time to start the init scripts. This can be achieved by using uImage. Once again this will increase  the time required to copy it at the boot loader stage.

Also an optimized file system format can be used for the root file system for faster access. It is preferred to have ubifs for NAND and ext4 for SD Cards.


The below sections describes the techniques to improve the functionality inside the Android subsystem.


For a faster processing, avoid starting unnecessary services and daemons. Also since JellyBean, there are lot of changes in file permissions. So the logcat output can be used to analyse any discrepancies in permissions and corrected.

Android preload classes and resources

In ZygoteInit, Andorid loads all the classes and resources that it will need for further execution. The boot time can be reduced significantly by reducing the number of classes and resources to be preload or even avoiding them all.

This is the easiest process and most visible step in the optimization process. The preloading can be disable by just making the variable “PRELOAD_RESOURCES” false (only to disable preloading resources) or commenting the function “preload()” on “frameworks/base/core/java/com/android/internal/os/ZygoteInit.java” (to disable both resources and classes).

But disabling preloading will directly increase in launch time of individual application after boot up. As a compromise, the number of classes to be preloaded can be manually configured in the frameworks/base/preloaded-classes file.

Android System service

By default, the SystemServer starts all android system services. But some of them may not be applicable for the current system. For example, a device may not have a Bluetooth module, thereby has no need for the BlueTooth manager service. Thus a necessity analysis of services and disabling unnecessary ones, will reduce the start time.

Scanning Application Packages

The package manager, up on start up, scans all the available packages in the app directories. Hence the service can be expedited be removing unnecessary applications from the system. It is also possible to delay scanning of packages by custom changes in the package manager implementation and using a customized home application.

Precreate directories

In some systems, certain directives are created in the on-init process. If it is possible, these activities can be done offline once during file system creating there by significantly reducing the time to boot.


For a faster boot it is better to avoid or use a shorter boot animation. The bootanimation.zip can be tactically placed on the best file system for optimum performance.

Other Techniques

Some other techniques that can be used to speed up boot are:

Storage Device Speed/Processor Execution Speed Tune up

Based on bootchart, the resource requirements of major services can be analyzed and be spread across time to avoid overloading of processor as well as the disk usage.

Disabling All Debug Options

All the debug information like kernel level debugs, debug services like logcat, strace, bootchart etc can be removed on final release. The loglevel in android init.rc can also be reduced.

Proper shutdown

If the system is shutdown improperly (in a non-battery backed up device), the file systems will not be un-mounted properly. So when the system is booted next time, it takes some time to recover the file system errors. So it is necessary to make sure that the system is shutdown properly.


With the above mentioned techniques, it is possible to reduce the boot time of the android system. Once again it is iterated that the effectiveness of each technique is highly dependent on the system. But with some time and a lot of patience, it is possible to achieve significant difference and make the Android boot faster.

Various technological advances are being made in this area. Once of them is being captured in this Linaro page. For any queries or requirements on Android Porting and/or Android Boot Time Optimization, feel free to contact us.

On the previous post “Android Boot Process”, various steps involved in booting up the Android is explained. Before we start optimizing the Android boot process, each step has to profiled and analyzed to identify the critical delays. There are various tools and techniques available to understand the resource usage (both time and processing), which will be discussed in the below sections.

As the “Observer effect” notes that the measurements of certain systems cannot be made without affecting the system, using some of these tools will affect the actual performance. For example, using “bootchart” tool increases the system load marginally as it has to write to file system for storing the sampled data. But since we are not dealing with quantum mechanics, we can safely use them for improving the process and then disabling them in the release. Now about the tools.

Kernel Prints with Time stamps

The basic and primary technique is to enable the debug capabilities in the kernel. This option, up on enabled, will output debug prints along with the time stamp information. It can be enabled in the kernel by “make menuconfig” configuration using the following options

Kernel hacking

  • –>Kernel debugging
  • –> stacktrace
  • –> Enable dynamic printk() support
  • –> Kernel low-level debugging functions
  • –> Early printk

During run time, the prints are output in the console.

Logcat with higher log level

Android provides a service started by the “init” process to log various debug information.  The service can be enabled in init.rc file as follows

service logcat /system/bin/logcat -r 1000 -n 10 -v time -f /data/local/logcat.log

It provides options to print the debug options on process and even thread level along with the time stamp. The logcat can also be started from console command line without needing it to be run as a service and the output directly printed on the console.

The verbosity of the log can be increased by configuring a higher number with 8 as the upper limit. So changing the default log level 3 to log level 8 in init.rc file will help us understand some of the internal processes and execution time of the same.

A detailed description of this tool is available in Android Developer page.


Another valuable tool in documenting performance of each process is the “strace” tool. It helps us to trace the system calls executed by the associated process. To enable strace, in the /init.rc file, rather than starting a process directly, “strace” has to be started with the process as the arguments.

For example to document the zygote process, instead of the usual command,

service zygote /system/bin/app_process -Xzygote /system/bin –zygote –start-system-server

following can be used:

service zygote /system/xbin/strace -tt -o/data/boot.strace /system/bin/app_process -Xzygote /system/bin –zygote –start system-server

strace generally outputs a lot of information and can be used in advanced debugging.


Bootchart is tool to generate a graphical representation of android boot sequence. The greatest advantage of this tool is that the processor usage and disk usage are logged together and hence give a fairly good understanding of the cause of execution delays. This is internally supported in the Android and  is enabled during compilation, by exporting a environment variable as follows,

‘export INIT_BOOTCHART=true’

Followed by usual Android compilation process.

To instantiate boot chart process, create a file in /data directory with the number of seconds to log the boot information, typically by

‘echo 60 > /data/bootchart-start’

The up on booting the Android, the bootchart logs all the necessary information in the /data/data/bootchart/ directory.

The contents can be transferred to the host PC and by using a “python” based tool called “bootcharting”, the graphical representation can be created. To generate bootchart image by ‘system/core/init/grab-bootchart.sh’

The following is a typical output of a boot chart.

Bootchart - Capturing Android Boot process

As we can see, start time of each process along with their disk usage and execution pattern can be inferred.

Other tools:

There are other tools available for profiling the android processes. Some of them are



OProfile For Statistical profiling of entire system’s running code
Perf Performance Counters for Linux
Dalvik Method Tracer Profiling application performance graphically
Stop watch Measure boot up time manually

Since Android boot time optimization needs a lot of iterations, it is better to create an ecosystem to easily capture and process these profiling information using scripts and other techniques.

Now armed with detailed profiling information, we will look in to various Optimization techniques in our next post.