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# 37135]  +/-

XO-1 Software Specification

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.

Firmware (aka BIOS on conventional PC's)

Open Firmware

Rather than using a conventional BIOS and boot loader, as of the "C" series of our firmware we are solely 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 almost identical.

We have also removed VSA and VESA support (the Geode Virtual Systems Support) from our firmware. Since our PCI bus is fixed, we have no need for PCI configuration registers. Similarly, using the fbdev driver on Linux, we have no need for VESA emulation; while the PCI bus emulation was free software (AMD had generously made it available), the VESA emulation was the one part of VSA that they did not own, and so we did not have source for it. We did not want an unmaintainable binary blob in our firmware that we did not need anyway, and saves space in the flash for other purposes.

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 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).

System Identification

The Manufacturing Data page documents the Model ID string, part number, localization information, factory, BIOS version, and many other pieces of data.

Quiet Boot

Boot is not "quiet" at this time. Linux has facilities to make a splash screen at boot overlay the boot messages, but OLPC has not implemented this as yet. Bug #1394 tracks this issue for eventual resolution.

POST Message

The system gives an progression of iconic images across the top of the screen to indicate progress of the boot process.

Prior to Q2C10, if any key is pressed during the initial countdown after the initial message, the boot sequence is stopped and OFW's command interpreter invoked. After firmware version Q2C10, if a game key is pressed after power on, the automatic boot sequence is stopped.

OFW gives a cheery "ok" message to indicate it is ready for a command.

The initial line of text on the screen provides the version, amount of memory and serial number of the machine. The second line provides the the OpenFirmware version, the version of the firmware aggregate (OpenFirmware, embedded controller, etc.)

It then reports a number of progress messages.

Here is a sample:

OLPC B2, 128MB memory installed, S/N SHF70400BD
OpenFirmware CL1   Q2C06  Q2C

Interactive boot
Keyboard probe
USB probe
USB2 devices:
/pci/usb@f,5/wlan@3,0
USB1 devices
Type any key to interrupt automatic startup
type 'help' for more information

ok

Open Firmware Command Prompt

The OFW FAQ answers some of the most common questions of how to interact with the OLPC OFW firmware.

Status Indicators

The XO-1 has a number of status indicators; some of which are on both sides of the main unit.

The picture to the right

of a BTest-2 system has most of these, though some

will be used in a different fashion than the current use. The final production XO-1 systems will lack the keyboard lights in the picture and add indicator lights for the microphone and camera. A labeled picture of a BTest-3 system will be added as soon as possible (sometime in the last two weeks of May).

Wireless Lights

There are two wireless lights. One light looks roughly like an exclamation point, and the other like (*). These are used to indicate connectivity

• The ! LED is used to indicate association *and* connectivity via infrastructure mode.
• The (*) LED is used to indicate similar association *and* existence of a mesh portal.
• if neither is lit, then you are trying to use a mesh that is not connected.
• if both are lit, then you know you are a mesh portal for a mesh to the internet.

Note that this behavior has not been implemented yet. See bug #1385 to track progress.

Power Indicator LED

This LED indicates the system is powered up. It is controlled by the embedded controller.

Battery LED

The battery LED indicates information about the battery.

• if the LED is green, it indicates the battery is fully charged.
• if the LED is orange, it indicates the battery is charging
• if the LED is red, it indicates the battery charge is critically low
• if the LED is red and flashing, it indicates an error in the battery charging system.

This LED is controlled by the embedded controller's battery charging logic.

Microphone LED

If the microphone is enabled, the microphone LED is lit. This is a hardware feature than cannot be circumvented.

Camera LED

If the camera is powered on, the camera LED will be lit. This is a hardware feature than cannot be circumvented.

System Management BIOS Interface

Not Supported

Hardware Configuration

Keyboard Support

The physical keyboards are all identical on any XO-1; the firmware manufacturing information indicates which variant of keyboard is installed. We chose to use a 3.3V version of a PS/2 interface to save power. There is no provision for external PS/2 devices to be plugged in.

