Implementing Power Management on the Biscayne SH7760 Reference Platform Using the QNX® Neutrino® RTOS

In this paper, you'll find an overview of the sample power management implemented on the Biscayne SH7760 reference platform using the QNX power management architecture. The focus is to illustrate some of the design process and considerations required when creating a power-managed solution for an embedded system. This example is not intended to be a total power management solution for the Biscayne. Instead, its purpose is to demonstrate a tangible implementation of power management on real hardware with real devices. The power policy implemented by this example demonstrates the possible functionality that can be implemented using the QNX power management framework.

QNX Neutrino's power management architecture has been designed to allow developers to build a fully customized power management solution specifically for their target hardware. The architecture makes no assumptions regarding any specific power management standards, but instead allows developers to have full control over the power resources of their system. Figure 1 shows an overview of the architecture, consisting of a server library, client library, and a power callout.

The server library provides the building blocks used to create a custom power manager. The power manager runs as a standard application in user space and manages all power aware devices in the system including device drivers and the CPU. The server library allows developers to create a state machine in their power manager in order to implement a custom power policy for the target system.

The client library provides the mechanisms to allow drivers and other applications to interface to the system's power manager. It is through this client interface that the power manager can control the power mode of individual device drivers. The client library interface can also allow monitoring applications the ability to pass system information (such as ignition status or battery levels) to the power manager. In addition, applications that may be sensitive to power state changes can receive notifications from the power manager (e.g. if a particular device driver is going to be powered down).

Finally, the QNX architecture allows developers to write their own power callout to control the power state of the CPU itself. This custom callout is accessible via a standard kernel function call, allowing the power manager to take advantage of the CPU's specific power modes or voltage/frequency scaling capabilities.

Figure 1 - The QNX power management framework implements a flexible client-server architecture in which the server, or power manager, interacts with client applications and peripherals to determine their power-management capabilities and adjust their power states.

The following sections describe how the example power modes were derived for the Biscayne platform. Based on these power modes, the example power policy was implemented using the QNX power management architecture.

Implementing power management using the QNX architecture requires an overall system power policy to be defined based on the system requirements and the hardware capabilities. The QNX architecture makes no assumptions regarding the power policy or hardware. By examining the power mode capabilities of the CPU, overall power states for the system can be defined. In the case of the Biscayne, the SH7760 power modes were used as a basis for defining the system power states. A similar procedure can be performed on any other platform, such as ARM, MIPS, PowerPC, XScale, or x86. Since the power management is abstracted from the kernel, a custom power callout can be written to implement the CPU power modes for particular hardware. A custom power manager application can then be created using this custom kernel callout to implement the power management policy for the system. This power manager application is also able to interact with other applications and device drivers running on the system.

The QNX power management architecture provides a common interface between the power manager application and device drivers, which allows the system's power policy control over the power consumption of peripheral devices as well as the CPU.

Our sample power policy is based on four general power mode definitions: Active/Run, Idle, Standby, and Shutdown. Because the QNX power management framework is completely customizable, these power mode definitions are used for convenience only. There are no assumptions or dependencies on these definitions. The general CPU power modes can be defined as follows:

Active/Run - The system is actively running applications. Some peripherals or devices may be idle or shutdown.

Idle - System is not running applications. CPU is halted. Code is all or partially resident in memory.

Standby - System is not running applications. CPU is halted. Code is NOT resident in memory.

Shutdown - Minimal or zero power state. CPU, memory, and devices are all powered off.

These definitions are used as a guideline only. Multiple subsets can be defined for each state (i.e. Idle1, Idle2, etc.). Further, not all these CPU power modes may be required or even possible for a specific board or CPU.

CPU power modes have been defined for the Biscayne sample power manager based on the capabilities of the SH7760. The SH7760 provides the following power down modes:

Module Standby - CPU operating, specified modules halted

Sleep - CPU halted, some/all peripherals operating; exit by interrupt or reset

Deep Sleep - CPU halted, some/all peripherals operating, DMA halted; exit by interrupt or reset

Software Standby - CPU halted, clocks halted, peripherals halted, DMA halted; exit by interrupt or reset

Hardware Standby (OFF) - CPU and all devices OFF; exit by power-on

Based on the SH7760 power down modes and the general CPU power mode definitions, the Biscayne power mode mappings for the example power manager are defined:

Defined power modes are implemented by custom software creating a kernel power callout. These power mode mappings for the Biscayne are an example only, and are completely customizable depending on the system's particular requirements. Since a power manager application based on the QNX power management framework implements a policy using the above definitions, the application and its policy are also completely customizable.

