[UPDATE4][CFW 4.40 MiralaTijera] System manager 1.1 & Core 3.2.0 integrado +qaflag

[update 4 publicado , leerse todo el post ]

Estwald escribió:Antes de nada, Miralatijera me comentó que si no lo "veía" hiciera público el Core en su nombre y el resto, es de mi cosecha gracias a su colaboración

Por otro lado, la exclusividad de esto, se debe a que solo su CFW ofrece la posibilidad de lanzar aplicaciones en segundo plano y estas cosas, demuestran que cuando los CFW aportan ideas útiles y en vez de guardarse bajo llave, se les ofrece la posibilidad a los dev, estos pueden hacer cosas y son mas proclives a hacerlo. En cambio, otros, se piensan que por sacar un CFW, automáticamente, tienes que darle soporte... pues va a ser que no : o te lo curras y proporcionas la info o te preocupas tu de portarlo (hablo de Iris Manager), como ha hecho Miralatijera (en 4.31 nos dió todos los datos que pudo y en 4.40, hizo el port él, y yo luego arreglé algunas cosillas: así si se hacen las cosas), porque si no, directamente se descarta el soporte y yo tan tranquilo .

Y dicho esto, vayamos al asunto:

El Core

El core presenta cómo novedad la posibilidad de lanzar una aplicación en segundo plano, la cual recibe el nombre de "sm.self" y se instala en raíz de /dev_flash, lo cual tiene ventajas e inconvenientes:

Inconvenientes:

- Si la aplicación en segundo plano cuelga el sistema, obviamente, el sistema no avanzará a partir de ese punto. Por eso se ha previsto la flag removesm para poder eliminarla, aunque obviamente, si alguien pone flag nosearch, el resultado sería un semibrick (habría que reinstalar en CFW). Así que ojo con esto.

- El acceso al sistema está limitado a las syscalls y los exports de liblv2 básicamente.

- Que la aplicación esté en segundo plano, no significa que no coma recursos, obviamente

Ventajas:

- La posibilidad de poder controlar las temperaturas y ventilador sin afectar a otros procesos directamente o de mantener "despiertos" dispositivos USB que tienden a dormirse, parece un buen principio. La aplicación corre en un plano independiente al VSH.SELF, emulador de PSX o juego de PS3 (obviamente, en el emulador de PS2, al menos, en modo nativo en las FATs, el LV2 deja de existir y nuestra aplicación, muere) y no detiene los procesos en LV2 cómo ocurre con otras alternativas.

El System Manager

El System Manager es cómo he llamado a la aplicación que correrá en segundo plano: básicamente, consta de 3 partes autónomas:

1) El main: El main se encierra en un bucle de 1ms de duración para recibir comandos vía dirección 0x450 de LV2 con los cuales configurar la aplicación (se pueden fijar las prioridades de los hilos, cambiar las tablas de temperatura, el modo y el tiempo de la activación de dispositivos y obtener alguna información adicional)-

2) El FanCtrl_Thread: básicamente, éste hilo hace lo mismo que el payload que he desarrollado para Control Fan Utility (Por cierto, la aplicación ha sido actualizada a la 1.5 para que trabaje con ésto sin problemas )

hilo_utilidad-control-fan-utility-v1-5-cfw-cex-3-41-3-55-4-21-4-30-4-31-y-4-40_1893851

La ventaja es que a diferencia del payload, esto no afecta a los procesos de forma directa, por lo que no deberían suceder los problemas que reportan algunos usuarios de la aplicación. Básicamente, así es como me hubiera gustado a mi hacerlo desde el principio, pero hasta ahora, no tenía forma.

Se ha añadido un pequeño payload que se aloja en la dirección 0xF70 de LV2, parecido al del Control Fan Utility, pero solamente, para protegerse de la syscalls sm_shutdown y proporcionar compatibilidad con el sistema anterior, con el fin de que lo pueda integrar en Iris Manager, el soporte.

3) UsbWakeup_Thread: Este hilo tiene 3 modos de ejecución y básicamente, se ocupa de "despertar" a los dispositivos USB que tienden a "dormirse" por falta de uso, ocasionando problemas en los juegos.

El modo de despertarlos consiste en escribir en un fichero llamado "nosleep" que podemos crear en Raíz del dispositivo (no importa que tenga longitud 0, solo que exista o no) para que el SM sepa que unidades debe o no utilizar. Por defecto, lo hace cada minuto, pero se pueden programar pasos de 10 segundos (2560 segundos el máximo, a los cuales habría que añadir dos segundos por el indicador).