Keyboard Power

The keyboard and touchpad are powered up continuously when the system is in any but the powered down state (BTest-3 or later) to allow the keyboard to trigger a resume of the processor. An design oversight in BTest-1 and BTest-2 means the keyboard is not powered on those versions.

Keyboard Languages Support

Language support for a keyboard involves either three or four items:

• The keyboard engravings themselves
• XKB definitions for keyboard for the window system that defines the behavior of the keyboard. These are found in /usr/share/X11/xkb.
• A console mapping of the keyboard (generally simpler than the full X Window System keyboard definition, since the console is not fully internationalized.
• Possibly input methods for some languages (e.g. Chinese).

A single keyboard design may be capable of supporting multiple languages, and be able to switch from one language to the other.

At this time, keyboard designs have been completed for the following areas:

• Arabic
• Brazilian Portuguese
• French
• Nigeria (for English, Hausa, Yoruba)
• Spanish
• Thai
• Urdu
• US International (able to be used for many western European languages)

Which keyboard is installed is encoded in the manufacturing area of the firmware, and the correct keyboard language support installed on software installation.

Additional keyboard definitions are pretty easy to generate: input methods for complex script input may be more involved (though many already exist).

Touchpad

The touch pad/tablet has provision to be "recalibrated" under program command as of BTest-3 (maybe also BTest-2-2). This readjusts the sensitivity of the capacitive sensor. Trac bug #1407 is being used to track implementation of this power related feature. As a temporary measure, recalibrating the touch pad can be forced manually.

CPU Support

More information about the CPU can be found at Wikipedia and AMD.

• BTest-1 and BTest-2 systems both use the AMD Geode GX-400
• BTest-3 and later systems will all use the AMD Geode LX-700

All XO-1's use the AMD 5536. Note that the processor and southbridge chips both have extensive facilities to either automatically or under program control save power. Examples include the ability to power down the GPU when not in use, and turn off the video output.

Memory Support

The XO-1 uses soldered down memory on the mother board and cannot be expanded.

• BTest-1 systems all have 256M of RAM and 512M of flash.
• BTest-2-1 systems all have 128M of RAM and 512M of flash.
• BTest-2-2 systems all have 256M of RAM and 512M of flash.
• BTest-3 and later systems will all have 256M of RAM and 1GB of flash.

Wireless Hardware

The XO-1 supports 88W8388+88W8015, 802.11b/g compatible; dual adjustable, rotating coaxial antennas; supports diversity reception. It also supports an implementation of what is the evolving 802.11s mesh network draft standard.

The power consumption of the Marvell wireless module has been measured at a bit over 300mw; even with power supply losses, we expect the batteries can power the wireless for > 40 hours (to be measured).

Since the "last kilometer" problem is so great, we are engineering the system to leave the wireless active for as much of the time as possible, since the wireless can run the mesh network autonomously. The module is capable of waking up the CPU via the embedded controller.

Therefore, we expect to leave the wireless active in all modes except fully powered down (labeled state 1 below).

Additionally, there needs to be an "airplane" mode to meet FAA and similar emissions requirements for on board airplane use, in which the wireless can be disabled. This will not be easy to access, by deliberate design. Bug #1406 is being used to track this issue.

Battery Subsystem

Battery charging is controlled by the embedded controller. Both NiMH and LiFePo battery chemistries are supported by the firmware. The current state of battery charge is reflected in the Home Mode display. It is also available in the developer's console.

Linux reflects the battery information into the /sys/class/battery/psu-0 directory. The files found in this directory include:

• capacity_percentage - percentage of battery remaining
• current - the current being subtracted/added to the battery
• device - link to ../../../../devices/platform/olpc-battery.0
• name - OLPC battery
• power
  • modaliasas - olpc-battery
  • power
  • psu_0
  • psu_1
  • subsystem - link to ../../../bus/platform
  • uevent
• status - e.g. present discharging or present charging discharging
• status-cap - capabilities e.g. present low full charging discharging overtemp critical
• subsystem - link to ../../../../class/battery
• technology - unknown?? (see bug #1408)
• temp1
• temp1-name - battery
• temp2
• temp2_name - ambient
• type - battery
• uevent
• voltage - voltage in

Linux reflects the line information into the /sys/class/battery/psu-1 directory. The files found in this directory include:

One Touch Buttons

The Sugar Instructions documents the function of buttons in the Sugar user interface. Note that there are no built in function keys that are built into the BIOS firmware as there may be on a conventional PC: instead, all keys and buttons are left to the user interface software for interpretation.

The sole exception to this is the power button, where by holding the button down for four seconds you can force a hard reset of the XO-1 system.

Power Management Support

As discussed above, Linux does not depend on ACPI. To meet our fast resume goals and transparency into the firmware, we do not use ACPI, which would significantly slow our resume from suspend while adding no benefit. In this regard, we differ significantly from other x86 systems. This is the normal case for Linux on other architectures, so should not be regarded as unusual for Linux overall.

Power Button

The power button on OLPC serves as a power button.

Momentary Button Push

The system will suspend to RAM after the button is pressed momentarily. Wireless will be left operational when suspended this way. (Prior to deployment of suspend/resume, this button currently performs a clean Linux shutdown). See bug #1396 for more information.

Four Second Button Push

Pressing the power button for four seconds does a hard reset of the system and all state is lost.

Power Management States

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

1. Powered Down: This state is called G3 in ACPI terminology Everything is off and the battery can be swapped. The operating system will have to be booted to start operation; the RAM contents are not preserved. If power is available, the EC will be powered up and potentially charging the battery.
2. 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).
3. Suspended, with Mesh Active, Screen Enabled: Another common mode of use is sometimes called "ebook mode". Both the screen and the Marvell wireless are left operational: the screen by use of the DCON chip. This differs from our powered down state by the fact the Marvell wireless will be powered up, and active along with the display. In ACPI terminology, the closest match is G1/S3. The processor is suspended to RAM (in self-refresh). Note that the DCON has facilities to implement a "screen saver" where it can disable itself and the backlight after a preset time without requiring the system to be resumed from RAM.
4. System fully operational: In this state, the system is available for normal use. The ACPI processor states that this corresponds to are C0 and C1 (note that C1 is not useful on a GX, but does save power on the LX). Linux is working very hard to remove "ticks"; as of this writing, the kernel is now "tickless" and this is operational on OLPC, meaning that it no longer uses a periodic timer clock interrupt to drive the scheduling of processes (which had caused 250 interrupts and transitions from C1 to C0 per second). The OLPC has been observed at 40 per second. Work is underway in user space to abolish polling of hardware that might force wakeups, and private communications are that a full Gnome environment has been seen as low as only a few wakeups/second. Note: in this state, Linux may have many parts of the system powered down: e.g. audio, GPU, etc. as described in detail below.

Switches

There are a number of switches that are intended to help Linux know what the user is doing and take appropriate action. These are not hardwired in the firmware at all, but the following describes the expected behavior under Linux. This policy is typically controlled by a user level daemon process.

Lid Close Switch

This switch indicates the laptop has been closed. Depending upon the policy set in the power manager, the system may:

• suspend to RAM, powering down everything except the wireless (default behavior), and corresponds to state 1, as described above.
• forcing the screen off, power down the DCON, the video unit, and the video drivers. In principle, the GPU could also be disabled and applications be asked to regenerate their contents on reenable, but we'll probably get most of the power benefit by disabling the GPU when not in use.

Ebook sense switch

The Ebook sense switch indicates that the hardware is configured as an ebook, though this is just a physical configuration rather than a requirement of what sort of application is running. Depending upon the chosen application, the behavior may differ.

An ebook reader itself will ask for aggressive power management. (State 3 as described above; wireless enabled, and screen in DCON driven mode). The screen will be on, being driven at 25 hz, with the DCON configured to turn the screen and backlight off after a short timeout.