Power Management/lang-es

Administración de Energía

  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

XO-1 Especificación de Software

Introducción y material relacionado

La administración cuidadosa de la energía de batería es crítica.

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.

Careful stewardship of battery power is critical.

OLPC power management is a work in progress.

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

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

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

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

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.

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.

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

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

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

AMD Geode™ CS5536 Chip Acompañante

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.

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

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.

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

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

Video RAM

La memoria del display de Video en el XO-1 se toma de la memoria principal. Esta colocada a 16 megabytes.Lops sistemas con base GX usan 8 megabytes.

Video display memory on the XO-1 is taken from main memory. LX-based systems use 16 megabytes of main memory for display purposes, GX-based systems use 8 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

Inter. Sistema	Conector	Función
IRQ0		Temporizador del Sistema
IRQ1		Teclado PS2
IRQ2		Cascada del segundo PIC
IRQ3		Disponible
IRQ4		Disponible
IRQ5	IRQ Audio	AC 97 Audio
IRQ6		Disponible
IRQ7	PCI INTC#	NAND/tarjeta SD/Cámara
IRQ8		Real time Clock (RTC) Interrupt
IRQ9		SCI
IRQ10	USB IRQ	Controladores USB
IRQ11	PCI INTB#	VGA/DCON
IRQ12		Touch Pad PS2
IRQ13	PCI INTA#	Procesador matemático
IRQ14		Disponible
IRQ15		Disponible

Asignación de Recursos DMA

OLPC does not use legacy ISA DMA. All DMA is done via PCI bus mastering, so fixed resource allocation is not necessary.

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.

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

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.

The keyboard and touchpad are powered up continuously in both fully-opeationalal and suspended-to-RAM states (BTest-3 or later) so the keyboard can trigger a resume of the processor. On BTest-1 and BTest-2 the keyboard is not powered during suspend, due to a design oversight.

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

Language support for a keyboard involves several items:

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

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

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

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

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

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

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.

The touch pad/tablet can 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

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.

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

The power consumption of the Marvell wireless module has been measured at just 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.

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.

The embedded controller, an ENE KB3700: File:KB3700-ds-01.pdf, 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.

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

que es de un sistema BTest-2 tienen la mayoria de ellos, aunque algunos seran usados en diferente forma que los actuales. Los sistemas XO-1 de produccion final les faltara las luces del teclado y tendran luces de indicacion para el microfono y la camara. Una fotografia con marcas de un sistema BTest-3 se anadira tan pronto sea posible (en algun momento en las dos ulimas semanas de mayo).

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

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.

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.

LED indicador de Prendido

Este LED indica que el sistema esta prendido. Es controlado por el controlador embebido.

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

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.

The battery LED indicates information about the battery.

• if the LED is green, the battery is fully charged.
• if the LED is orange, the battery is charging
• if the LED is red, the battery charge is critically low
• if the LED is red and flashing, there is 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.

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

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.

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)

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.

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.

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

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

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.

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

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.

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 (Power-On Self Test)

Si la pantalla se prende y el logo de OLPC aparece, una gran parte de la maquina esta funcionando correctamente. Algunos reportes de progreso para pasos previos del comienzo requieren un acceso interno al sistema, usando puertos seriales especiales o adaptadores de hardware de "puerto 80"

La secuencia normal de booteo intenta cargar el SO lo mas rápido posible de los devs mas probables. Típicamente esto toma solo pocos segundos, entonces es difícil leer la información que sale en al pantalla.

Usted puede parar la secuencia de booteo rápido presionando una tecla de juego (cualquiera de los cuatro botones arriba del boton de prendido) justo despues de prender la potencia, presionándolo hasta que la pantalla se prenda. La pantalla dice: "Release the game key to continue", y OFW entonces empieza en modo interactivo. En modo interactivo OFW activa el teclado, prueba los USB dev (los cuales pueden incluir un teclado USB), y le da la oportunidad de interrumpir el conteo de 3 segundos de auto-booteo. Para interrumpirlo, tipee la tecla de escape (La tecla izquierda superior en el teclado principal, cuya leyenda es un X dentro de un circulo). (Si un teclado USB esta conectado, tipee en el en vez de en el teclado principal).

