Power Management/lang-es: Difference between revisions

From OLPC
Jump to navigation Jump to search
(added inlined anchors)
Line 1: Line 1:
{{OLPC}}{{Translation | lang = es | source = Power Management | version = 36691}}{{__TOCright__}}{{Ongoing Translation}}
{{OLPC}}{{Translation | lang = es | source = Power Management | version = 36691}}{{__TOCright__}}{{Ongoing Translation}}
<div id="Power Management"/>
<div id="Power Management"/>
<big>Administración de potencia</big>
<big>Administración de Energía</big>


<div id="Introduction and Related Material"/>
==Introducción y material relacionado <div id="Introduction and Related Material"/>==
==Introducción y material relacionado==


Careful stewardship of battery power is critical.
Careful stewardship of battery power is critical.
Line 17: Line 16:
Ademas de manejar efectivamente la potencia que hay en la batería también la pagina [[Battery and power]] discute muchas fuentes alternas de potencia que pueden ser usadas para complementar el actual cargador.
Ademas de manejar efectivamente la potencia que hay en la batería también la pagina [[Battery and power]] discute muchas fuentes alternas de potencia que pueden ser usadas para complementar el actual cargador.


<div id="Linux's Approach to Power Control"/>
==Enfoque de Linux al control de potencia <div id="Linux's Approach to Power Control"/>==

==Enfoque de Linux al control de potencia==


Linux es una plataforma altamente portable que corre en casi todas las arquitecturas importantes, incluso muchas que son usadas para sistemas embebidos que utilizan baterías. Por ello la infraestructura para manejo de potencia se ha vuelto algo sofisticada en los últimos años, aunque aun esta madurando. Esto significa que las instalaciones son generales y no estan atadas a una arquitectura particular. La primera generación del sistema OLPC, siendo de la parte x86 del mundo es por ello similar '''y''' fundamentalmente diferente de otros sistemas basados en x86, por razones que seran claras en la siguiente discusión.
Linux es una plataforma altamente portable que corre en casi todas las arquitecturas importantes, incluso muchas que son usadas para sistemas embebidos que utilizan baterías. Por ello la infraestructura para manejo de potencia se ha vuelto algo sofisticada en los últimos años, aunque aun esta madurando. Esto significa que las instalaciones son generales y no estan atadas a una arquitectura particular. La primera generación del sistema OLPC, siendo de la parte x86 del mundo es por ello similar '''y''' fundamentalmente diferente de otros sistemas basados en x86, por razones que seran claras en la siguiente discusión.
Line 25: Line 22:
Linux no es dependiente de ACPI o los mas viejos sistemas de administración de potencia APM, que son específicos para x86. Por ello, el diseño de Linux ha siempre hecho su control de potencia en el sistema operativo, y ACPI u otros parecidos son considerados "dependientes de la plataforma".
Linux no es dependiente de ACPI o los mas viejos sistemas de administración de potencia APM, que son específicos para x86. Por ello, el diseño de Linux ha siempre hecho su control de potencia en el sistema operativo, y ACPI u otros parecidos son considerados "dependientes de la plataforma".


<div id="OLPC's Innovations"/>
==Innovaciones de OLPC <div id="OLPC's Innovations"/>==

==Innovaciones de OLPC==


El chip DCON nos deja manejar el refresco de nuestro "flat panel" de bajo consumo de potencia y por ello apagar completamente la board del procesador. Dado que nuestro "flat panel" es usable en modo de escala de grises a 1 vatio, usted puede ver que las corrientes de fuga (leakage) y el consumo de potencia de la fuente de poder pueden dominar el consumo de potencia fácilmente.
El chip DCON nos deja manejar el refresco de nuestro "flat panel" de bajo consumo de potencia y por ello apagar completamente la board del procesador. Dado que nuestro "flat panel" es usable en modo de escala de grises a 1 vatio, usted puede ver que las corrientes de fuga (leakage) y el consumo de potencia de la fuente de poder pueden dominar el consumo de potencia fácilmente.
Podemos también ser capaces de dejar que el modulo wireless de Marvell opere independientemente, mandando paquetes por la Mesh mientras que posiblemente todo lo demás este apagado.
Podemos también ser capaces de dejar que el modulo wireless de Marvell opere independientemente, mandando paquetes por la Mesh mientras que posiblemente todo lo demás este apagado.


