El Desarrollo: Investigación y Descripción

Cómo ya comenté en otro hilo, existe una syscall llamada sys_sm_set_fan_policy() que permite controlar el ventilado. En concreto, descubrí que tiene al menos, 3 modos de operación que se resumen en:

sys_sm_set_fan_policy(0, 0, 0); // ventilador a toda potencia (velocidad 0xff)

sys_sm_set_fan_policy(0, 1, x) ; // ventilador controlado por el SYSCON (la x no parece usarse de forma directa o es ignorada por que se autoajuste, pero puede que influya cuando se reinicia/apaga el sistema)

sys_sm_set_fan_policy(0, 2, x) ; // ventilador controlado de forma manual.

Este último modo, el 2, es el que nos interesa a nosotros: la x se mueve en el rango de 0x33 (un valor menor se puede escribir, pero se corrige automáticamente en el SYSCON) a 0xFF, que sería la máxima potencia. Este modo tiene sus peligros, si no se maneja debidamente, ya que por ejemplo, si ajustamos 0x33, la velocidad es insuficiente y la temperatura alcanzará temperaturas muy peligrosas. Así que ojo con esto.

Según parece, cuando se reinicia el sistema, el SYSCON cambia a Modo 1 pero al apagarse la consola (piloto rojo) el Modo sigue siendo 2 pero el SYSCON fija el valor a 0x4D, cómo medida de seguridad, seguramente, pues con este valor la consola mantiene niveles aceptables de refrigeración.

De hecho el SYSCON utiliza valores mucho más bajos, usualmente. Que yo haya visto, empieza con el mínimo 0x33, luego sube a 0x40, 0x44, 0x48 y rara vez sube de ahí, por que al SYSCON manejarse en el rango de 70º a 75º en las FAT (al menos en la mía), le parece aceptable y prefiere menos ruido y mayor temperatura, cuando a nosotros nos puede interesar lo contrario.

Todo esto se puede ver mediante la syscall sys_sm_get_fan_policy() que cuenta con cinco parámetros que yo los he llamado así:



int sys_sm_get_fan_policy(u8 id, u8 *st, u8 *mode, u8 *speed, u8 *unknown)



- id es 0

- st y mode: reflejan el modo actual

- speed: como su nombre indica, refleja el valor x de velocidad que ajustamos nosotros o el SYSCON, dependiendo del modo.

- unknown: que yo haya visto (y vosotros mediante la presente aplicación) siempre es 0: ignoro si tiene un uso concreto.

Esta syscall la utilizo únicamente con fines informativos en la utilidad, pero el payload no hace uso de ella.

Una vez que podemos regular la velocidad del ventilador, lo siguiente, pero no menos importante, es conocer la temperatura que queremos regular.

Para ello, tenemos la syscall sys_game_get_temperature() que recibe como primer parámetro 0 si queremos medir la temperatura de la CPU y 1, para el RSX, mientras que el segundo parámetro es una variable que almacenará el valor de temperatura.

Por último, aunque de forma decorativa, hacemos uso de la syscall sys_set_leds() la cual nos permite poner los leds en el estado que queramos.

El problema de éstas syscalls es que requieren un tipo de permiso que nuestras aplicaciones y sobre todo los juegos, no suelen tener: algunas requieren flags PM cómo las relacionadas con el ventilador y otras permisos ROOT. Así que no queda más remedio que desactivar esos chequeos mediante "pokes" como éste:



// enables sys_game_get_temperature
lv2poke32(0x800000000000C694ULL, 0x38600000);



y esa es la razón por la que la utilidad está limitada a esos CFW: faltan los parches necesarios para los otros XD.

Bien, con todo lo dicho hasta ahora, se puede montar una aplicación que ajuste los modos a nuestro antojo, lo cual puede estar bien si solo se pretende ajustar el ventilador a una velocidad fija y ya está (al estilo de los que hacéis el mod del potenciómetro), pero si se pretende algo más "regulable" entonces la cosa se complica, por que requiere que nuestro código esté funcionando a nivel de sistema y eso requiere, por la vía elegida, hacer un payload y pinchar algunas syscalls.

El Payload

