new_core (v1.2): sm.self desde PSL1GHT y abierto a todos los CFW

Antes de nada, esto en teoría, puede trabajar con los CFW3.41, 3.55, 4.21. 4.30. 4.31, 4.40, 4.46, 4.50, 4.53 y 4.55 CEX, así como está. En principio, el core no hace nada que invite a pensar de que es incompatible con otros CFW, pero solo ha sido probado en 4.46 y 4.53 CEX y además,el sm.self solo está preparado para los CFW que menciono (no conozco los parches o los tocs de otros CFW). En todo caso, yo no me hago responsable de enladrillamiento alguno: en teoría, si esto no va, se puede entrar en modo recovery y actualizar (si os pasa eso, ni se os ocurra restaurar nada, ya que las herramientas de disco, etc, pasarían por ésta aplicación). Pero lo mejor sería que alguno que disponga de flasher lo pruebe primero en un CFW de los no probados (4.46 y 4.53 y si estás en estos, pero una aplicación externa peta, a mi no me pidáis cuentas, pecadores ) y luego reporte si va o no va, por precaución.

¿Que es lo que hace el nuevo core?. En principio, su utilidad es simplemente, lanzar sm.self, instalarlo y poder actualizarlo y actualizar el core. He procurado tener especial cuidado en el proceso de instalación os exponga el menor tiempo posible a un posible semibrick (por ejemplo, la actualización del core, es decir, de sys_init_osd.self, se hace en base renombrar rápidamente los ficheros en el momento oportuno, sin que haya riesgo alguno hasta ese momento). Más adelante, podrían implementarse otras funciones del Core de MiralaTijera, si este aparece y no le parece mal (de momento, está con las funciones mínimas). Aparte de eso, en su modo normal trabaja en segundo plano con la carga de VSH.SELF por lo que no se desincronizan los mandos, pero SI puede responder a las distintas flags, cosa que no ocurría con el "nosearch" de MiralaTijera.

¿Por qué un core ahora?. Hace tiempo, MiralaTijera me pasó el código fuente de su core, para que lo viera y portarlo hacia PSL1GHT y hacerlo open source (lleva meses con esa idea). En ese momento yo estaba en otras cosas y tampoco tenía forma segura para trabajar en ello. Además, lo suyo es que lo hiciera el . Más adelante me pasó el export que es la base y la razón de este nuevo core, para que lo añadiera en Iris Manager (y así que todo el mundo lo pudiera disfrutar). Lamentablemente, el uso de ese export solo funcionaba bien desde el core, por lo que solo los CFW MiralaTijera que incluyen el método, se beneficiaban del sm.self a pesar de ser una aplicación open source (por cierto, a mi nadie me ha preguntado nunca nada, sobre este tema )

Como ahora tengo un método más seguro de probarlo, he decidido matar dos pájaros de un tiro: por un lado, proporcionar un core básico que permita la carga de sm.self y otras cosas que les pueda interesar a otros desarrolladores en los CFW que no lo soportan y por otro, proporcionar una base para que MiralaTijera (cuando aparezca, que está desaparecido en combate desde que se ha mudado de casa ) pueda hacer open source el resto de cosas que soporta su core (yo solo he metido lo básico y lo que creo que podía hacer sin interferir en su trabajo ) o que otros hagan lo que les de la gana (yo de momento, no voy a hacer nada más salvo que surjan ideas nuevas para el core)

No tengo lector: ¿Puedo usar este core?

No, ya que no soporta "bdemu". Si estás en CFW MiralaTijera, usa su core (y no metas este!)

Tengo core de MiralaTijera, ¿debería meter el tuyo?

Depende: si no necesitas bdemu, ni ninguna función especial del core de MiralaTijera y lo único que te interesa es el sm.self, este lo carga igual, como si tuviera la flag "nosearch" (no se le va la olla a los mandos) pero SI explora el dispositivo USB en busca de flags en segundo plano, si no activas "boot_on" (en ese caso, trabajaría con el de MiralaTijera: antes de VSH.SELF)

Lo que si tienes que saber es que en ese caso, NO debes renombrar el sys_init_osdxxxx.self como sys_init_osd_orig.self

¿Como funciona el core?

El core (new_core.self) reemplaza sys_init_osd.self (que está en /dev_flash/sys/internal).

la verdad es que no se cual es la función exacta de éste ejecutable, pero parece que todo funciona si te lo saltas y cargas vsh.self directamente (Es como lo hace MiralaTijera ). Aún así, he previsto que desde el Core, se pueda lanzar sys_init_osd_orig.self si existe (si quieres usar el original, tendrás que copiarlo tu ahí con ese nombre, por ejemplo, montando /dev_rewrite desde Iris Manager y procediendo a copiarlo). En caso contrario, usaría vsh.self y si este no carga, opcionalmente puede cargar emergency.self montando dev_usb000 para arreglar el desaguisado (se supone que sería una aplicación externa con capacidad de restaurar archivos)

La característica principal de este core, es que puede trabajar en segundo con vsh.self para hacer las cosas y así los mandos no se desincronizan. Con la flag "install2" puedes instalar el sm.self o el new_core.self (una actualización) de esa manera y luego reiniciar para aplicar los cambios.

