[UTILIDAD] Control Fan Utility v1.7 (CFW 3.41, 3.55, 4.21, 4.30, 4.31, 4.40 y 4.41)

1, 2, 3, 4, 518
Antes de nada, abro éste hilo aquí por tratarse de una modificación de firmware muy concreta (que trabaja sobre CFW CEX 3.41, 3.55, 4.21, 4.30, 4.31 y 4.40), destinada principalmente a trabajar bajo el entorno de los juegos. No se trata de un simple ajuste de la velocidad del ventilador, si no de un payload que cumple su cometido regulando la velocidad del ventilador en función de las temperaturas del sistema, para tratar de evitar un sobrecalentamiento excesivo en lo posible. Por esa razón lo abro aquí y no en Scene, donde también podría tener cabida..

El hilo tendrá dos cometidos: por un lado, el exponer el desarrollo, investigación y los aportes propios o que hagáis vosotros y por otro lado, la parte práctica para quienes solo quieren usar la utilidad.

Empecemos pues por la parte del desarrollo (si a alguien no le interesa, que salte a "La Aaplicación Control Fan")

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 puta 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:

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

Descarga

http://mods.elotrolado.net/~hermes/ps3/ ... y_v1.7.rar

System Manager para CFW Miralatijera 4.40 y core 3.2.0 +

Mas info en:

hilo_update3-cfw-4-40-miralatijera-100-core-3-2-0-integrado-qaflag_1880798

v1.1:

viewtopic.php?p=1732436068

Lo nuevo en SM v1.1:

- Se han hecho unas correcciones de tiempo para evitar demoras excesivas a la hora de cambiar el modo de trabajo para el Fan y el USB Wakeup.

- Se han reducido las prioridades al mínimo para intentar que el System Manager interrumpa lo menos posible a otros procesos en marcha y solo utilice sus tiempos muertos.

- Se ha añadido la posibilidad de cambiar a prioridad y el tiempo de actualización de main() (esto sirve para tener la posibilidad de toquetear cosas, si resulta necesario, pero en principio, debería valer como está)

Descarga:

http://mods.elotrolado.net/~hermes/ps3/ ... 0_v1.1.rar

Instalación:

- Si ya tenías la versión previa, simplemente, copia sm.self en raíz del dispositivo USB, ponlo en USB000 (el mas cercano al lector) y reinicia.

- Si no tienes el core 3.2.0 entonces ve aquí:
hilo_update3-cfw-4-40-miralatijera-100-core-3-2-0-integrado-qaflag_1880798

y siguiendo las instrucciones, reemplaza el viejo sm.self por el nuevo

Desinstalación:

- Copia la carpeta "flags" que hay dentro del RAR al dispositivo y reinicia con éste enchufado en USB000

USB Wakeup:

- Crea un fichero de nombre "nosleep" (sin extensión, que ya os veo venir XD) en raíz del dispositivo que queráis que cada cierto tiempo, se acceda en escritura para mantenerlo alerta
gracias tio joder si que hay que leer :) :)
Como Siempre
IMPRESIONANTE

Saludos Maestro
ssecarlos está baneado por "Crearse un clon para saltarse un baneo"
Estwald chapó! [tadoramo] [tadoramo]
Enhorabuena por el currazo!
A probarlo [beer]

Salu2!
Bueno, he corregido alguna cosa y sigue habiendo alguna letra comida y cosas así, pero ya lo tocaré en otro momento XD

El texto es largo, pero la parte de la aplicación en si, es a partir de
La Aplicación Control Fan


De todas formas, si os interesa el tema de scene o una explicación mas extensa de cómo funciona el "mecanismo", os resultará interesante el resto.

Espero que al final, el fruto merezca la pena: a mi por lo menos, me está resultando muy útil, pero cómo solo yo la he probado, pues mi punto de vista es limitado en ese sentido.

Por lo general, el mayor problema de todos es la lectura de temperatura: requiere de una variable que "cuesta" conseguir y se toma un tiempo considerable y al menos, la primera vez que se llama, se tira sus buenos 20 ms de tiempo y puede que de vez en cuando necesite tomarse ese tiempo por que vete tu a saber que motivo..
Ya te vi comentarlo hace una semana pero jamas pensé que lo tendrías tan rápido :O
Solo puedo decir que me has alegrado el día. UN TRABAJO IMPRESIONANTE [tadoramo] [tadoramo] [tadoramo] [tadoramo]