¿Y que debe de hacer el payload?. Pues en principio, debe tomar muestras de temperatura, ajustar la velocidad del ventilador, si procede y luego avisarnos de alguna manera (mediante LEDS) si la temperatura está dentro de unos parámetros y tal.

Así dicho suena muy fácil, pero ¿como hacemos todo esto y cómo averiguamos que syscalls pinchar?

Inicialmente, yo opté por pinchar la syscall usleep() pero esa opción no resultó ser buena al final y tuve que recurrir a otra, que es la que voy a describir a continuación (y prestadle atención, que es importante XD)

Antes de nada, conviene saber varias cosas o al menos, es lo que yo se (si alguien sabe otras cosas, que nos lo cuente)

- Las aplicaciones corren en modo usuario y cuando llamas a la syscalls, entras en modo supervisor, kernel, LV2 o llámalo como más te guste.

- Las aplicaciones usan memoria virtual, por lo que no podemos estar seguro si un determinado bloque de memoria está mapeado o lo que es peor, que permita escrituras.

- Cualquier intento de pasar memoria de LV2 cómo variable, retornará con error o simplemente... no retornará

- Dentro de LV2, sólo conocemos esto cuando una determinada syscall, utiliza variables entre sus parámetros. Lo cual tiene sus problemas, si las que necesitamos utilizar sólo reciben valores, pero ninguna dirección de memoria aprovechable. Por lo que necesitamos adquirir dicha información de forma indirecta y eso es un embrollo XD .

- Obviamente, si obtenemos un área de memoria que podamos "modificar" tenemos que asegurarnos que la modificación no afecta, o que de cara a la aplicación, lo datos no se hayan modificados (es decir: preservar los valores)

- Pues bien, nuestra syscall de medir la temperatura, requiere una ************ variable XD y eso plantea éstas dificultades.

- Por otro lado, dentro de LV2 es posible llamar a ciertas syscalls o mas concretamente, a las funciones que manejan dichas syscalls, pero hay otras que no se puede (por ejemplo, las de acceso a fichero bloquean el sistema, si por ejemplo, haces un open y luego un read, sin salir a modo usuario)

Con todos estos problemas, encima necesitamos una syscall que se llame con regularidad para poder hacer nuestras lecturas/ajustes y tuve que descartar usleep().

La "salvación" vino en forma de eventos: los eventos del sistema nos permiten, cómo su nombre indica, recibir sucesos dentro del sistema, recibiendo una serie de datos.

La syscall sysEventQueueReceive() es la encargada de recibirlos y además, nos proporciona una variable que podemos utilizar para la medida de temperatura. La syscall en su último parámetro especifica el tiempo en microsegundos durante el cual esperará un evento (0 indica infinito).

Una cosa a tener en cuenta es que ésta syscall recibe TODOS los eventos que se producen vía aplicaciones y es bien posible que mientras estemos procesando uno, se reciba OTRO evento, si nos demoramos en nuestras tareas, por lo que conviene proteger contra ellos.

De hecho, la toma de temperatura requiere entre 7ms y 20ms y volví a encontrarme con problemas, debido a que se sobrepasaba la velocidad de respuesta. en un determinado momento, produciéndose un bloqueo.

Así que cambié de estrategia e intenté averiguar donde se generaban los eventos para que si se debía producir demora, fuese allí y no en el receptor. A todo esto, tengo que decir que ni siquiera conozco de primera mano QUIEN, DONDE Y PORQUE genera los eventos: simplemente, se que algo genera eventos en cadencia suficiente para permitirme hacer mis lecturas y que la naturaleza de esos eventos se producen en el XMB, en los juegos, en el emulador de PSX y en el de PSP. En PS2, al menos en la retrocompatibilidad por hardware de mi PS2 se que no, por que el LV2 que conocemos desaparece y con ello, mi payload

Existen varias formas de producir eventos, pero la más accesible, son los EventPort.

Pinchándolo pude ver que efectivamente, es el origen de las llamadas. La syscall sysEventPortSend() envía en los registros la siguiente información



sysEventPortSend(sys_event_port_t portId,u64 data0,u64 data1,u64 data2)



