Power Management/lang-es: Difference between revisions
RafaelOrtiz (talk | contribs) |
RafaelOrtiz (talk | contribs) |
||
| Line 431: | Line 431: | ||
===System Management BIOS Interface=== |
===System Management BIOS Interface=== |
||
No Soportado |
|||
Not Supported |
|||
<div id="Battery Subsystem"/> |
<div id="Battery Subsystem"/> |
||
===Subsistema de la Batería=== |
===Subsistema de la Batería=== |
||
Revision as of 21:51, 14 May 2007
- 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.
- Hardware Power Domains
- Power Management Software
- XO Power Management Tips and Tricks
- Misc. Papers on Energy Efficiency in Computing and Networking
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.
- Los sistemas BTest-1 y BTest-2 usan el AMD Geode GX-400
- LOs sistemas BTest-3 y posteriores usan el AMD Geode LX-700
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.
Soporte de la Memoria
El XO-1 usa memorias soldadas 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
La memoria del display de Video en el XO-1 se toma de la memoria principal. Esta colocada a 16 megabytes.
Recursos del Sistema
Mapa IRQ
| 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 |
Asignación de Recursos DMA
| Canal DMA | Descripción |
|---|---|
| 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 |
Soporte para el Teclado
Los Teclados físicos son todos idénticos en cualquier XO-1; La información de fabricación del firmware indica cual variante de teclado esta instalada. Escogimos usar una versión de 3.3V de una interfase PS/2 para ahorrar energía. No hay provisiones para conectar aparatos PS/2 externos.
Potencia del teclado
El teclado y el touchpad estan prendidos continuamente cuando el sistema esta en cualquier estado menos en el estado apagado (BTest-3 o posteriores) para permitir que el teclado haga un resume al procesador. An design oversight in BTest-1 and BTest-2 means the keyboard is not powered on those versions.
Soporte de Lenguajes para el Teclado
El soporte de lenguaje para el teclado involucra tres o cuatro items:
- The keyboard engravings themselves
- XKB definitions para el teclado y para el sistema de ventanas que define el comportamiento del teclado. Estas se encuentran en /usr/share/X11/xkb.
- Un mapeo en consola del teclado, generalmente mas sencillo la definición del sistema completo de teclado X Window, ya que la consola no esta totalmente internacionalizada.
- Metodos posibles de entrada para algunos lenguajes (Como Chino).
Un diseño sencillo de teclado puede ser capaz de soportar múltiples lenguajes y ser capaz de cambiar de uno a otro.
En este momento los diseños de teclados han sido terminados para las siguientes áreas:
- Arabic
- Brazilian Portuguese
- French
- Nigeria (for English, Hausa, Yoruba)
- Spanish
- Thai
- Urdu
- US International (able to be used for many western European languages)
Que clase de teclado esta instalado, esta codificado en la área de manufactura del firmware, y el correcto soporte de lenguaje para el teclado instalado en la instalación del software.
Definiciones adicionales de teclados son fáciles de generar: métodos de entrada para scripts complejos pueden ser mas difíciles (Aunque muchos ya existen).
Touchpad
El touch pad/tablet tiene una provision para ser "recalibrado" bajo comandos de programa como en las BTest-3 (Tambien probablemente en las BTest-2-2). esto re ajusta la sensibilidad del sensor capacitivo. El Trac bug #1407 esta siendo usado para seguir la implementacion de esta caracteristica relacionada a la potencia. Como una medida temporal, recalibrar el touch pad puede ser forzado manualmente.
Wireless Hardware
La XO-1 soporta 88W8388+88W8015, es 802.11b/g compatible; dual ajustable, antenas coaxiales rotables; soporta diversidad de recepcion. Tambien soporta una implementacion de la evolucion del estandart 802.11s mesh network draft.
El consumo de potencia del modulo Marvell wireless ha sido medido como un poco mayor de 300mw; aun con perdidas de fuente de potencia, esperamos que las baterias puedan dar potencia al wireless por > 40 horas (falta ser medido).
Debido a que el problema del "ultimo Kilometro" es tan grave, estamos haciendo ingenieria al sistema con el fin de dejar el wireless activo por la mayor cantidad de tiempor posible, debido a que el wireless pude correr la red mesh autonomamente. El modulo es capaz de despertar la CPU atravez del controlador embebido. El Trac #1060 ha sido establecido para seguir el desarrollo, integracion y verifcacion del desarrollo, integracion y verificacion del modo autonomo mesh.
El firmare del wireless dinamicamente ajusta la potencia transmitida; pero elprocesamiento de la senal el receptor determina el consumo de potencia. Marvell ha hecho un extensivo trabajo para minimizar el consumo de potencia automaticamente.
Por ello, esperamos dejar el wireless activo en todos los modos exepto en el modo totalmente apagado (Marcado como estado 1 abajo); este estado tambien nos permite apagar el USB enteramente por que hay una senal del modulo wireless que permite al XO-1 ser despertado por el firmware del wireless.
Adicionalmente, debe haber un modo que cumpla con los rquirimientos de emisiones de la FAA y similares para uso dentro de los aviones, en el cual el wireless pueda ser deshabilitado. Esto no sera facil de accesar por un diseno deliverado. El Bug #1406 esta siendo usado para seguir este tema.
Controlador Embebido (CE)
El controlador embebido es un ENE KB3700: File:KB3700-ds-01.pdf. es usado para cargar la bateria, emular varios ¨legacy devices¨ (e.g. PS/2), anadir mas pines GPIO (debidoa que el Geode no tiene pines suficientes, algunas senales deben ser ruteadas atravez del CE), bootear el sistema (El flash SPI usado para guardar el firmware es una ROM serial conectada al CE), despertar el sistema bajo varias circunstancias, y otras funciones micelaneas. La EC specification contienen informacion detallada acerca de los comandos y protocolos usados para comunicarse con el CE. Un numero de botones (game pad y botones, etc.), estan unidos al CE, y tambien generan codigos de scan como si estos fueran teclas del teclado, para simplificar la interfaz de programacion. Eventos SCI tambien son generados a veces para informar al CPU de eventos, entonces el XO-1 puede evitar interfaces de polling que de otra forma requeririan despertares periodicos del sistema.
Indicadores de Estado
El XO-1 tiene muchos indicadores de estado; algunos de los cuales estan en ambos lados de la unidad principal.
La imagen en la derecha
Luces Wireless
Hay dos luces wireless. Una luz se ve casi como un punto de exclamacion y la otra como (*). Estas son usadas para indicar conectvidad.
- El LED ! es usado para indicar asociacion *y* conectividad via modo infraestructura.
- El LED (*) es usado para indicar una associacion similar y la existencia de un portal mesh.
- Si ninguno esta prendido entonces usted esta tratando de usar una mesh que no esta conectada.
- Si los dos estan encendidos, entonces usted es un portal mesh para una mesh a internet.
Note que este comportamiendo no ha sido aun implementado y requerira trabajo con el demonio NetworkManager, por que alli es el mejor lugar para saber si la conectividad esta disponible. Vea bug #1385 para seguir el progreso.
LED indicador de Prendido
Este LED indica que el sistema esta prendido. Es controlado por el controlador embebido.
LED de la Batería
El LED de la batería indica información acerca de la bateria.
- 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.
LED del Micrófono
Si el micrófono esta activado, el LED del micrófono esta prendido. Esta es una característica de Hardware que no pude ser evitada.
LED de la Cámara
Si la cámara esta prendida, el LED de la cámara se prenderá. Esta es una característica de hardware que no puede ser evitada.
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
En este momento (antes de Q2C10, como mínimo),si cualquier tecla es presionada durante el conteo inicial después del mensaje inicial, la secuencia de booteo es detenida y el interprete de comandos de OFW es invocado . OFW da un mensaje "ok" para indicar que esta listo para un comando.
Open Firmware, Prompt de comandos
Las OFW FAQ resuelven las preguntas mas comunes acerca de como interactuar con el firmware OFW de OLPC.
Suporte para Manejo de Potencia
Como se discutió arriba, Linux no depende de ACPI. Para alcanzar nuestros objetivos de un resume rápido y la transparencia en el firmware, nosotros no usamos ACPI, lo cual haría significativamente mas lento nuestro resume desde suspensión y no añadiría ningún beneficio. En este aspecto diferimos significativamente de otros sistemas x86. Este es el caso normal para linux en otras arquitecturas, entonces esto no debe ser visto como inusual para linux en conjunto.
Botón de Prendido/Apagado
Este botón en OLPC sirves como botón de prendido/apagado.
Presión de Botón Momentanea
El sistema se suspenderá a RAM después de que el botón sea oprimido momentareamente. la wireless seguira operacional mientras que se suspenda de esta forma. (Antes de el lanzamiento del suspend/resume, este botón actualmente hace un apagado limpio de Linux). Vea bug #1396 para mas información.
Presión del Botón por Cuatro Segundos
Presionar el botón de prendido/apagado por cuatro segundos resultara en un reset duro del sistema y todos los estados se perderan.
Estados de Administración de Potencia
Los siguientes son los principales sistemas de operación del sistema. Para simplicidad acerca de la terminología comúnmente usada vea Wikipedia's ACPI article.
Apagado (Completo)
En este estado, (G3 en este estado en ACPI). Todo esta apagado y la batería puede ser cambiada. El sistema operativo tendrá que ser booteado para empezar operación; la RAM no es preservada. En nuestro hardware, si hay potencia disponible, el CE sera prendido y se podra cargar la batería potencialmente.
Suspendido, con la Mesh Activa, No pantalla
Un modo comun de uso sera el sistema no siendo usado,pero un 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
No Soportado