Para trabajar como el core de MiralaTijera, que hace las cosas antes de cargar vsh.self tenemos dos maneras: una temporal, que sería con la flag "install" que escribe una flag temporalmente en /dev_flash, para que instale las actualizaciones sin que vsh.self pueda interferir de alguna manera y la otra permanente, activando "boot_on", que deja escrita una flag en /dev_flash para saber que tiene que proceder de esa manera.

En principio, yo no he tenido problemas en usar "install2" para actualizar y en parte todo éste mecanismo es por seguridad y en parte para señalar como pueden trabajar futuras flags antes/después de la carga de VSH.SELF

Sobre las flags

Para hacer la aplicación he tomado notas de una serie de inconvenientes que en mi opinión, tiene el core de MiralaTijera. Por ejemplo, a mi me asusta que si metes un fichero en raíz de /dev_usb000, se instale automáticamente al arrancar, pudiendo ocasionar un problema, por un olvido.

Por ese motivo, se han añadido las flags "install" e "install2" (esta es la que verdaderamente instala las cosas). Sin dichas flags, ignorará los ficheros y además, el nuevo core renombra las flags anteponiendo el carácter '_' al usarlas. También hace lo mismo con sm.self o con new_core.self, después de instalarlos, pasando a llamarse _sm.self y _new_core.self respectivamente.

El objetivo de esto es reducir al mínimo el riesgo de instalaciones erróneas y al mismo tiempo, conservar copia de todo y poder activar las flags y las aplicaciones con solo borrar desde el Archive Manager de Iris Manager, por ejemplo, el carácter añadido.

Para evitar interferencias con las flags de MiralaTijera, se utiliza la carpeta "core_flags" en lugar de "flags". Así mismo, las aplicaciones a instalar deben estar en "core_install", en raíz del dispositivo USB que vayamos a usar (es preferible que sea una pendrive, porque se inician más rápidamente). De esta forma quitamos "basura" del directorio raíz, evitamos riesgos y queda mas clara la función de las carpetas y lo que hay dentro.

El core puede generar tres tipos de logs en /dev_usb000: emergency_log.txt solo ocurriría si no pudiera cargar vsh.self por algún motivo, install_log.txt se crea cuando se instalan ficheros con install/install2 y core_log.txt es el log normal. En principio, el core, evita generar logs en /dev_usb000 salvo en los casos importantes (install/emergency) o que añadamos la flag "verbose". Esto es así por que por lo general, los logs no son importantes y los dispositivos flash tienen ciclos de escritura limitados.

Por cierto, existe una posibilidad de usar sm.self de forma externa: consiste en copiar "sm.self" como "sm_external.self " en raíz de /dev_usb000. Lógicamente, requiere que no esté activo "ignoresm" y la presencia del dispositivo /dev_usb000, pero es otra posibilidad más para el desarrollador o para ejecutar otras cosas en segundo plano.

Este es un resumen de las flags actuales:

boot_on : habilita que el core trabaje antes de cargar VSH.SELF (como el de MiralaTijera)

boot_off : hace que el core vuelva a trabajar en segundo plano con VSH.SELF (a mi estilo )

install : procede a instalar ficheros antes de cargar VSH.SELF (forma mas segura)

install2 : procede a instalar ficheros en segundo plano con VSH.SELF

removesm : borra sm.self de /dev_flash

ignoresm : ignora la carga de sm.self (puede servir de test, si sm.self provoca un cuelgue o algo o simplemente, para saltárselo, sin necesidad de borrarlo)

verbose : activa el log completo.

¿Y como instalamos tu nuevo Core?

En el RAR adjunto un PKG: copia "install_core.pkg", "core_flags" y "core_install" en raíz de una pendrive, lo introduces en /dev_usb000 (el puerto USB mas cercano al lector), instala el PKG y lo ejecutas (New Core Installer)

Si el sistema reinicia, es que todo ha ido bien y habrá copiado el new_core.self que lleva dentro como sys_init_osd.self y el antiguo lo habrá renombrado como sys_init_osd_old.self
(si no estas en CFW MiralaTijera con Core, si quieres, puedes renombrar sys_init_osd_old.self como sys_init_osd_orig.self. Si en el futuro actualizas el Core, esa copia se borrará, ojo)

Al reiniciar cargará el XMB y se producirá un nuevo reinicio (ya que acabáis de instalar sm.self con "install2" y el core fuerza ese reinicio)

Si queréis, podéis desinstalar el "New Core Installer": los futuros updates, se harán desde la carpeta "core_install". El PKG es solamente para realizar la primera vez la instalación del core, de la forma más segura posible para vosotros y en un tiempo mínimo:

Código fuente de todo el proyecto (new_core, install_core y sm):

https://github.com/Estwald/new_core

Descarga (binarios):

http://mods.elotrolado.net/~hermes/ps3/ ... e_v1.2.rar

v1.2: añadido soporte en sm.self para CEX 4.55
v1.1: añadido soporte en sm.self para Rebug CEX 4.21, 4.30 y 4.46