Cómo vemos, ninguna variable, solo datos, con lo cual, seguimos necesitando el concurso de sysEventQueueReceive() para recibir una variable que podamos modificar.

El problema es que la modificación la debemos hacer en el llamante y no en el llamado, que es el que recibe la variable del programa. Es decir, que necesitamos la gallina para poner el huevo, pero no hay gallina hasta que nazca del huevo [sonrisa]

Para saltar ese obstáculo, recurrí al PID: si conocemos el process ID, podemos comparar, si el envío y la recepción están en el mismo proceso y podemos por tanto, pasar la gallina al huevo, desde la propia gallina [+risas] . O para no liar el asunto, pasar la variable de sysEventQueueReceive() para que la usen nuestros procedimientos en sysEventPortSend() (tambien es necesario por que en principio, no sabemos si el EventPort tendía cómo destinatario ESE QueueReceive, debido a que se relaciona de forma indirecta con el evento!)

Perfecto, hecho eso, mediante unas comprobaciones de seguridad de los respectivos PIDs, podemos asegurar que "mem_app" (en el payload) contiene una dirección de memoria para escritura que podemos usar.

Una vez que cerramos el circuito y vemos que funciona, nos interesa intentar discriminar para encontrar los eventos que nos resultan útiles y descartas otros que no lo son y solo pueden acarrear problemas. Haciendo varias pruebas, resulta que se que la recepción del evento no es bloqueable (o sea, que tiene un tiempo límite) y que el evento que se genera y recibe, útil, tiene todos los datos a 0 (por lo general, un evento contiene una serie de datos con información útil y necesaria para los programas. Por ejemplo, los eventos relacionados con los dispositivos, reciben el tipo de dispositivo en data2).

Ahora necesitamos hacer dos cosas: si nuestros eventos tienen una caducidad y una capacidad de respuesta corta, por un lado, necesitamos una base de tiempo para saber cada cuanto tiempo leer la temperatura, etc, sin lastrar al sistema y también necesitamos dividir las tareas a realizar para que cumplan su cometido sin lastrar al sistema.

Después de éxitos y penurias, al final, de base de tiempo utilizo un registro del procesador (nota: suponía que tenía que haber uno con ese cometido, pero ni idea de como se usaba en CELL [+risas] ) que cuenta los ticks desde el arranque del sistema (con eso podemos conocer cuanto tiempo lleva la consola encendida XD. De hecho, en la utilidad muestro esa información como "PS3 Start Time")

La base de tiempo que utiliza, ni idea [+risas] . Lo que hice al final, es hacer un par de bucles combinados con el reloj de tiempo real para primero sincronizar y luego tomar una lectura durante 60 segundos, con la cual obtener los ticks por segundo que se generan. La cifra: 0x4c1a6bd o 79799997 como gustéis. Tampoco se necesita una precisión del copón, solo algo que que cuente el tiempo de forma razonable [+risas]

Si alguien tiene curiosidad en saber como se obtiene los ticks, ésta es la función:

Código: Seleccionar todostatic inline u64 get_ticks(void)
{
u64 ticks;
asm volatile("mftb %0" : "=r" (ticks));
return ticks;
}


Se supone que en un punto puede dar cero y que habría que entrar en bucle hasta obtener una lectura válida. De hecho, en el payload se hace así:



get_ticks:
mftb %r4 // get tick counter 1s = 79799997 ticks aprox
cmpldi %r4, 0
beq get_ticks
srdi %r4, %r4, 12 // ticks/4096 0 => 1s 0x4C1A ticks aprox




En este caso, utilizo un desplazamiento de 12 bits desde la derecha para obtener un número de ticks con el que comparar de forma "razonable" desde ensamblador

Al final, la rutina trabaja así:

- Se dividen las tareas a realizar de forma que primero, se hace una lectura de temperatura que se va alternando entre CPU y RSX. Esta tarea requiere mucho tiempo en términos de eventos por lo que es importante dividirla

- Cómo segunda tarea está mirar si se necesita corregir la temperatura y ajustar los leds (cosa que la mayor parte del tiempo, no se necesita)