Saludos
enhorabuena!!! ésto ayudará a alargar muchisimo la vida de nuestras ps3. Muchas gracias!!
Con CFW Rebug 4.41 da pantallazo negro, ya sé que solo es para CFW 4.31 y 4.40 CEX pero lo tenia que intentar! Refirmar el eboot para solucionar esto?
Estoy probandolo y me funciona de lujo,el unico pero que le veo (no se si lo has avisado o no) es que al volver a entrar por segunda vez al pkg en cuestion,pega blackscreen y se te queda colgada la consola de manera que tienes k apagarla (al menos en mi slim),no se si crashea al intentar leer la syscall o que...
nabunocosor escribió:Con CFW Rebug 4.41 da pantallazo negro, ya sé que solo es para CFW 4.31 y 4.40 CEX pero lo tenia que intentar! Refirmar el eboot para solucionar esto?


¿da pantallazo negro?. Eso es un error mío XD

Lo que debería aparecer es un mensaje, pero con tantos cambios, olvidé cambiar una comparación: ahora mismo lo corrijo

kikeadsl escribió:Estoy probandolo y me funciona de lujo,el unico pero que le veo (no se si lo has avisado o no) es que al volver a entrar por segunda vez al pkg en cuestion,pega blackscreen y se te queda colgada la consola de manera que tienes k apagarla (al menos en mi slim),no se si crashea al intentar leer la syscall o que...


¿Usas CFW 4.31?. EN 4.40 puedes entrar todo lo que quieras, por eso lo pregunto XD

EDIT: He actualizado la utilidad con la comparación correcta. Ahora, si no detecta los payloads, retornará con un mensaje de error (en teoría [+risas] )
Estoy en 4.40 MLT,Estwald por eso se me hace extraño...es que pega un blackscreen que hasta me corta la señal de video (me sale en mensaje en la tele de "sin señal") y la ps3 sigue encendida xDDD
kikeadsl escribió:Estoy en 4.40 MLT,Estwald por eso se me hace extraño...es que pega un blackscreen que hasta me corta la señal de video (me sale en mensaje en la tele de "sin señal") y la ps3 sigue encendida xDDD


Pues si que es raro: yo tengo una FAT, tal vez cambie algo en el comportamiento del SYSCON o el propio sistema, use algo similar o alguna cosa raruna que yo no puedo ver en mi FAT XD (no se que aplicaciones tendrán PM, pero si se que he detectado cadenas relacionadas con el ventilador haciendo busquedas en memoria), vete a saber [+risas]

De todas formas, si con una te funciona bien y ves que regula, pues no hace falta entrar más XDDDD
Leído entero y me quito el sombrero.

Gran trabajo, esta tarde lo pruebo sin faltas y te comento esta noche.

Saludos.

Yo estoy en 4.40 MLT.

Saludos y gran trabajo.

Edit: Kikeadsl, el mismo "bug" de cuando conecto la Vita xDDD
Estwald escribió:
kikeadsl escribió:Estoy en 4.40 MLT,Estwald por eso se me hace extraño...es que pega un blackscreen que hasta me corta la señal de video (me sale en mensaje en la tele de "sin señal") y la ps3 sigue encendida xDDD


Pues si que es raro: yo tengo una FAT, tal vez cambie algo en el comportamiento del SYSCON o el propio sistema, use algo similar (no se que aplicaciones tendrán PM, pero si se que he detectado cadenas relacionadas con el ventilador haciendo busquedas en memoria), vete a saber [+risas]

De todas formas, si con una te funciona bien y ves que regula, pues no hace falta entrar más XDDDD


Nada,a mi mientras me rule bien a la primera,me doy con un canto en los dientes xD.De todas formas kizas alguien k tenga otra slim lo pueda confirmar,para saber que no soy un caso aislado y poner asi un aviso para navengantes ;)
Si podéis, hacer pruebas cambiando a Modo 2, bajando la velocidad y dejando que la temperatura suba, para ver los ajustes automáticos XD .

