Book Image

Instant Optimizing Embedded Systems Using BusyBox

By : Wu Zhangjin, Cao Ziqiang
Book Image

Instant Optimizing Embedded Systems Using BusyBox

By: Wu Zhangjin, Cao Ziqiang

Overview of this book

As hundreds of millions of people have started using Android smartphones, embedded Linux systems are becoming more and more popular. To get more market share, not only for hardware and function piling up, smartphone manufacturers gradually realized the importance of user experience. To improve user experience, the back-end Linux system must be optimized in many ways. Instant Optimizing Embedded System Using BusyBox is a practical, hands-on guide that provides you with a number of clear, step-by-step exercises to help you take advantage of the real power behind Busybox, and give you a good grounding for using it to optimize your embedded (Android Linux) systems. Moving on from the basics, this book will teach you how to configure and compile it from source code, including cross-compiling it with static linking and dynamic linking. You will also learn how to install and use Busybox on the Android emulator. You will learn to replace the simple Android mksh console with Busybox ash console and start a telnet and HTTP service provided by Busybox. You will also build embedded Linux file system from scratch and start it on Android emulator. We will take a look at how to add functionality to Busybox based system, including adding external applets to Busybox, as well as building development environments (like Bash and C) for it manually or with the automatic Buildroot system. If want to learn how to take advantage of using Busybox applets to optimize your embedded system, then this is the book for you for it will also show you how to use the powerful applets to optimize multiple aspects of an embedded (Android Linux) system.This book will teach you how to build an embedded (Android Linux) system with Busybox, enhance its functionality to meet diverse system requirements, and optimize it to provide a better user experience for embedded products.
Table of Contents (8 chapters)

Reducing the power consumption of an embedded (Android) system (Advanced)

For most embedded systems, particularly for consumer electronics like smartphone systems, in order to extend battery life and reduce charging time per day, power consumption should be controlled.

The power issue becomes more and more critical in smartphone systems because of the conflicts of higher function requirements and performance requirements, but limited battery capacity and a smaller hardware model.

Getting ready

The whole power-cost optimization topic is very systematic; it is related to hardware system design and the power management policies of the software system.

The hardware elements that need to be considered in the power-cost balance are CPU, memory and external devices, and system components, such as clock, power domain, and regulator.

The corresponding software management topics include CPU idle, CPU frequency, CPU hotplug, memory hotplug, memory frequency, bus frequency, runtime power management, clock management, power domain management, and system suspend.

It's not possible to explain all of them, but we'll introduce an applet that can give us power optimization suggestions, and can measure top power-cost events.

How to do it...

PowerTOP ( is designed to measure, explain, and minimize a computer's electrical power consumption; it not only works on x86 systems, but also supports ARM, AMD, and other kinds of architectures.

  1. Enable basic Linux kernel support for PowerTOP:

    To make PowerTOP work, the kernel must be configured with CONFIG_TIMER_STATS=y.

       Kernel hacking  --->
          [*] Collect kernel timers statistics

    Then compile and flush it to the target platform.

  2. Configure PowerTOP in BusyBox:

    BusyBox already has a tiny version of PowerTOP integrated; to use it, make sure it is enabled in the BusyBox configuration.

       Process Utilities  --->
           [*] powertop
  3. Using PowerTOP:

    Let's run it as follows on the Android emulator:

    $ adb shell
    shell@android:/ # powertop
    C-state information is not available
    Wakeups-from-idle in 10 seconds: 308
    Top causes for wakeups:
      38.1% (  115)       <interrupt> : Goldfish Timer Tick
      17.9% (   54)     <kernel core> : hrtimer_start (tick_sched_timer)
      14.9% (   45)        yaffs-bg-1 : add_timer (yaffs_background_waker)
      12.3% (   37)     <kernel core> : hrtimer_start_range_ns (tick_sched_timer)
       4.6% (   14)       <interrupt> : goldfish_pipe
       3.6% (   11) : hrtimer_start_range_ns (hrtimer_wakeup)
       3.3% (   10)     <kernel core> : dev_watchdog (dev_watchdog)
       3.0% (    9)       VSyncThread : hrtimer_start_range_ns 
       0.7% (    2)     <kernel core> : bdi_arm_supers_timer (sync_supers_timer_fn)
       0.3% (    1)       <interrupt> : goldfish_fb
       0.3% (    1)   FinalizerWatchd : hrtimer_start_range_ns (hrtimer_wakeup)
       0.3% (    1)   er.ServerThread : hrtimer_start (devalarm_hrthandler)

    We can see that the Goldfish Timer Tick interrupt wakes up the system that is idle for 115 times in 10 seconds. In a real Android device, it may differ from the mentioned outputs.

    If the events wake up the system that is idle too frequently, the power cost will be increased remarkably. So, the major causes for wakeups should be attended to and their working frequency should be decreased by tuning the respective kernel drivers.

    For example, to reduce the interrupt of Goldfish Timer Tick, the HZ configuration of the Linux kernel should be decreased to reduce the ticks per second; for example, replacing CONFIG_HZ=1000 with CONFIG_HZ=100 may reduce 90 percent system timer interrupts in a second.

How it works...

The ideal working status that is power cost friendly is putting the system into an idle state as far as possible or eventually shutting down all of the devices.

To reduce the power cost of a single device, we should put it into a deeper idle state with less voltage and working frequency (if supported) or power it off eventually if nobody uses it. On the contrary, if some events wake up the device from the idle state to the active state frequently, the device will cost more power; such events are often used as the most important indicators to reduce power cost.

There's more...

We learned about the switching of a system or device state from idle to active and introduced the PowerTOP tool, which can monitor this switching.

In Android, the command dumpsys alarm can track the alarms that wake up the system from a suspend state (a deeper idle state).

But even if we fix all potential wakeup causes, the power cost may still need to be optimized in other aspects. This means even in an idle state, there will be power leaking, which should be fixed up by the GPIO and register settings based on the datasheets of specific chips.

In an active state, power and performance should be balanced carefully with DVFS, clock gating, regulator gating, or power QOS policies.

The system or device should enter into an idle state from an active state timely if there is no activity.

In Android, if there is an activity request, wake_lock is held. The system will not switch from an active state to an idle state until the lock is released. To reduce power cost, the lock-holding time should be as short as possible. To track the holding of such wake locks, the /proc/wakelocks or /sys/kernel/debug/wakeup_sources interface helps, and the dumpsys power command may give more related information.