- El temporizador se ajusta para que responda cada 1,5 segundos. Es decir, el proceso de medir la temperatura de la CPU y hacer ajustes, lleva 3 segundo y otros tantos para el RSX, por lo que el total, se de 6 segundos, que es una buena cifra.

- Esta temporización puede ser saltada si el tiempo expiró pero no se pudo producir lectura de temperatura por que no coinciden los PIDS o mem_app está a cero.

- Los PIDs se suelen ajustar a cero en ciertos momentos después de su uso para prevenir problemas (recordad que hablamos de syscalls que se usan por TODO el sistema y tenemos casos donde huevo da lugar a gallina y gallina da lugar a huevo y a veces, la gallina muere y el huevo cuando nace, se equivoca de madre y la lía [+risas] )

- Un detalle MUY importante que no he mencionado, es que para evitar una serie de problemas, me veo obligado a mandar ANTES el evento (o sea, dejar pasar la syscall) que las acciones que estoy realizando por lo que no puedo estar seguro si el sistema, que recordemos que soporta dos hilos por hardware y tal, pueda estar recepcionando el evento mientras uno se piensa que hasta que no salga de la syscall no ocurre nada. Este tipo de pensamientos "monotarea" en el que solemos incurrir, puede hacer que nos roben la cartera y ni siquiera nos hayamos enterado. Por ello, intento cubrirme con el flag "in_use" tambien de forma que se ignoren las llamadas que puedan ser problemáticas (de hecho, ya ignoramos muchas por el uso del contador de ticks)

A grandes líneas, este es el funcionamiento, los problemas que uno se encuentra y como resolverlos sobre la marcha: no tiene por qué ser el enfoque más correcto o incorrecto, si no que simplemente, es cómo yo he resuelto el problema y curiosamente, no en base a lo que sabía, si no en base a lo que no se y voy descubriendo por mi cuenta.

Uso Del Payload

Una característica del payload es que permite ser ubicado en cualquier parte del sistema: se ha elegido la dirección 0xF70 de LV2 (recordad que hay que añadir un 0x80....000 para formar la dirección de 64 bits) pero podría alojarse en cualquier otra parte (usando el método write_htab() que se incluye en los fuente Iris Manager, podemos habilitar la ejecución de las partes prohibidas de LV2) y es compatible con cualquier CFW teóricamente.

Como ya he comentado antes, los parches para habilitar las syscalls que requieren permisos, son la razón por la que la que esto se presenta para CFW 4.31 y 4.40 .

De hecho, solo he testeado en 4.40 por lo que espero no haber metido la pata con los partes para 4.31 XD

En la aplicación, la función load_ps3_controlfan_payload() carga el payload uniendo las diferentes syscalls (el loop y los sleeps son para "garantizar" que el payload se carga bien)

El inicio del payload contiene la ID 'PFAN' (0x5046414E) en los primeros 4 bytes. Los 4 bytes siguientes, contienen en el offset dentro del payload (bajo este punto de vista, el payload comienza en 0) donde encontrar los datos fan_control.

Todos los datos que menciono a continuación son de 32 bits:

En fan_control - 8 bytes podemos cambiar el comparador actual de velocidad (esto solo es útil si deshabilitas el payload y lo quieres volver a habilitar, provocando que se actualice).

En fan_control - 4 podemos deshabilitar o habilitar el payload: 0- >deshabilita, 1- habilita sin leds y 2 - con leds

En fan_control + 0 podemos ajustar la velocidad que se fijará si se llama a la syscall sys_sm_shutdown() para algo que no sea un Reset o Apagado normal (por ejemplo, cuando se activa el emulador de PS2 en la consolas retrocompatibles, al menos). Se supone que con 0x5F la velocidad es suficiente (de hecho, alta) para evitar problemas, pero claro, todo dependerá de la temperatura ambiente y de lo que se caliente vuestra PS3 [+risas]

Dicha syscall es intervenida para que en caso contrario, fije el Modo 1, con la idea de dotaros de algo de protección adicional si no se vuelve a activar la aplicación (si en ese caso, está en Modo 2, carecerá de regulación y dependerá de lo suficiente que sea la velocidad 0x4D)