Como cada PS3 es de su padre y de su madre, tal vez en alguna sean velocidades exageradas: por ejemplo, la mía ha estado 6 horas "currando" y está ahora en 61º CPU y 55º RSX con la velocidad más baja... pero se nota que estamos unos grados mas abajo con respecto a las pruebas del otro día.

El tema es que con las explicaciones, no deberíais tener problemas para ajustar los perfiles vosotros (seguramente, no tengáis necesidad de hacerlo, pero cuidado con no cagarla XD)

Por otro lado, con un dump de LV2 4.40 por ejemplo, es fácil ajustar los parches a otros firmwares (cosa que si hacéis otros, mejor, que yo estoy hasta los cojones y me vuelvo al Batman, que es parte del motivo de haberme retrasado en la publicación: la excusa para jugar durante horas, es que hay que probarlo [+risas] )

Saludos
Estwald escribió:Por otro lado, con un dump de LV2 4.40 por ejemplo, es fácil ajustar los parches a otros firmwares (cosa que si hacéis otros, mejor, que yo estoy hasta los cojones y me vuelvo al Batman, que es parte del motivo de haberme retrasado en la publicación: la excusa para jugar durante horas, es que hay que probarlo [+risas] )


Me alegra que a estas alturas sigas encontrando esa motivación para disfrutar de un videojuego :) , en mi caso, cada vez que miro la estantería me encuentro como se me van acumulando los originales que no "ven" el momento adecuado para salir de su plástico [carcajad]

Muchas gracias crack!, descansa y "revienta" ese Batman [beer]
ssecarlos está baneado por "Crearse un clon para saltarse un baneo"
va de lujo gracias!!
pero una cosa no me queda clara... se puede poner el ventilador en automatico?
es para que lo haga ella todo sola XD y si no se pudiera en que velocidad me aconsejais que la deje? me gusta mucho la 2

y otra cosa cuando activo el pkg el led se pone en verde :-?
estoy en MLT 4.40 con el core puesto y el led amarillo

a mi tambien me pega pantallazo negro al intentar entrar por segunda vez
salu2 ;)
Primeramente agradecer esta herramienta.
Voy a leer y luego probare el programa.

Al rato posteo los resultados.
Gran trabajo amigo, como siempre un crack ;)

Un saludo.
Un trabajo impresionante, muchísimas gracias por el curro desinteresado, ojala se porte para que funcione también en 4.30(que es en la que estoy yo) y en 3.55 que la usa mucha gente.
ssecarlos escribió:va de lujo gracias!!
pero una cosa no me queda clara... como lo dejo en automatico? es el 2?
es para que lo haga ella todo sola XD

y otra cosa cuando activo el pkg el led se pone en verde :-?
estoy en MLT 4.40 con el core puesto y el led amarillo

a mi tambien me pega pantallazo negro al intentar entrar por segunda vez
salu2 ;)



En automatico estás nada mas entrar XD. Si te fijas, pone Mode #Payload, pues ese es.

Cuando activas la aplicación se pone el led en verde en efecto , pero luego cambia a amarillo cuando entra el payload y a verde otra vez, cuando se desactiva.


Sobre lo que se cuelga la segunda vez, acabo de subir la versión 0.2 que hace las cosas un poco distinto, por si es un problema de timming al desconectar/conectar el payload: probadlo y me contáis ;) (eso si, ésta vez, si reentras no cambia a modo automático directamente y hay que hacer una corrección en el mensaje, pero eso es para que probeis)

PD: vosotros probadlo bien y si de verdad, interesa que se porte a otros CFW, es solo cuestión de encontrar los parches necesarios y esto es más la "pereza" de tener que hacerlo yo que otra cosa. Así que si alguien me puede hace ese pequeño favor... [+risas]

Si os mola el asunto y veis que os funciona bien, se incluye en Iris Manager y así ahorramos pasos ;)
Saludos
Increible trabajo compañero, la probare esta noche, cuando me digne a encenderla para jugar tras casi 1 semana sin jugar a nada, jeje. Yo uso el Rogero 4.40 v1.03, y es una Slim 2504B de 120GB's. Haber si poniendo todos nuestra versión de PS3, y CFW, podemos centrar los pasos, para que no tenga tanto lio el pedazor de fistro pecador de la pradera, que alegrías nos da, aupa Estwald XD