OFW muestra un "ok" prompt para indicar que esta listo para un comando.

La primera linea del texto del banner muestra la versión del hardware, cantidad de memoria y numero serie de la maquina. La segunda linea muestra la cadena de firma del sistema, que incluye la version de firmware. En el ejemplo de abajo, la version de firmware "Q2C11".

Luego muestra el numero de mensajes de progreso, como en este ejemplo:

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

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

ok

Para desarrollar diagnosticos de harware mas extensos, typee "test-all".

ok test-all

If the screen lights up and OLPC logo appears, a large part of the machine is functioning correctly. Progress reports for earlier startup steps require internal access to the system, using either special serial port or "port 80" hardware adapters.

The normal boot sequence tries to load the OS as fast as possible from the most-likely devices. It typically takes only a few seconds, so it is difficult to read the information that is displayed on the screen.

You can override the fast boot sequence by pressing a game key (any of the four buttons above the power button) right after turning on the power, holding it down until the screen lights up. The screen says: "Release the game key to continue", and OFW then starts in interactive mode. In interactive mode, OFW enables the keyboard, probes for USB devices (which might include a USB keyboard), and gives you the opportunity to interrupt the 3-second auto-boot countdown. To interrupt it, type the Escape key (the upper left key on the main keyboard, whose legend is an X inside a circle). (If a USB keyboard is attached, type on it instead of the main keyboard.)

OFW displays an "ok" prompt to indicate it is ready for a command.

The first line of banner text shows the hardware version, amount of memory and serial number of the machine. The second line shows the system signature string, which includes the firmware version. In the example below, the firmware version "Q2C11".

It then reports a number of progress messages, as in this example:

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

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

ok

To perform more extensive hardware diagnostics, type "test-all".

ok test-all

Open Firmware, Prompt de comandos

Las OFW FAQ resuelven las preguntas mas comunes acerca de como interactuar con el firmware OFW de OLPC.

Type "help" at the ok prompt for a list of the most common OFW commands. The OFW FAQ gives additional information about OFW.

Booting

OFW representa el progreso de booteo con una secuencia de iconos que muestran los dispositivos que el esta tratando de accesar.

OFW actualmente puede bootear de lso siguientes medios:

• NAND Flash interna (usando el sistema de archivos JFFS2)
• Tarjeta de memoria SD (usando sistemas de archivos EXT3 or FAT)
• USB mass storage (FLASH key o disk drive) (usando sistemas de archivos EXT3 or FAT)
• Ethernet USB (Cableado) (usando protocolos TFTP, NFS, o HTTP)
• Red Wireless (a través del modo infraestructura o mesh) Vea Trac 1431 para booteo wireless boot e instalación.

La secuencia normal de fast-boot - si usted no oprime una tecla de juego después de prender - es:

1. Tarjeta de Memoria SD
2. NAND flash interna
3. Ethernet USB (Cableada)
4. Red Wireless

El icono apropiado se muestra una vez que el dispositivo es escaneado.

Si usted presiona una tecla de juegoIf you do press a game key after power on (and do not type "Esc"), the boot sequence is:

1. SD memory card
2. USB mass storage (FLASH Key or disk drive)
3. Internal NAND flash
4. USB (wired) ethernet
5. Wireless network

The appropriate icon is displayed as the device is scanned.

When OFW succeeds in loading a boot file from a device, it displays the XO icon and executes that file. The icon just to the left of the XO shows which device succeeded.

OFW on OLPC does not load the operating system in one step. Instead, it first loads a file named "/boot/olpc.fth", containing an executable script written in the Open Firmware command language. The script typically sets up command line arguments for Linux and tells OFW to load the final operating system image from another file. For special circumstances, the script can do other things such as performing system updates or running manufacturing diagnostics.

In the normal case, you will see two occurrences of the pair of icons (device icon, XO icon). The first pair shows successful loading of the olpc.fth script, the second the final loading of the operating system.

The several-second delay that occurs during the first attempt to load from NAND FLASH is caused by the need to scan the entire NAND device in order to mount the JFFS2 filesystem. This is a well-know characteristic of JFFS2 that is not specific to the firmware.

OFW depicts the booting progress with a sequence of icons showing the devices that it is trying to access.