Essentially, the main difference between the Idle and Standby power modes is the state of the SDRAM. In the Idle power modes, the SDRAM operates in either a refreshing or self-refreshing mode. Therefore, memory contents are preserved across power modes. In the Standby power modes, the SDRAM refresh is disabled so that the SDRAM can be powered down completely. The advantage of the Standby modes over a Shutdown mode is that the system can be woken up from a Standby power mode by an interrupt, while the Shutdown mode cannot. Depending on the application, the Standby power modes may not be required for a system.

Besides controlling the power consumption of the CPU itself, a number of device drivers have power management functionality built in using the QNX power management client library. To illustrate implementation of power managed devices, the serial driver for the Biscayne SCIF UARTs and the Ethernet driver for the SMC9000 network driver have power capability built in. Both of these devices currently support Active and OFF power modes. The power manager or (other applications) can interface to these device drivers to control their power state.

In addition to power-managed peripheral devices, the QNX reference design makes use of the Biscayne H8 real-time clock (RTC). The RTC's interrupt line is connected to a GPIO pin on the Biscayne board. The H8 RTC is used by the power manager example to demonstrate a timed wakeup out of CPU sleep modes.

Based on the QNX framework, we've written a power manager application for the Biscayne platform. This application makes use of the previously defined Biscayne power mode definitions and the power management enabled serial and Ethernet drivers. The power manager application is not meant to be the end solution for the SH7760 or the Biscayne board. Instead, it is meant to illustrate how all of the components of the framework operate together to implement a custom power policy.

Figure 3 provides an overview of the sample Biscayne power manager and its interactions with other system components. The power manager interacts with the Ethernet and serial drivers to set their desired power modes, as well as the power callout to set the system's power level. A client application provides simulated low-battery power events, while the debug serial console provides user input and output to the power manager.

Figure 3 - Overview of Biscayne Example Power Manager

Figure 4 shows an overview of the sample power manager state machine and power policy implemented on the Biscayne. This example depicts how the power manager application interacts with the CPU and peripherals, and shows a stepped reduction in power-level of the system over time (by use of the RTC).

The Biscayne system always starts in its full power usage, Active 1 state. In this state, the system is running applications and all peripheral devices are active. This is the normal running state of the system. A power monitoring client application may send an event to the power manager indicating low battery power. This event will cause the power manager to begin conserving power on the system. The power manager state machine enters into the Active 2 state by powering down the Ethernet and serial port 2 peripherals. The debug console on serial port 1 is left active for continued use during the demo. If the power monitoring application sends a second low battery power event to the power manager, the system begins to conserve even more power by transferring into the Idle 1 state. In this power mode, the CPU is halted and is not executing any programs.

When the SH7760 CPU is in power down sleep mode, either an interrupt or a system reset will cause the power mode to be exited. In the case of the Biscayne demo, the sample power policy makes use of two wakeup devices - the debug console serial port and the RTC. Because it is possible that other devices may cause an unwanted wakeup from a power down mode, other devices such as the other serial ports or the Ethernet port must be powered down before entering into a CPU power down mode. In a real-world power management application such as an automotive telematics system, wakeup interrupts could be generated from devices such as the ignition system or the remote keyless entry system.

Before entering a power down mode, the power manager programs the H8 RTC on the Biscayne board to generate an alarm interrupt at a specified time in the future. The RTC acts as the default wakeup device if another wakeup event does not occur within the specified amount of time. In the Idle 1 case, there are three possible wakeup events - debug serial port 1 interrupt, RTC interrupt, or system reset. The power manager must be able to distinguish between the wakeup events, and make a decision based on this event. If the system is woken up by a serial interrupt on the debug console, the power manager determines that a user is attempting to access the system, and places the system back to the fully running Active 1 state. If an RTC interrupt occurs instead, the power manager decides that the system has not been in use, and can be placed into an even lower power state Idle 2. If a reset occurs, the system always assumes it is to be started up in the fully running Active 1 state.

In the Biscayne power manager example, the wakeup policy decisions for each of the power states are the same as they are for Idle 1. A serial interrupt on the debug port or a reset will cause the system to return to a fully running Active 1 state, while an RTC interrupt will cause the system to enter into a lower power state. If an RTC interrupt wakes the system out of the Standby 2 power state, the power manager decides the system must be fully powered down to conserve the remainder of the battery power. Once the Shutdown state is reached, the system can only be returned to an Active 1 state by a power-on. Although the Idle 3 and Standby 3 power modes have been implemented in the power callout, this particular example does not make use of these modes.