Descargada la v2, para hacer la prueba, la v1, ni la pille, jeje [jaja]
He vuelto a subir la v0.2 para corregir el pequeño error de la informacion de inicio y una puta coma en el .pkg XD

La verdad es que con tantas modificaciones que he tenido que hacer (sobre todo al payload, que es donde tengo que centrar toda la atención) y todas las pruebas, hay algunos flecos que estaban sin pulir y ahora pueden ser foco de problemas en consolas pijoteras, por lo que lo he corregido por si las moscas cojoneras XD

PD: Por cierto, ¿habeis visto que ruido hace el ventilador a tope?. Pues como yo soy medio sordo, si me quito los audífonos, no lo oigo [+risas]
OK, Saludos Estwald.

He puesto el Modo 2 hasta que a alcanzado la CPU 77 grados y el RSX 75 (Todo en rojo xDD)

Luego he puesto el modo del Payload y ha aumentando la velocidad, luego cuando a ido bajando también lo ha echo la velovidad del ventilador hasta quedarse a 60 grados.

De todas maneras haber si este fin de semana le meno mato al source para que se quede a 45 grados XD

Saludos y gran trabajo.

Edit: El ruido que hace a tope es como de 50-70 db
Impresionante el curro, jeje me he quedao flipao cuando he puesto el modo 0, eso parecia un avion no una ps3 jeje
estoy en cfw 4.40 mlt con una slim 2004 y respecto que cuando la segunda vez que entras en el programa se que queda sin señal, a mi me ha pasado tambien, pero el programa sigue funcionando ya que le doy a cuadrado y hace el cambio de mode y despues de hacer eso me ha vuelto a salir la pantalla del programa eso si ha tardado con unos 20-30 seg en dar video, no se porque.

Muchas gracias por esta herramienta, seria interesante tenerla en segundo plano mientras se juega o utilizamos otras herramientas.

como siempre, gran currazo el tuyo estwald, que seria de la ps3 sin ti....
Angel sefirot escribió:OK, Saludos Estwald.

He puesto el Modo 2 hasta que a alcanzado la CPU 77 grados y el RSX 75 (Todo en rojo xDD)

Luego he puesto el modo del Payload y ha aumentando la velocidad, luego cuando a ido bajando también lo ha echo la velovidad del ventilador hasta quedarse a 60 grados.

De todas maneras haber si este fin de semana le meno mato al source para que se quede a 45 grados XD

Saludos y gran trabajo.


¿45 grados? Dios.. te va a sonar como un helicóptero XD

La forma de probarlo es fácil: pon el modo 2 a una velocidad y espera unos minutos. Si te fijas, la temperatura de 61 grados es justo el corte de 0x4D y se mantiene bien ahí, excepto cuando la temperatura ambiente sube o las exigencias, lo hacen (sobre todo el que sube es el RSX, que tiene mas margen)

De todas, formas, lo peligroso de verdad es irse por encima de los 75 grados: lo otro, es ver "paranoias" de que si el estaño malo y tal pascual, pero lo cierto es que no te evitará que una mala soldadura salte, si tiene que saltar.

Un mod interesante que podría hacer nuestro amigo Miralatijera es incluir un flag que suba el payload y lo habilite desde el arranque o si está un poco vago, que al menos ajuste el modo manual a una velocidad razonable hasta que nosotros podamos hacer el ajuste pertinente XD
ssecarlos está baneado por "Crearse un clon para saltarse un baneo"
me sigue dando pantallazo negro en la v2 cuando entro por segunda vez
A mi también me da pantallazo negro pero puedo seguir haciendo ajustes :s
Angel sefirot escribió:A mi también me da pantallazo negro pero puedo seguir haciendo ajustes :s


¿Con la v0.2?, bueno con la 0.3 ya (dicen que no hay dos sin tres XD : ahora si que recupera bien el modo previo, que me dejaba el payload desajustado)

A ver si va a ser un tema de video... XD
He descomprimida la 0.3 y el pkg pone 0.2, ¿Es de toda maneras la 0.3?

Saludos.
Angel sefirot escribió:He descomprimida la 0.3 y el pkg pone 0.2, ¿Es de toda maneras la 0.3?

Saludos.