OFW can currently boot from the following media:

• Internal NAND Flash (using the JFFS2 file system)
• SD memory card (using EXT3 or FAT file systems)
• USB mass storage (FLASH key or disk drive) (using EXT3 or FAT file systems)
• USB (wired) ethernet (using TFTP, NFS, or HTTP protocols)
• Wireless network (via infrastructure mode or mesh) See Trac 1431 for wireless boot and installation.

The normal fast-boot sequence - if you do not press a game key after power on - is:

1. SD memory card
2. Internal NAND flash
3. USB (wired) ethernet
4. Wireless network

The appropriate icon is displayed as the device is scanned.

If you do press a game key after power on (and do not type "Esc"), the boot sequence is:

1. SD memory card
2. USB mass storage (FLASH Key or disk drive)
3. Internal NAND flash
4. USB (wired) ethernet
5. Wireless network

The appropriate icon is displayed as the device is scanned.

When OFW succeeds in loading a boot file from a device, it displays the XO icon and executes that file. The icon just to the left of the XO shows which device succeeded.

OFW on OLPC does not load the operating system in one step. Instead, it first loads a file named "/boot/olpc.fth", containing an executable script written in the Open Firmware command language. The script typically sets up command line arguments for Linux and tells OFW to load the final operating system image from another file. For special circumstances, the script can do other things such as performing system updates or running manufacturing diagnostics.

In the normal case, you will see two occurrences of the pair of icons (device icon, XO icon). The first pair shows successful loading of the olpc.fth script, the second the final loading of the operating system.

The several-second delay that occurs during the first attempt to load from NAND FLASH is caused by the need to scan the entire NAND device in order to mount the JFFS2 filesystem. This is a well-know characteristic of JFFS2 that is not specific to the firmware.

Device Tree

Hardware configuration information is exposed to Linux via the OFW device tree. This facility is also used on PPC and SPARC architectures. OLPC is working with others in the community using the device tree to try to come to a common implementation.

SPI Boot Flash Image

The firmware is stored in an SPI FLASH chip that is directly connected to the EC. The CPU accesses it via the EC, using the LPC bus between the CS5536 companion chip and the EC. The layout of the SPI FLASH is:

• 00000 .. 0ffff 64Kbytes of EC firmware
• 10000 .. dffff The OFW firmware system
  • Forth language core
  • Open Firmware extensions
  • Firmware device drivers
  • Filesystem and boot protocol handlers
  • Hardware diagnostics
  • Icons and audio for the boot screen
  • A copy of the Marvell wireless firmware to enable network boot and installation
• e0000 .. ef7ff Manufacturing Data: serial number, keyboard type, keys, etc.
• f0000 .. fffff Early startup code

The Marvell wireless firmware is a dropin module. Use .dropins to see the locations and sizes (compressed and uncompressed) of all such modules in OFW. The Marvell firmware is named usb8388.bin.

We hope to also include a cut down OFW image for recovery in the case of problems with the firmware. We do not yet know if there will be sufficient space for this backup copy of OFW. The build process collects these pieces and generates a single image for installation into the SPI flash.

System Management BIOS Interface

No Soportado

Not Supported

Seguridad

Physical Security

Cable locks can easily be arranged by use of the handles, which have two holes and a carrying handle.

Firmware and Software Security

The firmware and system security and anti-theft system is covered in the [http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt Bitfrost specification].

The SPI flash for the XO-1 is being epoxied to the motherboard, to make it very difficult to remove the boot flash intact. The boot flash contents with their keys are the basis for the Bitfrost security model, which has provisions both to protect the systems from viruses and worms, but also an anti-theft system, to protect the systems during transportation and later if desired.

Indexed register access via the embedded controller to internal registers must also be disabled. Trac 1432 has been entered to track this work.

Firmware Recovery

Space permitting, OLPC hopes to have a (subset) copy of OFW in left-over flash space to be used if somehow the original is corrupted. We do not yet know if there will be sufficient space for a recovery copy; if it exists, it is clear it will have to be a subset of the full OFW.

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.

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.