<div id="Firmware (aka BIOS on conventional PC's)"/>
=Configuracion de Hardware <div id="Firmware (aka BIOS on conventional PC's)"/>=

==Soporte del CPU <div id="CPU Support"/>==


=Configuracion de Hardware =
==Soporte del CPU==
Mas informacion sobre el CPU puede encontrarse en can be found at [http://en.wikipedia.org/wiki/Amd_geode#AMD_Geode Wikipedia] y [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330,00.html AMD].
Mas informacion sobre el CPU puede encontrarse en can be found at [http://en.wikipedia.org/wiki/Amd_geode#AMD_Geode Wikipedia] y [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330,00.html AMD].
* Los sistemas BTest-1 y BTest-2 usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9864,00.html AMD Geode GX-400]
* Los sistemas BTest-1 y BTest-2 usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9864,00.html AMD Geode GX-400]
* LOs sistemas BTest-3 y posteriores usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022,00.html AMD Geode LX-700]
* LOs sistemas BTest-3 y posteriores usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022,00.html AMD Geode LX-700]

==AMD Geode™ CS5536 Companion Device==
==AMD Geode™ CS5536 Companion Device <div id="AMD Geode™ CS5536 Companion Device"/>==

Todos los XO-1' usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022%5E13054,00.html AMD 5536]. Note que el procesador y los chips southbridge tienen facultades entendibles para ahorrar potencia automáticamente o bajo programa. Los ejemplos incluyen la habilidad de apagar el GPU cuando no esta en uso y apagar la salida de video.
Todos los XO-1' usan el [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022%5E13054,00.html AMD 5536]. Note que el procesador y los chips southbridge tienen facultades entendibles para ahorrar potencia automáticamente o bajo programa. Los ejemplos incluyen la habilidad de apagar el GPU cuando no esta en uso y apagar la salida de video.

==Memory Support==
==Memory Support <div id="Memory Support"/>==

El XO-1 usa memorias soldada en la tarjeta madre y esta no puede ser expandida.
El XO-1 usa memorias soldada en la tarjeta madre y esta no puede ser expandida.
* BTest-1 Tienen 256M de RAM y 512M de flash.
* BTest-1 Tienen 256M de RAM y 512M de flash.
Line 47: Line 46:
* BTest-2-2 Tienen 256M de RAM y 512M de flash.
* BTest-2-2 Tienen 256M de RAM y 512M de flash.
* BTest-3 y posteriores tendrán 256M de RAM y 1GB of flash.
* BTest-3 y posteriores tendrán 256M de RAM y 1GB of flash.

==Video RAM==
==Video RAM <div id="Video RAM"/>==

Video display memory on the XO-1 is taken from main memory. It is set to 16 megabytes.
Video display memory on the XO-1 is taken from main memory. It is set to 16 megabytes.

==System Resources==
==System Resources <div id="System Resources"/>==
==IRQ Map==

==IRQ Map <div id="IRQ Map"/>==
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 122: Line 125:
|}
|}


==DMA Resource Assignments==
==DMA Resource Assignments <div id="DMA Resource Assignments"/>==
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 154: Line 157:
|-
|-
|}
|}

==Keyboard Support==
==Keyboard Support <div id="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.
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===
===Keyboard Power <div id="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.
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===
===Keyboard Languages Support <div id="Keyboard Languages Support"/>===

Language support for a keyboard involves either three or four items:
Language support for a keyboard involves either three or four items:
* The keyboard engravings themselves
* The keyboard engravings themselves
Line 179: Line 188:


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

==Touchpad==
==Touchpad <div id="Touchpad"/>==