No, es la 0.2 [+risas] . Descargalo otra vez, please XD (menos mal que me ha dado por comprobarlo antes de que tu dijeras nada:; es lo que pasa cuando estas en 50 cosas a la vez y surge un fallo tonto que te obliga a tocarlo todo: que te dejas cabos sueltos XD )
Sigue estando la pantalla negra xDD Aunque puedo ir cambiando los ajustes.

¿Puede ser problema mio y no de la aplicación?

La mía es SLIM.

Saludos.
ssecarlos está baneado por "Crearse un clon para saltarse un baneo"
Angel sefirot escribió:Sigue estando la pantalla negra xDD Aunque puedo ir cambiando los ajustes.

¿Puede ser problema mio y no de la aplicación?

La mía es SLIM.

Saludos.


a mi me pasa igual y tb es slim
Angel sefirot escribió:Sigue estando la pantalla negra xDD Aunque puedo ir cambiando los ajustes.

¿Puede ser problema mio y no de la aplicación?

La mía es SLIM.

Saludos.


Que raro, XDD

Mas parece un problema con el video que otra cosa XD

No creo que sea un problema tuyo por que ya van varios con SLIM que se quejan de lo mismo y si la aplicación responde al pad (y os permite salir, con triangulo), algo de eso debe de haber (ahora se evitan hacer ajustes al payload y si fuera de ahím, la pantalla negra sería de muerte absoluta)

Si fuera de la aplicación todo va correctamente, entonces no es ningún problema importante (dentro de poco con los datos que aporteis, irá de cabeza a Iris Manager)
Hola Estwald yo tengo otro problema y es que teniendo activado el modo payload empece a jugar al black ops 2 y transcurridos unos 5 minutos el juego se quedo pillado y tuve que reiniciar la ps3 pero pense que habría sido algo puntual.

Sin embargo ahora me disponía a ver un video en la ps3 con el showtime y la sorpresa es que me ha pasado lo mismo(se quedo congelada y tuve que reiniciar) y ademas se escuchan micro cortes de sonido.

La temperatura esta normal ( unos 62 grados) y si no lanzo tu pkg funciona todo perfectamente sin congelaciones.

Por si te sirve de ayuda tengo una ps3 slim CECH-2504A con firmware 4.40 MT con spoof a 4.41 y he probado con la 0.3 pero esto que comento también me pasaba con la primera versión que publicaste
Muchas gracias Estwald, mis ps3 de 60gb y yo te lo agradecemos mucho, haver si duran mas. [beer]

PD: el modo avion refrigera mas que mi congelador cpu 45 rsx 35 [flipa]
me funciona de lujo, lo ideal sería dejar los valores marcados en la flash para no tener que entrar en el programa cada vez que se encienda la ps3. Muchisimas gracias!
Muchas gracias Maestro, aparte de compartir tu trabajo con nosotros, te molestas en escribirnos un megapost explicandonos su funcionamiento que por cierto me lo voy a tener que leer varias veces para poder asimilar tanta informacion.

Eres un crack... :)

un saludo
Eswald, una pregunta (no es de la aplicación). A mi normalmente se me queda a 60-62 grados, con ruido del ventilador audible pero no molesto. Hasta ahí bien. Lo que pasa es que a veces (muchas veces), el ventilador se me queda en la anterior velocidad y la temperatura sube hasta 66-67º. Luego apago la consola, inmediatamente la enciendo otra vez y ahí si, sube una velocidad más, pero ya le cuesta bajar la temperatura.

Mi pregunta es si se sabe por qué a veces al pasar de 60º la consola sube el ritmo sola y otras muchas veces la deja como está, calentándose más. Una cosa rara.

¿Con esta aplicación se podría fijar como máximo 60º? Creo que es la temperatura/ruido óptimo.
aibo19 escribió:Hola Estwald yo tengo otro problema y es que teniendo activado el modo payload empece a jugar al black ops 2 y transcurridos unos 5 minutos el juego se quedo pillado y tuve que reiniciar la ps3 pero pense que habría sido algo puntual.

Sin embargo ahora me disponía a ver un video en la ps3 con el showtime y la sorpresa es que me ha pasado lo mismo(se quedo congelada y tuve que reiniciar) y ademas se escuchan micro cortes de sonido.