Los dispositivos USB de almacenamiento, los podemos dividir en discos duros y dispositivos de memoria flash que no son tan conveniente estar escribiendo todo el rato. Esta es la razón por la que se delega en el usuario la creación de "nosleep". Por cierto, en algunos juegos, se requiere montar BD Emu y eso hace que el dispositivo USB pase a renombrarse como /dev_bdvd, cosa que también esta soportado.

Los tres modos de funcionamiento son :0 -> desahabilitado, 1-> habilitado para un solo dispositivo y 2-> habilitado para todos los dispositivos (éste es el modo por defecto)

Funcionamiento por defecto (autónomo)

Nada más cargarse el SM, los ajustes son los siguientes:

- Control de temperaturas/ventilador equivalentes a Control Fan Utility activo.

- Wakeup de escritura en todos los dispositivos, incluido /dev_bdvd (si es un dispositivo USB permitirá la escritura) activada, procediéndose a escribir 1 vez cada minuto, aproximadamente. Evidentemente, la escritura solo afectará a aquellos dispositivos que tengan el fichero "nosleep" (en el resto, podrías detectar un acceso de lectura como mucho)

Los leds indican lo siguiente:

- Led amarillo fijo: temperatura por debajo de los 70 grados
- Led amarillo/verde parpadeante: temperatura por encima o igual a 70 grados
- Led rojo/amarillo/verde parpadeante: temperatura por encima o igual a 75 grados

- Led verde mantenido dos segundos cada 10: led de actividad

- Leds apagados durante dos segundos: indican un acceso de escritura al dispositivo USB. Esto es importante conocerlo, por que no debemos desenchufar un dispositivo USB en medio de una escritura, obviamente (podemos esperar a que los leds se apaguen y desenchufar unos segundos después)

Soporte de Control Externo

Control Fan Utility 1.5:

hilo_utilidad-control-fan-utility-v1-5-cfw-cex-3-41-3-55-4-21-4-30-4-31-y-4-40_1893851

Y próximamente, Iris Manager:
hilo_aplicacion-iris-manager-v2-36p_1862716_s820

Instalación y uso

Si tienes la flag "nosearch" activa, desactivala. Copia el Core (sys_init_osd.self) y sm.self en raiz de una pendrive y espera los reinicios (hace varios, para instalar el core y luego, al instalar el system manager)

Si quieres desinstalar sm.self posteriormente, añade la flag "removesm"

Si quieres que prevenir que un dispositivo USB se "duerma" crea un fichero "nosleep" en raíz del dispositivo (no importa si mide 0 bytes)

Descarga

Core 3.3.0:

http://mods.elotrolado.net/~hermes/ps3/core_3.2.0.rar

System Manager v1.0:

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

(incluye código fuente para compilación bajo PSL1GHT)

Estwald escribió:Lo nuevo:

- 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 ) en raíz del dispositivo que queráis que cada cierto tiempo, se acceda en escritura para mantenerlo alerta

-------------------------------------

Psmaniaco escribió:Estwald una pregunta, en tu Iris Manager me parece que añadiste las temperaturas del Cell y el RSX ¿no?
¿Son las temperaturas de los sensores que mencionaste mas atras?
Un saludo.

Si

poner otra aplicación en segundo plano

Si y no. Para empezar, solo se puede tener acceso mediante syscalls o con las funciones exportables de liblv2 en PSL1GHT. Haceros a la idea de que esto es pre-VSH.SELF y funciona de forma completamente autónoma. Además, necesita una serie de flags especiales de construcción o no funcionará (los que incluyo en el Makefile para scetool).

Si no se hace así, lo mejor que os puede pasar, es que ignore vuestra aplicación

Por cierto y ya que estamos, si queréis borrar el sm.self lo podéis hacer directamente (está en raíz de /dev_flash y basta con montarla en escritura) o por el contrario, añadir la flag "removesm" para que el core lo haga por vosotros: no hace falta quitar el Core.

Y ya que estamos, una recomendación mía: no pongáis NUNCA en raíz ningún fichero susceptible de ser copiado por el core salvo que sea eso lo que queráis: si metes un vsh.self en raíz, por ejemplo, se copia de forma automática y no le va a importar si es una versión distinta. Asi que mucho ojo con eso, que podéis provocar un semibrick