A partir de fan_control + 4 (inclusive) está la tabla de velocidades que se relacionan con las temperaturas de temp_control0 a temp_control4

Las temperaturas (todas en ºC) temp_control0 a temp_control1 conforman un abanico en el que se tiene en cuenta si la temperatura partía por debajo de temp_control0 y va subiendo o se está bajando desde temp_control1 (si se está calentando, la velocidad es menor que si está viendo la necesidad de enfriar)

temp_control2 supone un cambio de marcha, mientras que temp_control3 supone el punto de inflexión. En el caso por defecto de 70º el led parpadeará en amarillo/verde si la temperatura es mayor o igual de 70º

temp_control4 representa la temperatura de la alarma: en ese caso, el led parpadeará en modo "discoteca" (amarillo, rojo y verde) y la velocidad se ha ajustado en 0xA0, que es ruidos y enfría bastante [+risas]

Un detalle importante cada 11-12 segundos o así, el led se ilumina en verde durante 1,5 segundos (excepto si estamos en temperatura de emergencia). Es la forma que tiene el payload de deciros que está trabajando (sobre todo se nota si está el LED en amarillo fijo)

Y creo que no me olvido de nada importante en este apartado XD (el fuente del payload ya tiene bastantes comentarios)

La Aplicación Control Fan

La aplicación es bastante sencilla (si alguien la quiere compilar, puede usar éste entorno de compilación hilo_psdk3v2-windows-ps3-sdk-con-psl1ght-v2-tiny3d-y-ps3-soundilb_1867760) y muestra en forma de texto toda la información.

Nada más arrancar se fija el modo "#Payload" que es de lo que hemos estado hablando.

La información en pantalla es la siguiente:

Temperatura de la CPU/ temperatura de RSX y Tiempo transcurrido desde el encendido de PS3

Las temperaturas parpedearán en amarillo cuando alcancen los 70 grados y en rojo cuando alcancen los 75 grados

sys_sm_get_fan_policy aquí indica el modo y la velocidad que tiene fijado el SYSCON

Current Mode Indica el modo actual y la velocidad del ventilador fijada (modo 2 y payload)

Los modos vienen resumidos abajo. En el Modo 2, con UP/ARRIBA subimos la velocidad y con DOWN/ABAJO la bajamos. Recordad que el modo 2 es un modo con velocidad fija y no varía en función de la temperatura. El Modo 1 es el normal del sistema.

Para cambiar de Modo se usa SQUARE/CUADRADO e irá cambiando en sentido ascendente (eso permite por ejemplo, fijar una velocidad muy baja en Modo 2 para que la consola se caliente y luego activar el Modo Payload para ver como responde XD)

Con el botón TRIANGULO se sale de la aplicación. Recomiendo usar éste botón para salir y no desde PS

Protecciones de la aplicación

- Desde el Modo Payload, protección anti-shutdown, para que ajuste el modo de protección

- Si se apaga la consola en Modo 2, se conservará al encenderlo, ojo a esto, aunque en principio, el SYSCON fija una velocidad supuestamente apropiada.

- El SYSCON corrige los valores fijados por debajo de 0x33. Aún así, se ha limitado el Modo 2 a 0x30 cómo mínimo y cuando la velocidad baja de 0x4D Current Mode parpadeará en azul

- Si se sale de la aplicación en Modo 2, la velocidad mínima se ajustará a 0x5f, independientemente de la que hubiera sido fijada (a modo de seguridad y por que el Modo 2, no debiera ser fijado, a menos que lo que se pretenda es que el ventilador trabaje a velocidad alta y en ese caso, ese mínimo es correcto :p )

- Independientemente del modo, si la temperatura es mayor o igual a 80 grados, se activará el Modo 0 hasta que la temperatura baje por debajo de los 60 grados (momento en que conectará el Modo Payload) o vosotros mismos cambiéis de modo cuando la temperatura baje de ese límite.

Cómo veis la aplicación tiene sistema de seguridad para evitar que dejéis frita la consola, independientemente de las protecciones que pueda tener el sistema. Ya me contaréis que os parece el tema (seguramente acabe integrándolo en Iris Manager, pero por el momento, estamos en fase de pruebas)