Ese precisamente es el problema al que me refiero en mi explicación: si algo usa eventos que suceden demasiado rápidos, no puedo evitar que puedan ser demorados si la lectura de temperatura se come cómo mínimo, 7ms (e incluso una primera lectura, 20 ms). Ese tipo de cosas, pueden producir microcortes y suceder que un evento no sea recibido y el sistema se congele en parte, por que no se ha tenido en cuenta esta posibilidad.

Eso podría hacer que un juego o una aplicación se quede frita o se aprecien pequeños cortes en el sonido, pero no tengo medio de solucionarlo ahora mismo (en ese caso, o renuncias a usar el payload con el mode 1, o ajustas una velocidad adecuada en mode 2 (una que mantenga fresquita la PS3, como por ejemplo, 0x60 o si el sonido no te molesta, la puedes subir mas)). De hecho, antes era peor el problema, pero el coste de las lecturas de temperatura, es muy alto y hay que pagarlo...

La única forma de poder solucionar eso sería inyectando código en modo usuario que cree un hilo que haga todas estas mismas cosas, pero de forma independiente, ya que de esa forma evitamos interrumpir los eventos y ni siquiera los necesitaríamos (es algo que tengo que probar si es posible hacerlo y hasta que punto es posible hacerlo, ojo). Ten en cuenta que esto no es gratis y chupa recursos y 7 ms puede ser un mundo, pero un pico de 20, demasiado

Pichake escribió:Eswald, una pregunta (no es de la aplicación). A mi normalmente s eme queda a 60-62 grados, con ruido del ventilador audible pero no molesto. Hasta ahí bien. Lo que pasa es que a veces (muchas veces), el ventilador se me queda en la anterior velocidad y la temperatura sube hasta 66-67º. Luego apago la consola, inmediatamente la enciendo otra vez y ahí si, sube una velocidad más, pero ya le cuesta bajar la temperatura.

Mi pregunta es si se sabe por qué a veces al pasar de 60º la consola sube el ritmo sola y otras muchas veces la deja como está, calentándose más. Una cosa rara.


El SYSCON ajusta las velocidades en base a unas temperaturas de corte (en mi caso a los 74 grados sube la velocidad) y la velocidad previa. Es decir: si está en 0x33 y 74 grados, sube a 0x44 y si eso se mantiene o sube, al tiempo, sube a 0x48, 0x4D... pero no lo hace de golpe, si no que se parece más al tramo que manejo yo desde los 62 hasta los 67 grados, donde la velocidad se mantiene en un rango y solo cambia cuando lo sobrepasa por debajo o por encima, solo que el SYSCON espera un tiempo y hace los ajustes mas lentamente.
Estwald escribió:
aibo19 escribió:Hola Estwald yo tengo otro problema y es que teniendo activado el modo payload empece a jugar al black ops 2 y transcurridos unos 5 minutos el juego se quedo pillado y tuve que reiniciar la ps3 pero pense que habría sido algo puntual.

Sin embargo ahora me disponía a ver un video en la ps3 con el showtime y la sorpresa es que me ha pasado lo mismo(se quedo congelada y tuve que reiniciar) y ademas se escuchan micro cortes de sonido.


Ese precisamente es el problema al que me refiero en mi explicación: si algo usa eventos que suceden demasiado rápidos, no puedo evitar que puedan ser demorados si la lectura de temperatura se come cómo mínimo, 7ms (e incluso una primera lectura, 20 ms). Ese tipo de cosas, pueden producir microcortes y suceder que un evento no sea recibido y el sistema se congele en parte, por que no se ha tenido en cuenta esta posibilidad.

La única forma de poder solucionar eso sería inyectando código en modo usuario que cree un hilo que haga todas estas mismas cosas, pero de forma independiente, ya que de esa forma evitamos interrumpir los eventos y ni siquiera los necesitaríamos (es algo que tengo que probar si es posible hacerlo y hasta que punto es posible hacerlo, ojo). Ten en cuenta que esto no es gratis y chupa recursos y 7 ms puede ser un mundo, pero un pico de 20, demasiado

Gracias por la aclaración y sobretodo por el aporte, ya me imagino que no debe ser fácil porque cuando me leí todo el primer post que escribiste ya he visto que te encontraste con bastantes problemas
Lo acabo de probar en una slim y a mi no se me produce el blackscreen que comentan algunos compis al entrar por segunda en vez en la aplicacion....¿puede ser igual porque la señal de video la tengo conectada por RGB en vez de por HDMI? igual es una tonteria lo que estoy diciendo, pero a mi no me da ningun error.

