XO-1/Software specification

  This page is monitored by the OLPC team.

Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to XO-1/Software specification/translations

HowTo [ID# 36414]  +/-

Power Management

Introduction and Related Material

Careful stewardship of battery power is critical.

This page is a work in process, collecting information related to power management on OLPC.

• Hardware Power Domains
• Power Management Software
• XO Power Management Tips and Tricks
• Misc. Papers on Energy Efficiency in Computing and Networking

In addition to effectively managing the power that is in the battery. The Battery and power page discusses many alternate power sources that could be used to supplement the existing charger.

Linux's Approach to Power Control

Linux is highly cross platform, running on just about all significant architectures, including many that are used for battery powered embedded systems. The infrastructure for power management has therefore become quite sophisticated over the last years, though it is still maturing. This means that the facilities are general, and not tied to any particular architecture. The generation one OLPC system, being from the x86 part of the world, is therefore similar and fundamentally different from other x86 based systems, for reasons that will become clear in the discussion below.

Linux is not dependent on ACPI or the older APM power management systems, which are x86 specific. As such, Linux's design has always done its power control in the operating system, and ACPI and the like are considered "platform dependent".

OLPC's Innovations

The DCON chip lets us take over refresh of our very low power flat panel and therefore completely power off the processor board. Given our flat panel is usable in gray scale mode at .1 watt, you can see that the leakage currents and power supply power consumption of the system board can dominate power consumption easily.

We are also able to leave the Marvell wireless module to operate independently, forwarding packets in the mesh while possibly everything else is powered down.

Use of OpenFirmware

Rather than using a conventional BIOS and boot loader, as of the "C" series of our firmware we are using Open Firmware. We no longer use LinuxBIOS for the setup of our systems. This is a result of having implemented fast past resume from RAM; once you have implemented this, setup of the system initially is essentially identical.

We have also removed VSA support (the Geode Virtual Systems Support) from our firmware

Fast Resume

Resume on our system is extremely fast: even without any serious attempt to optimize resume, we can resume from RAM in 160 milliseconds (mid-April). We believe the hardware limitations for resume are about 63 milliseconds on the B2 and before systems; B3 and later are probably similar. We will do work in the future to further speed resume. Note that for most uses, 100ms is considered at the edge of human perception (e.g. typing).

BIOS

General

Power Management States

End user visible operating states

The following are the major operating states of the system. For simplicity's sake, see Wikipedia's ACPI article.

Powered Down

In this state, (in ACPI terminology, G3 is this state). Everything is off and the battery can be swapped. The operating system will have to be booted to start operation; the RAM is not preserved. On our hardware, if power is available, the EC will be powered up and potentially charging the battery.

Suspended, with Mesh Active, No screen

A common mode of use will be the system not being used, but still active forwarding in the mesh network on behalf of others in the mesh, but otherwise unused. This differs from our powered down state by the fact the Marvell wireless will be powered up, and active. In ACPI terminology, the closest match is G1/S3. The processor is suspended to RAM (in self-refresh).

System Managemetn BIOS Interface

Not Supported