[http://dev.laptop.org/query?status=new&status=assigned&status=reopened&keywords=%7Epower&order=priority The Trac system] can give you a list of all open power related issues (by searching on the keyword "power").

Power Management States

User Visible States

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.

1. 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.
2. 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).
3. Sistema completamente operacional: En este estado, el sistema está disponible para su uso normal. En estados de procesador ACPI correspondería C0 y C1 (nota que C1 no es de utilidad en un GX, pero si ahorra energía en el LX).

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

Processor Power Management States

The Geode LX processor itself supports the following states (excerpt from the LX processor handbook):

• On (S0/C0): All internal and external clocks with respect to the AMD Geode LX processor are running and all functional blocks (CPU Core, Memory Controller, Display Controller, etc.) are actively generating cycles. This is equivalent to the ACPI specification’s “S0/C0” state.
• Active Idle (S0/C1): The CPU Core has been halted and all other functional blocks (including the Display Controller for refreshing the display) are actively generating cycles. This state is entered when a HLT instruction is executed by the CPU Core. From a user’s perspective, this state is indistinguishable from the On state and is equivalent to the ACPI specification’s “S0/C1” state.
• Sleep (S1): This is the lowest power state the AMD Geode LX processor can be in with voltage still applied to the device’s core and I/O supply pins. This is equivalent to the ACPI specification’s “S1” state. Given that the Geode LX does not drive the video output, and therefore a full DCON synchronization is required to get the display running, it is not clear that S1 will be useful for us (though it would allow computation to start faster than full suspend to RAM).

Botón de Prendido/Apagado

Este botón en OLPC sirves como botón de prendido/apagado.

The power button on OLPC serves as a power button.

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.

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.

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.

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

Subsistema de la Batería

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

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

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

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

• name - OLPC AC
• power
  • wakeup