un saludo
No Puedo Creer [buuuaaaa]
impresionante :O
excelente trabajo y muchas gracias [angelito]
my respects [oki]
Instale el programa y me gusto la combinación de colores [sonrisa]

Estuve haciendo pruebas y me di cuenta de algo, que en el emulador de snes, bajo una algunos fps cuando el payload esta trabajando, pero si apago la ps3 y vuelvo y abre el emulador sin ejecutar el payload, los fps vuelve a restablecerse.

Digo que la pequeña caída de frames lo noto mas en el sonido, que de repente tiene alguno picos que no deberían salir normalmente.

Creo que esa pequeña caída de frames la tiene por los 6 segundos que se toma el payload en procesar la información con respecto a la temperatura.

Una pena que no soy programador para poder ayudarte mas con este asunto.
1985a escribió:Creo que esa pequeña caída de frames la tiene por los 6 segundos que se toma el payload en procesar la información con respecto a la temperatura.

Una pena que no soy programador para poder ayudarte mas con este asunto.


En realidad es al revés: gracias a que hay 3 segundos entre cada lectura (6 segundos es lo que se tarda en completar todo el proceso: leer las dos temperaturas y actualizar), la caída es menor de lo que debería ocurrir en condiciones normales.

La putada es que tarda mucho en tomar las temperaturas: por comparación, conté los ciclos que tomaba en cambiar la velocidad del ventilador o en ajustar los leds y el tiempo es mucho menor.

Lo que realmente molaría, es tener un proceso independiente que se ocupara de estas cosas y no transmitiera las demoras que ocurren, pero eso no es sencillo si lo que se pretende es hacerlo desde fuera
si enciendo y lo dejo en el 2 salgo del programa y el sonido se me corta da golpes y e jugado y se a quedado bloqueada e apagado de la luz con la 0.3
Me quito el sombrero ante esto Estwald, de verdad, confío en que los bug's pequeñitos que reportan los usuarios serás capaz de resolverlos, te veo capaz de eso y mucho más.

Desharé en estos días lo del potenciómetro en una de mis PS3 y lo testearé a fondo a ver, yo de momento con el POT nunca he tenido cortes como los del programa (obviamente, es hardware, no genera eventos), PERO prefiero mucho antes una solución por software que por hardware a la refrigeración.

Touché!

Gracias por todo.
Estwald escribió:
1985a escribió:Creo que esa pequeña caída de frames la tiene por los 6 segundos que se toma el payload en procesar la información con respecto a la temperatura.

Una pena que no soy programador para poder ayudarte mas con este asunto.


En realidad es al revés: gracias a que hay 3 segundos entre cada lectura (6 segundos es lo que se tarda en completar todo el proceso: leer las dos temperaturas y actualizar), la caída es menor de lo que debería ocurrir en condiciones normales.

La putada es que tarda mucho en tomar las temperaturas: por comparación, conté los ciclos que tomaba en cambiar la velocidad del ventilador o en ajustar los leds y el tiempo es mucho menor.

Lo que realmente molaría, es tener un proceso independiente que se ocupara de estas cosas y no transmitiera las demoras que ocurren, pero eso no es sencillo si lo que se pretende es hacerlo desde fuera


Lo que dices, es como si el código se integrara con el kernel.

Esto quiere decir, que si MLT se amabilizara y lo integrara como una flag, el modo usuario normal no notaria los cambios del payload y todo cargaría fluidamente???

pd: ahora mismo tengo el modo 2, a una velocidad 6D y aveces el ventilador se escucha como si baja los rpm por algunos micro segundos y luego vuelve y se restablece a la velocidad que lo tengo. Quizás esto sea tontería, porque ahora lo mas importante es el micro corte de audio que sufre la ps3 en modo payload. Sino es mucho pedir, crees que se pueda poner un visor de las revoluciones por minuto que da el ventilador.

Otra vez genial aplicación :)
Gracias por la apli y por el curro desinteresado ke te pegas,eres lo mas de lo mas Jajajaja
Saludos
893 respuestas
1, 2, 3, 4, 518