The [[Touch Pad/Tablet|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. [http://dev.laptop.org/ticket/1407 Trac bug #1407] is being used to track implementation of this power related feature. As a temporary measure, [[Recalibrating Touchpad|recalibrating the touch pad]] can be forced manually.
The [[Touch Pad/Tablet|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. [http://dev.laptop.org/ticket/1407 Trac bug #1407] is being used to track implementation of this power related feature. As a temporary measure, [[Recalibrating Touchpad|recalibrating the touch pad]] can be forced manually.

==Wireless Hardware==
==Wireless Hardware <div id="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 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.


Line 194: Line 207:
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. [http://dev.laptop.org/ticket/1406 Bug #1406] is being used to track this issue.
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. [http://dev.laptop.org/ticket/1406 Bug #1406] is being used to track this issue.


==Embedded Controller==
==Embedded Controller <div id="Embedded Controller"/>==

The embedded controller is an ENE KB3700: [[Image:KB3700-ds-01.pdf]]. It is used to charge the battery, emulate various legacy devices (e.g. PS/2),
The embedded controller is an ENE KB3700: [[Image:KB3700-ds-01.pdf]]. It is used to charge the battery, emulate various legacy devices (e.g. PS/2),
add more GPIO pins (since the Geode does not have enough pins, some signals have to be routed through the EC), boot the system (the SPI flash used to store the firmware is a serial ROM attached to the EC), wake up the system under various circumstances, and other miscellaneous functions. The [[Ec specification|EC specification]] contains detailed information about the commands and protocol used to communicate with the EC. A number of buttons (game pad and buttons, etc.), are interfaced to the EC, and also generate scan codes as though they were keyboard keys, to simplify the programming interface. SCI events are also generated at times to inform the CPU of events, so that the XO-1 can avoid polling interfaces that would otherwise require periodic wake ups.
add more GPIO pins (since the Geode does not have enough pins, some signals have to be routed through the EC), boot the system (the SPI flash used to store the firmware is a serial ROM attached to the EC), wake up the system under various circumstances, and other miscellaneous functions. The [[Ec specification|EC specification]] contains detailed information about the commands and protocol used to communicate with the EC. A number of buttons (game pad and buttons, etc.), are interfaced to the EC, and also generate scan codes as though they were keyboard keys, to simplify the programming interface. SCI events are also generated at times to inform the CPU of events, so that the XO-1 can avoid polling interfaces that would otherwise require periodic wake ups.


=Status Indicators <div id="Status Indicators"/>=


=Status Indicators=
The XO-1 has a number of status indicators; some of which are on both sides of the main unit.
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[[Image:Drawing75c1.jpg|right]] of a BTest-2 system has most of these, though some
The picture to the right[[Image:Drawing75c1.jpg|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).
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==
==Wireless Lights <div id="Wireless Lights"/>==

There are two wireless lights. One light looks roughly like an exclamation point, and the other like (*).
There are two wireless lights. One light looks roughly like an exclamation point, and the other like (*).
These are used to indicate connectivity
These are used to indicate connectivity
Line 211: Line 227:
* if both are lit, then you know you are a mesh portal for a mesh to the internet.
* 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, and will require work in the NetworkManager daemon, as it is probably the best place that knows if connectivity is available. See [http://dev.laptop.org/ticket/1385 bug #1385] to track progress.
Note that this behavior has not been implemented yet, and will require work in the NetworkManager daemon, as it is probably the best place that knows if connectivity is available. See [http://dev.laptop.org/ticket/1385 bug #1385] to track progress.

===Power Indicator LED===
===Power Indicator LED <div id="Power Indicator LED"/>===

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

===Battery LED===
===Battery LED <div id="Battery LED"/>===

The battery LED indicates information about the battery.
The battery LED indicates information about the battery.
* if the LED is green, it indicates the battery is fully charged.
* if the LED is green, it indicates the battery is fully charged.
Line 221: Line 241:
This LED is controlled by the embedded controller's battery charging logic.
This LED is controlled by the embedded controller's battery charging logic.


===Microphone LED===
===Microphone LED <div id="Microphone LED"/>===

If the microphone is enabled, the microphone LED is lit. This is a hardware feature than cannot be circumvented.
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.


===Camera LED <div id="Camera LED"/>===


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


==Firmware (BIOS en PC's convencionales)==
==Firmware (BIOS en PC's convencionales) <div id="Firmware (aka BIOS on conventional PC's)"/>==


<div id="Use of Open Firmware"/>
===Uso del Open Firmware <div id="Use of Open Firmware"/>===
===Uso del Open Firmware===


Aparte de usar una BIOS y boot loader, para la serie "C" de nuestro firmware estamos usando [[Open Firmware]]. Ya no usamos [http://www.linuxbios.org/Welcome_to_LinuxBIOS LinuxBIOS] para el setup de nuestro s¡stema. Este es el resultado de haber implementado un resume fast past resume desde la RAM; una vez esto es implementado, el setup inicial del sistema es casi idéntico.
Aparte de usar una BIOS y boot loader, para la serie "C" de nuestro firmware estamos usando [[Open Firmware]]. Ya no usamos [http://www.linuxbios.org/Welcome_to_LinuxBIOS LinuxBIOS] para el setup de nuestro s¡stema. Este es el resultado de haber implementado un resume fast past resume desde la RAM; una vez esto es implementado, el setup inicial del sistema es casi idéntico.
Line 237: Line 257:
Tambien hemos removido el soporte VSA y VESA (Soporte de sistemas virtuales del Geode) de nuestro firmware. Ahora que nuestro PCI bus esta arreglado, no tenemos necesidad de registros de configuración del PCI. Similarmente al usar el fbdev driver en Linux, no tenemos necesidad de la emulación VESA; mientras que la emulación del bus PCI era software libre (AMD la hizo disponible generosamente), la emulación VESA fue una parte de VSA que no les pertenecía, y por ello no teníamos fuentes para este. No queríamos un "blob" binario inmantenible en nuestro firmware que no necesitábamos de cualquier forma, y salva espacio en la flash para otros propósitos.
Tambien hemos removido el soporte VSA y VESA (Soporte de sistemas virtuales del Geode) de nuestro firmware. Ahora que nuestro PCI bus esta arreglado, no tenemos necesidad de registros de configuración del PCI. Similarmente al usar el fbdev driver en Linux, no tenemos necesidad de la emulación VESA; mientras que la emulación del bus PCI era software libre (AMD la hizo disponible generosamente), la emulación VESA fue una parte de VSA que no les pertenecía, y por ello no teníamos fuentes para este. No queríamos un "blob" binario inmantenible en nuestro firmware que no necesitábamos de cualquier forma, y salva espacio en la flash para otros propósitos.


<div id="Fast Resume"/>
===Reinicio (Resume) Rapido <div id="Fast Resume"/>===

===Reinicio (Resume) Rapido===


El Resume en nuestro sistema es extremadamente rápido: aun sin ningún intento serio de optimizar el resume, podemos reiniciar desde RAM en 160 milisegundos (mediados-Abril). Creemos que las limitaciones de hardware para el resume son de aproximadamente 63 milisegundos en el B2 y sistemas anteriores; B3 y posteriores son probablemente similares. Trabajaremos mas en el futuro para hacer que el resume sea mas rápido. Note que para la mayoría de usos, 100ms es considerado como el limite de la percepción humana (e.g. tipear).
El Resume en nuestro sistema es extremadamente rápido: aun sin ningún intento serio de optimizar el resume, podemos reiniciar desde RAM en 160 milisegundos (mediados-Abril). Creemos que las limitaciones de hardware para el resume son de aproximadamente 63 milisegundos en el B2 y sistemas anteriores; B3 y posteriores son probablemente similares. Trabajaremos mas en el futuro para hacer que el resume sea mas rápido. Note que para la mayoría de usos, 100ms es considerado como el limite de la percepción humana (e.g. tipear).


<div id="System Identification"/>
===Identificación del sistema <div id="System Identification"/>===

===Identificación del sistema===


La pagina [[Manufacturing Data]] documenta la cadena del ID del Modelo, numero de las partes, información de localización, empresa, versión de la BIOS y muchas otros piezas de datos.
La pagina [[Manufacturing Data]] documenta la cadena del ID del Modelo, numero de las partes, información de localización, empresa, versión de la BIOS y muchas otros piezas de datos.


<div id="Quiet Boot"/>
===Boot "Silencioso" <div id="Quiet Boot"/>===

===Boot "Silencioso"===


El booteo no es "silencioso" en este momento. Linux tiene facilidades para hacer un splash screen en el booteo para esconder los mensajes de booteo, pero OLPC no ha implementado esto todavía. El [http://dev.laptop.org/ticket/1394 Bug #1394] anota este asunto para su eventual resolución.
El booteo no es "silencioso" en este momento. Linux tiene facilidades para hacer un splash screen en el booteo para esconder los mensajes de booteo, pero OLPC no ha implementado esto todavía. El [http://dev.laptop.org/ticket/1394 Bug #1394] anota este asunto para su eventual resolución.


<div id="POST Message"/>
===POST Message <div id="POST Message"/>===

===POST Message===


At this moment (prior to Q2C10, at a minimum), if any key is pressed during the initial countdown after the initial message, the boot sequence is stopped and OFW's command interpreter invoked. OFW gives a cheery "ok" message to indicate it is ready for a command.
At this moment (prior to Q2C10, at a minimum), if any key is pressed during the initial countdown after the initial message, the boot sequence is stopped and OFW's command interpreter invoked. OFW gives a cheery "ok" message to indicate it is ready for a command.


<div id="Open Firmware Command Prompt"/>
===Open Firmware Command Prompt <div id="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.


<div id="Power Management Support"/>
==Power Management Support <div id="Power Management Support"/>==

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


<div id="Power Button"/>
===Botón de Prendido/Apagado <div id="Power Button"/>===
===Botón de Prendido/Apagado===


The power button on OLPC serves as a power button.
The power button on OLPC serves as a power button.


<div id="Momentary Button Push"/>
====Momentary Button Push <div id="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.


<div id="Four Second Button Push"/>
====Four Second Button Push <div id="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.


<div id="Power Management States"/>
===Estados de Administración de Potencia <div id="Power Management States"/>===
===Estados de Administración de Potencia===


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


<div id="Powered Down"/>
====Powered Down <div id="Powered Down"/>====
====Powered Down====


In this state, (G3 is this state in ACPI). 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.
In this state, (G3 is this state in ACPI). 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.


<div id="Suspended, with Mesh Active, No screen"/>
====Suspended, with Mesh Active, No screen <div id="Suspended, with Mesh Active, No screen"/>====
====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).
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).


<div id="Suspended, with Mesh Active, Screen Enabled"/>
====Suspended, with Mesh Active, Screen Enabled <div id="Suspended, with Mesh Active, Screen Enabled"/>====
====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.
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.


<div id="System fully operational"/>
====System fully operational <div id="System fully operational"/>====
====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.
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.
Line 315: Line 316:
Note that in this state, Linux may have many parts of the system powered down: e.g. audio, GPU, etc. as described in detail below.
Note that in this state, Linux may have many parts of the system powered down: e.g. audio, GPU, etc. as described in detail below.


<div id="Switches"/>
==Switches <div id="Switches"/>==
==Switches==


<div id="Lid Close Switch"/>
===Lid Close Switch <div id="Lid Close Switch"/>===
===Lid Close Switch===


<div id="Ebook Sense Switch"/>
===Ebook Sense Switch <div id="Ebook Sense Switch"/>===
===Ebook Sense Switch===


<div id="Rotation Switch"/>
===Rotation Switch <div id="Rotation Switch"/>===
===Rotation Switch===


<div id="Thermal Management"/>
==Thermal Management <div id="Thermal Management"/>==
==Thermal Management==


<div id="Configuration"/>
==Configuración <div id="Configuration"/>==
==Configuración==


<div id="Boot Configuration"/>
===Configuración del Boot <div id="Boot Configuration"/>===
===Configuración del Boot===


<div id="Device Tree"/>
===Device Tree <div id="Device Tree"/>===
===Device Tree===


<div id="Video RAM"/>
===Video RAM <div id="Video RAM"/>===
===Video RAM===


<div id="System Resources"/>
===Recursos del sistema <div id="System Resources"/>===
===Recursos del sistema===


<div id="IRQ Map"/>
===Mapa IRQ <div id="IRQ Map"/>===
===Mapa IRQ ===


<div id="DMA Map"/>
===Mapa DMA <div id="DMA Map"/>===
===Mapa DMA ===


<div id="Status Indicators"/>
==Indicadores de Estado <div id="Status Indicators"/>==
==Indicadores de Estado==


<div id="Wireless Lights"/>
===Wireless Lights <div id="Wireless Lights"/>===
===Wireless Lights===


<div id="Battery LED"/>
====LED de la Bateria <div id="Battery LED"/>====
====LED de la Bateria====


<div id="Microphone LED"/>
====LED del Micrófono <div id="Microphone LED"/>====
====LED del Microfono====


<div id="Camera LED"/>
====LED de la Cámara <div id="Camera LED"/>====
====LED de la Camara====


<div id="Security"/>
==Seguridad <div id="Security"/>==
==Seguridad==


<div id="Firmware Recovery"/>
===Firmware Recovery <div id="Firmware Recovery"/>===
===Firmware Recovery===


<div id="Special Function Keys"/>
==Special Function Keys <div id="Special Function Keys"/>==
==Special Function Keys==


<div id="Video"/>
===Video <div id="Video"/>===
===Video===


<div id="Wireless"/>
===Wireless <div id="Wireless"/>===
===Wireless===


<div id="System Management BIOS Interface"/>
===System Management BIOS Interface <div id="System Management BIOS Interface"/>===
===System Management BIOS Interface===


Not Supported
Not Supported


<div id="Battery Subsystem"/>
===Subsistema de la Batería <div id="Battery Subsystem"/>===
===Subsistema de la Batería===


<div id="Hardware Power Management"/>
==Hardware Power Management <div id="Hardware Power Management"/>==
==Hardware Power Management==


<div id="Device Tree Support"/>
===Device Tree Support <div id="Device Tree Support"/>===
===Device Tree Support===


<div id="Power Management"/>
===Power Management <div id="Power Management"/>===
===Power Management===


<div id="Device Power Down"/>
====Device Power Down <div id="Device Power Down"/>====
====Device Power Down====


<div id="Sleeping States"/>
====Sleeping States <div id="Sleeping States"/>====
====Sleeping States====


<div id="Thermal Management"/>
====Thermal Management <div id="Thermal Management"/>====
====Thermal Management====


<div id="Lid Close"/>
====Lid Close <div id="Lid Close"/>====
====Lid Close====


<div id="PCI Subsystem ID's"/>
===PCI Subsystem ID's <div id="PCI Subsystem ID's"/>===
===PCI Subsystem ID's===


<div id="Keyboard Languages Support"/>
===Keyboard Languages Support <div id="Keyboard Languages Support"/>===
===Keyboard Languages Support===


<div id="CPU Support"/>
===CPU Support <div id="CPU Support"/>===
===CPU Support===


<div id="Memory Module Support"/>
===Memory Module Support <div id="Memory Module Support"/>===
===Memory Module Support===


<div id="Wireless Devices"/>
===Wireless Devices <div id="Wireless Devices"/>===
===Wireless Devices===


<div id="One Touch Buttons"/>
===One Touch Buttons <div id="One Touch Buttons"/>===
===One Touch Buttons===


<div id="Platform Software"/>
==Platform Software <div id="Platform Software"/>==
==Platform Software==


<div id="Screen"/>
===Screen <div id="Screen"/>===
===Screen===


<div id="DCON mode"/>
====DCON mode <div id="DCON mode"/>====
====DCON mode====


<div id="Refresh Rate"/>
====Refresh Rate <div id="Refresh Rate"/>====
====Refresh Rate====


<div id="GPU Powered Up"/>
====GPU Powered Up <div id="GPU Powered Up"/>====
====GPU Powered Up====


<div id="Audio"/>
===Audio <div id="Audio"/>===
===Audio===


<div id="USB"/>
===USB <div id="USB"/>===
===USB===


<div id="Keyboard/Touchpad"/>
===Keyboard/Touchpad <div id="Keyboard/Touchpad"/>===
===Keyboard/Touchpad===





Revision as of 21:31, 9 May 2007

  Esta página está supervisada por el equipo de OLPC.
  Traducción de Power Management original  
  english | español | 日本語 | 한국어   +/- cambios  
This is an on-going translation

Administración de Energía

Introducción y material relacionado

Careful stewardship of battery power is critical.

Esta pagina es un trabajo en proceso que recopila información relacionada a la administración de potencia de OLPC.

Ademas de manejar efectivamente la potencia que hay en la batería también la pagina Battery and power discute muchas fuentes alternas de potencia que pueden ser usadas para complementar el actual cargador.

Enfoque de Linux al control de potencia

Linux es una plataforma altamente portable que corre en casi todas las arquitecturas importantes, incluso muchas que son usadas para sistemas embebidos que utilizan baterías. Por ello la infraestructura para manejo de potencia se ha vuelto algo sofisticada en los últimos años, aunque aun esta madurando. Esto significa que las instalaciones son generales y no estan atadas a una arquitectura particular. La primera generación del sistema OLPC, siendo de la parte x86 del mundo es por ello similar y fundamentalmente diferente de otros sistemas basados en x86, por razones que seran claras en la siguiente discusión.

Linux no es dependiente de ACPI o los mas viejos sistemas de administración de potencia APM, que son específicos para x86. Por ello, el diseño de Linux ha siempre hecho su control de potencia en el sistema operativo, y ACPI u otros parecidos son considerados "dependientes de la plataforma".

Innovaciones de OLPC

El chip DCON nos deja manejar el refresco de nuestro "flat panel" de bajo consumo de potencia y por ello apagar completamente la board del procesador. Dado que nuestro "flat panel" es usable en modo de escala de grises a 1 vatio, usted puede ver que las corrientes de fuga (leakage) y el consumo de potencia de la fuente de poder pueden dominar el consumo de potencia fácilmente. Podemos también ser capaces de dejar que el modulo wireless de Marvell opere independientemente, mandando paquetes por la Mesh mientras que posiblemente todo lo demás este apagado.

Configuracion de Hardware

Soporte del CPU

Mas informacion sobre el CPU puede encontrarse en can be found at Wikipedia y AMD.

AMD Geode™ CS5536 Companion Device

Todos los XO-1' usan el AMD 5536. Note que el procesador y los chips southbridge tienen facultades entendibles para ahorrar potencia automáticamente o bajo programa. Los ejemplos incluyen la habilidad de apagar el GPU cuando no esta en uso y apagar la salida de video.

Memory Support

El XO-1 usa memorias soldada en la tarjeta madre y esta no puede ser expandida.

  • BTest-1 Tienen 256M de RAM y 512M de flash.
  • BTest-2-1 Tienen 128M de RAM y 512M de flash.
  • BTest-2-2 Tienen 256M de RAM y 512M de flash.
  • BTest-3 y posteriores tendrán 256M de RAM y 1GB of flash.

Video RAM

Video display memory on the XO-1 is taken from main memory. It is set to 16 megabytes.

System Resources

IRQ Map

System Interrupt Connected Pin Function
IRQ0 System Timer
IRQ1 PS2 Keyboard
IRQ2 Cascade from Second PIC
IRQ3 Available
IRQ4 Available
IRQ5 Audio IRQ AC 97 Audio
IRQ6 Available
IRQ7 PCI INTC# NAND/SD card/Camera
IRQ8 Real time Clock (RTC) Interrupt
IRQ9 SCI
IRQ10 USB IRQ USB controllers
IRQ11 PCI INTB# VGA/DCON
IRQ12 PS2 Touch Pad
IRQ13 PCI INTA# Math processor
IRQ14 Available
IRQ15 Available

DMA Resource Assignments

DMA Channel Description
Channel 0 Used for Memory Refresh
Channel 1 Available
Channel 2 Available
Channel 3 Available
Channel 4 Used Cascade channels 0-3
Channel 5 Available
Channel 6 Available
Channel 7 Available

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:

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

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. Trac #1060 has been established to track the development, integration and verification of autonomous mesh mode.

The wireless firmware dynamically adjusts transmit power; but signal processing in receive dominates power consumption. Marvell has done extensive work to minimize power consumption automatically.

Therefore, we expect to leave the wireless active in all modes except fully powered down (labeled state 1 below); this state also allows us to turn off the USB entirely as there is a signal from the wireless module that allows the XO-1 to be woken up by the wireless firmware.

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.

Embedded Controller

The embedded controller is an ENE KB3700: File:KB3700-ds-01.pdf. It is used to charge the battery, emulate various legacy devices (e.g. PS/2), add more GPIO pins (since the Geode does not have enough pins, some signals have to be routed through the EC), boot the system (the SPI flash used to store the firmware is a serial ROM attached to the EC), wake up the system under various circumstances, and other miscellaneous functions. The EC specification contains detailed information about the commands and protocol used to communicate with the EC. A number of buttons (game pad and buttons, etc.), are interfaced to the EC, and also generate scan codes as though they were keyboard keys, to simplify the programming interface. SCI events are also generated at times to inform the CPU of events, so that the XO-1 can avoid polling interfaces that would otherwise require periodic wake ups.

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
Drawing75c1.jpg
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, and will require work in the NetworkManager daemon, as it is probably the best place that knows if connectivity is available. 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.

Firmware (BIOS en PC's convencionales)

Uso del Open Firmware

Aparte de usar una BIOS y boot loader, para la serie "C" de nuestro firmware estamos usando Open Firmware. Ya no usamos LinuxBIOS para el setup de nuestro s¡stema. Este es el resultado de haber implementado un resume fast past resume desde la RAM; una vez esto es implementado, el setup inicial del sistema es casi idéntico.

Tambien hemos removido el soporte VSA y VESA (Soporte de sistemas virtuales del Geode) de nuestro firmware. Ahora que nuestro PCI bus esta arreglado, no tenemos necesidad de registros de configuración del PCI. Similarmente al usar el fbdev driver en Linux, no tenemos necesidad de la emulación VESA; mientras que la emulación del bus PCI era software libre (AMD la hizo disponible generosamente), la emulación VESA fue una parte de VSA que no les pertenecía, y por ello no teníamos fuentes para este. No queríamos un "blob" binario inmantenible en nuestro firmware que no necesitábamos de cualquier forma, y salva espacio en la flash para otros propósitos.

Reinicio (Resume) Rapido

El Resume en nuestro sistema es extremadamente rápido: aun sin ningún intento serio de optimizar el resume, podemos reiniciar desde RAM en 160 milisegundos (mediados-Abril). Creemos que las limitaciones de hardware para el resume son de aproximadamente 63 milisegundos en el B2 y sistemas anteriores; B3 y posteriores son probablemente similares. Trabajaremos mas en el futuro para hacer que el resume sea mas rápido. Note que para la mayoría de usos, 100ms es considerado como el limite de la percepción humana (e.g. tipear).

Identificación del sistema

La pagina Manufacturing Data documenta la cadena del ID del Modelo, numero de las partes, información de localización, empresa, versión de la BIOS y muchas otros piezas de datos.

Boot "Silencioso"

El booteo no es "silencioso" en este momento. Linux tiene facilidades para hacer un splash screen en el booteo para esconder los mensajes de booteo, pero OLPC no ha implementado esto todavía. El Bug #1394 anota este asunto para su eventual resolución.

POST Message

At this moment (prior to Q2C10, at a minimum), if any key is pressed during the initial countdown after the initial message, the boot sequence is stopped and OFW's command interpreter invoked. OFW gives a cheery "ok" message to indicate it is ready for a command.

Open Firmware Command Prompt

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

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.

Botón de Prendido/Apagado

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.

Estados de Administración de Potencia

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

Powered Down

In this state, (G3 is this state in ACPI). 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).

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 that in this state, Linux may have many parts of the system powered down: e.g. audio, GPU, etc. as described in detail below.

Switches

Lid Close Switch

Ebook Sense Switch

Rotation Switch

Thermal Management

Configuración

Configuración del Boot

Device Tree

Video RAM

Recursos del sistema

Mapa IRQ

Mapa DMA

Indicadores de Estado

Wireless Lights

LED de la Bateria

LED del Micrófono

LED de la Cámara

Seguridad

Firmware Recovery

Special Function Keys

Video

Wireless

System Management BIOS Interface

Not Supported

Subsistema de la Batería

Hardware Power Management

Device Tree Support

Power Management

Device Power Down

Sleeping States

Thermal Management

Lid Close

PCI Subsystem ID's

Keyboard Languages Support

CPU Support

Memory Module Support

Wireless Devices

One Touch Buttons

Platform Software

Screen

DCON mode

Refresh Rate

GPU Powered Up

Audio

USB

Keyboard/Touchpad