• status - on-line or off-line
• status_cap capabilities on-line ?? (see bug #1409)
• subsystem link to ../../../../class/battery
• type - ac
• uevent

Note that Linux is in the process of revising its battery interface and that this interface will change to match that revision. We also have to convert the battery driver from indexed reads to recently defined EC commands. Trac #1430 will track this work.

Switches

There are a number of switches that are intended to help Linux know what the user is doing and take appropriate action; these may be connected to the system either via Geode GPIO's or via the EC. These are not hardwired in the firmware at all, but the following describes the expected behavior under Linux. These generate SCI events, and also generate keyboard scan codes, as documented in the EC specification or in XO-1 GPIO assignments. Power management policy is typically controlled by a user level daemon process (trac #31).

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 re enable, but we'll probably get most of the power benefit by disabling the GPU when not in use.

Ebook sense switch

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

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

Thermal Management

The CPU is protected by a fixed over-temperature cut-out at 85 degrees C. By using the ambient temperature reported by the battery system and the known temperature rise over ambient in the system enclosure, we hope to be able to warn users of possible overheating before running into this over temperature cut-out. The CPU can also be "throttled" when over temperature. There may be some ways of reducing internal heat generation, though experimentation of this will wait until a later date. Bug #1410 has been established to track this.

Note that different battery chemistries have limitations on the maximum temperature that they can be charged, and the system can report over temperature to programs via the /sys/class/battery/psu_0/status interface.

Video

Compression Buffer

The Geode has the capability of compressing the video data stream from RAM to the video processor. This could greatly reduce the memory bandwidth used, thereby saving power, and reducing memory contention, increasing system performance. The power versus RAM tradeoffs are not obvious, particularly with the DCON able to take over driving the flat panel, and this will need serious careful investigation with real power numbers and possibly real use data. Bug #1411 has been established to track work on determining if this feature is worthwhile for the XO-1.

Video Drivers

If the GPU is idle for some length of time, (say, several frame times), the data sheet makes clear it might be worth turning off the video drivers to the DCON and switch to DCON mode, to reduce power consumption. As always, we should measure the benefit: the cost here is the latency for the Geode to resume driving the display. We cannot presume the 37ma typical figure is relevant to the XO-1, as we are driving the DCON chip rather than a TFT panel directly.

Trac bug #1412 has been established to track this issue.

Video Input Port

Is not used, and should be disabled in the driver. See the GLD_MSR_PM Bit Descriptions in the Geode LX processor handbook.

Security Block

The security hardware block in the processor should be turned off whenever not in use.

Operating System Power Management

Linux is working very hard to remove "ticks"; the Linux kernel is now "tickless" and this is operational on OLPC, meaning that it no longer uses a periodic 250 hz timer clock interrupt to drive the scheduling of processes. The X0-1 has been observed at 40 wakeups 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: Independent of the CPU lower state, Linux may have many parts of the system powered down: e.g. audio, video output, etc. as described in detail below.

CPU and Support Chip

The CPU and 5536 automatically gate clocks when the system is idle on most hardware in both chips. Trac #1417 has been created to track verification of the configuration registers that control clock gating.

Given the progressively improving reduction in wakeups in Linux, use of the CPU's S1 is expected to be possible much of the time. We do not yet know how much power this may save. Trac #1416 has been created to track this measurement.

The additional possible savings under program control internal to the LX processor and 5536 are the GPU, video TFT panel drivers, and refresh rate.

The X Window System is in a good position to control the GPU: when the X server is idle, it can shut down the GPU, and drop the refresh rate (see below). Trac #1418 has been entered to track the GPU power management.

Device Power Down

Many external devices in the XO-1 can be powered down when not in use.

Screen Refresh Rate

Up to 100mw of power can be saved by controlling the refresh speed of the screen. This is very significant in Ebook mode.

Whenever the X server transitions from not drawing to drawing, the refresh rate should be increased to its normal 50hz at the next vertical retrace. Whenever the X server goes idle, the refresh rate should be dropped to a frame rate of (tbd) at the next vertical retrace. Trac #1419 has been established to track this behavior.

DCON mode

See above section about the video drivers.

Backlight

Given the back light can consume a significant portion of total power, particularly in Ebook mode, its management is important.

In Ebook mode (CPU suspended), there are registers in the DCON chip that allow for the backlight to be turned off automatically without processor intervention.

Recent Gnome versions have dbus messages defined to allow applications (such as DVD players) to temporarily disable the screen saver/DPMS functions of the system (e.g. the Totem video player). The XO-1 power manager and activities should follow these conventions.

The backlight is controlled by the X DPMS extension Trac #1429 has been established to track its implementation..

Audio

The Analog Devices AD1888 can disable all sections it is not using. As it can drive 5.1 audio output, it is important that we verify that all but the stereo channels are disabled.

It also has a "deep sleep" feature, in which it can be entirely disabled. If its device driver is closed, the AD1888 should be put into deep sleep, and restored when the device opened. Trac #1420 has been established to track this verification.

We also need to audit our audio applications that they close the audio device when idle. Trac #1421 has been established to track this verification.

USB

USB and power management are "iffy" at best. Our power manager will probably need to have an option to indicate whether STR (suspend to RAM) should be performed if USB devices are plugged in or not.

We also need to verify that we are properly disabling USB as we suspend and resume. Trac #1423 has been established to track this issue.

Keyboard/Touchpad

At this time, it does not appear that the keyboard and touchpad consume enough power (a few milliwatts) to be a significant battery drain in Ebook mode. This may need to be revisited when we transition to a new lower power wireless module. In BTest-2 and BTest-1, it was inadvertently on the wrong power rail that is not powered during suspend: this is fixed in B3.

SD

The SD slot and CaFE chip section should be powered down whenever the device is closed. Trac #1426 has been established to track verification of this behavior.

Camera

An LED is in series electrically with the camera (B3 and later) to guarantee that users will know if the camera is enabled. The camera and that segment of the CaFE' chip should be disabled when the device driver is closed. Trac 1424 has been established to track this issue.

Camera based activities should be audited that they close the device when idle or when not the current activity; eventual automation of this for standard activities in the tinderbox would be desirable if we can arrange it. Trac #1425 has been established to track this task.

Special Function Keys

One Touch Buttons

The Sugar Instructions documents the function of buttons in the Sugar user interface. Note that there are no built in function keys that are built into the BIOS firmware as there may be on a conventional PC: instead, all keys and buttons are left to the user interface software for interpretation. The sole exception to this rule is the power button: by holding the button down for four seconds you can force a hard reset of the XO-1 system.

The two sets of keys which directly affect power consumption are the "volume" control keys for the audio, and the back light control keys.

Sugar Activities

Sugar activities and their status, along with detailed GUI specifications are available.