XO-1/Software specification: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
Line 1: Line 1:
{{OLPC}}{{Translations}}{{TOCright}}
{{OLPC}}{{Translations}}{{TOCright}}
=XO-1 Software Specification=
=Power Management=
==Introduction and Related Material==
==Introduction and Related Material==
Careful stewardship of battery power is critical.
Careful stewardship of battery power is critical.
Line 24: Line 24:
We are also able to leave the Marvell wireless module to operate independently, forwarding packets in the mesh while possibly
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.
everything else is powered down.
==Firmware (aka BIOS on conventional PC's)==
=Firmware (aka BIOS on conventional PC's)=
===Use of Open Firmware===
==Open Firmware==
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 [http://www.linuxbios.org/Welcome_to_LinuxBIOS 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.
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 [http://www.linuxbios.org/Welcome_to_LinuxBIOS 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.
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===
==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).
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===
==System Identification==
The [[Manufacturing Data]] page documents the Model ID string, part number, localization information, factory, BIOS version, and many other pieces of data.
The [[Manufacturing Data]] page documents the Model ID string, part number, localization information, factory, BIOS version, and many other pieces of data.
===Quiet Boot===
==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. [http://dev.laptop.org/ticket/1394 Bug #1394] tracks this issue for eventual resolution.
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. [http://dev.laptop.org/ticket/1394 Bug #1394] tracks this issue for eventual resolution.
===POST Message===
==POST Message==
The system gives an progression of iconic images across the top of the screen to indicate progress of the boot process.
The system gives an progression of iconic images across the top of the screen to indicate progress of the boot process.


Line 62: Line 62:
ok
ok


===Open Firmware Command Prompt===
==Open Firmware Command Prompt==
The [[OFW FAQ]] answers some of the most common questions of how to interact with the OLPC OFW firmware.
The [[OFW FAQ]] answers some of the most common questions of how to interact with the OLPC OFW firmware.
=Configuration=
==Power Management Support==
==Boot Configuration==
==Device Tree==
==Video RAM==
==System Resources==
==IRQ Map==
==DMA Map==
=Status Indicators=
==Wireless Lights==
===Battery LED===
===Microphone LED===
===Camera LED===
==System Management BIOS Interface==
Not Supported
=Hardware Configuration=
==PCI Subsystem ID's==
==Keyboard Languages Support==
==CPU Support==
==Memory Module Support==
==Wireless Devices==
==One Touch Buttons==
==Battery Subsystem==
=Security=
==Firmware Recovery==
=Special Function Keys=
=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.
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===
==Power Button==
The power button on OLPC serves as a power button.
The power button on OLPC serves as a power button.
====Momentary Button Push====
===Momentary Button Push===
The system will suspend to RAM after the button is pressed momentarily. Wireless will be left operational when suspended this way.
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 [http://dev.laptop.org/ticket/1396 bug #1396] for more information.
(Prior to deployment of suspend/resume, this button currently performs a clean Linux shutdown). See [http://dev.laptop.org/ticket/1396 bug #1396] for more information.
====Four Second Button Push====
===Four Second Button Push===
Pressing the power button for four seconds does a hard reset of the system and all state is lost.
Pressing the power button for four seconds does a hard reset of the system and all state is lost.
===Power Management States===
==Power Management States==
The following are the major operating states of the system. For simplicity's sake in using commonly understood terminology, see [http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface Wikipedia's ACPI article].
The following are the major operating states of the system. For simplicity's sake in using commonly understood terminology, see [http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface Wikipedia's ACPI article].
# 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.
# 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.
Line 79: Line 104:
# 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.
# 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.
# 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.
# 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==
==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.
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.
Line 86: Line 110:
* suspend to RAM, powering down everything except the wireless (default behavior), and corresponds to state 1, as described above.
* 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.
* 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===
===Ebook sense switch===
==Thermal Management==
==Thermal Management==
==Configuration==
==Video==
==Wireless==
===Boot Configuration===
===Device Tree===
===Video RAM===
===System Resources===
===IRQ Map===
===DMA Map===
==Status Indicators==
===Wireless Lights===
====Battery LED====
====Microphone LED====
====Camera LED====
==Security==
===Firmware Recovery===
==Special Function Keys==
===Video===
===Wireless===
===System Management BIOS Interface===
Not Supported


=Hardware Power Management=
===Battery Subsystem===
==Hardware Power Management==
==Device Tree Support==
==Power Management==
===Device Tree Support===
===Power Management===
===Device Power Down===
====Device Power Down====
====Sleeping States====
====Sleeping States====
====Thermal Management====
===Thermal Management===
====Lid Close====
===Lid Close===
=Platform Power Management Software=
===PCI Subsystem ID's===
==Screen==

===Keyboard Languages Support===
===DCON mode===
===CPU Support===
===Refresh Rate===
===Memory Module Support===
===GPU Powered Up===
==Audio==
===Wireless Devices===
==USB==
===One Touch Buttons===
==Keyboard/Touchpad==
==Platform Software==
===Screen===
====DCON mode====
====Refresh Rate====
====GPU Powered Up====
===Audio===
===USB===
===Keyboard/Touchpad===


[[Category:Hardware]]
[[Category:Hardware]]

Revision as of 03:09, 5 May 2007

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

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.

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.

Configuration

Boot Configuration

Device Tree

Video RAM

System Resources

IRQ Map

DMA Map

Status Indicators

Wireless Lights

Battery LED

Microphone LED

Camera LED

System Management BIOS Interface

Not Supported

Hardware Configuration

PCI Subsystem ID's

Keyboard Languages Support

CPU Support

Memory Module Support

Wireless Devices

One Touch Buttons

Battery Subsystem

Security

Firmware Recovery

Special Function Keys

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

Thermal Management

Video

Wireless

Hardware Power Management

Device Tree Support

Power Management

Device Power Down

Sleeping States

Thermal Management

Lid Close

Platform Power Management Software

Screen

DCON mode

Refresh Rate

GPU Powered Up

Audio

USB

Keyboard/Touchpad