Figure 4 - Sample Biscayne Power Manager Policy State Machine

In the Idle 1 power state (SH7760 sleep mode), the SDRAM is left in its normal refreshing state. As such, the contents of memory are preserved during this power down mode. When a wakeup interrupt occurs during Idle 2 mode, the system is configured to execute a small amount of software out of flash memory to place the SDRAM back into its normal refreshing state before the system can continue its normal operation.

In the case of the Idle 2 power state (SH7760 deep sleep mode), the SDRAM must be placed into a self-refreshing state in which the contents of the memory are held, but cannot be accessed. When a wakeup interrupt occurs during Idle 2 mode, the system must perform extra work to place the SDRAM back into its normal refreshing state before continuing operation.

In the case of the Standby power modes, the SDRAM refresh is actually turned off. This means that the entire contents of memory including the operating system, device drivers, and applications are lost. Extra work is required to wake the system up from the Standby power modes. The kernel must be completely reinitialized once a wakeup interrupt occurs. Obviously, it will take longer to wake the system up from a Standby mode than an Idle mode. However, in many power management applications, the Standby power modes may not be required. This functionality has been built into the example to show how this operation can be implemented using the power management framework for systems that may have ultra-low power consumption requirements.

When implementing power management on a hardware platform, slight modifications to the system boot process may be necessary in order to create an integrated power managed system. Figure 5 shows the normal boot sequence for a QNX Neutrino-based system. After a power-on or reset, the Initial Program Loader (IPL) runs and prepares the system image. Once the image is loaded into memory, control is transferred to the system startup that initializes basic hardware functionality and prepares the system for the QNX kernel. Once initialized, the kernel and device drivers are started.

Figure 6 shows the modifications to the QNX boot procedure required to support power management. The general system initialization is the same as under a normal boot. The main difference is that device drivers are not automatically started once the kernel is initialized. Instead, the power manager application is started. Depending on its current state within the policy state machine, the power manager determines which drivers (if any) are to be started. Based on the power policy, the power manager will then interact with devices to control their power consumption.

Once the power manager determines that it is necessary to enter a system wide power mode, it will configure the wakeup devices (RTC, serial, etc..), and make a call to the power callout. The custom power callout code is responsible for configuring the system hardware and CPU for the various power modes (Idle 1, Idle 2, Standby 1, etc..). Once the system has been powered down, there are a few different paths to return the system to a running state. In the case of an Idle power mode where the SDRAM is left in a refreshing state, a wakeup interrupt will simply bring the system out of the sleep mode and the CPU will continue executing software. The power callout will exit and the power manager will continue from where it last left off. In the case of a Standby power mode, the contents of the SDRAM (including the OS, applications, drivers, etc..) are lost. The system must be re-initialized in order to wake the system up from these power modes. For simplicity, the Biscayne power management example re-enters the IPL and performs a full initialization, similar to a system reset. After waking up from a Standby mode, the power manager must be able to determine its previous state, and re-initialize the policy state machine based on this information in order to continue from where it last left off.

Since the full boot time of QNX Neutrino on the Biscayne is fast, it may be acceptable for many applications to perform a full initialization when waking up from a Standby power mode. Alternatively, a fast initialization process could be implemented to take advantage of the fact that the system has already been initialized. Since the contents of many of the SH7760 registers are held during power modes, portions of the initialization that configure these registers during system boot could be bypassed. Further, application or driver information could be saved to a persistent storage mechanism, reducing the amount of initialization required on system boot. However, careful considerations must be made when examining this approach. For instance, the time required storing and retrieving this information from media such as FLASH memory or a hard disk may be greater than the time to simply re-initialize the system. This type of functionality is extremely application dependent and has been left as a project specific customization.

Figure 5 - Normal QNX Neutrino Boot on Biscayne

Figure 6 - Power Managed QNX Neutrino Boot on Biscayne

In this paper, we've examined the application of the QNX power management framework to an actual embedded platform. Specifically, an example power policy was implemented on the Biscayne reference platform based on the capabilities of the SH7760 CPU and peripheral devices. This example demonstrates how the various components of the framework work together to allow a developer to create a custom power management solution based on the hardware's capabilities and the end-product's requirements. It is important to note that many of the details presented in this article (such as power policy, system power modes, booting procedure, etc..) are customizable and are highly dependent on the actual hardware itself and may be different on other platforms. The source code for this working example is available for the Biscayne Board Support Package (BSP) to give developers a starting point for this or any other embedded platform.

More information about the QNX power management architecture can be found in the QNX whitepaper "Application-Driven Power Management."