¿Para qué se hacen downgrades de CF a 1.50?

Archivado
Pues eso, veo que mucha gente lo pregunta, hay manuales en varias webs, se habla de cómo hacerlo... ¿pero cuál es el objeto de hacerlo?
¿Volver a versiones anteriores de CF?

Saludos.
Pues que en la version 1.5 se puede ejecutar programas de codigo casero con todas las ventajas que ello tiene .... ( abrir isos, hacerse programas, etc etc )
-EvAnGeLiOn- escribió:Pues que en la version 1.5 se puede ejecutar programas de codigo casero con todas las ventajas que ello tiene .... ( abrir isos, hacerse programas, etc etc )


Pero todo esto no se hace tb con los nuevos M33??, con lo cual creo que ya el 1.5 ya esta un poco pasado, no??
-EvAnGeLiOn- escribió:Pues que en la version 1.5 se puede ejecutar programas de codigo casero con todas las ventajas que ello tiene .... ( abrir isos, hacerse programas, etc etc )

la version 1,50 ni carga codigo casero ni carga isos, para correr programas hace falta usar un xploit(bueno si, es codigo casero [+risas]) para ejecutar codigo sin firmar y para cargar isos necesitas un loader.

Con los custom firmwares ni necesitas xploit ni necesitas loaders
No creo que las respuestas que te han dicho sean las más correctas.

El principal (para mi, si me equivoco decidlo) motivo de downgrades que hay de CF a 1.50 es por si tienes un semibrick (un semibrick es cuando se puede entrar en recovery y asi recuperar la consola poniendola a 1.50)
A ver, aclaremos conceptos.

en la versión 1.0 y 1.5 del firmware de la psp, se logró ejecutar código sin firmar. esto significa que una persona cualquiera podría hacer un programa, compilarlo y ejecutarlo en la psp.

con esto nace la scene de la psp, osea, los programas caseros (homebrew)

no voy a entrar en mas detalles, pero se puede decir que en firmwares posteriores se ha logrado ejecutar código sin firmar, aprovechando Bugs (errores) en los firmwares, pero no se siguió desarrollando en estos firmwares por que la mayoría de las librerías desarrolladas para programar en la psp, estaban basadas en las librerías de la versión 1.50 del firmware, y era muy laborioso migrar estas librerías para que se pudieran ejecutar en los firmwares posteriores.

es así como el objetivo de la mayoría de los usuarios, era lograr llegar a la versión 1.5 del firmware.

a continuación llegaron los custom firmwares, que para resumir, diremos que son los firmwares originales de sony, mas las librerías que estaban "desencriptadas" (desprotegidas) del firmware 1.50, con lo que tenías las ventajas de los nuevos firmwares, manteniendo la posibilidad de ejecutar código sin firmwar de la versión 1.50.
Osea, un custom firmware será la versión oficial de Sony, mas las librerías de 1.50 que se podían programar (resumiendo, un firmware híbrido)

ahora, desde la versión 3.x (no recuerdo cual, creo que la 3.6), Dark_Alex ha logrado ejecutar código nativo en ese firmware, sin necesidad de depender de las librerías del 1.5, por lo que desde ese momento se empiezan a generar librerías para 3.x

por eso ahora se necesita un addon kernel 1.5, por que los programas antiguos funcionan con las librerías 1.5, y cuando intentas ejecutarlas por ejemplo en un 3.71m33, sale un error.
Para esto, el addon kernel 1.5, lo que hace es proporcionar a la psp las librerías que necesita para que ese programa se ejecute en una versión superior de la que fué creada. (es como la compatibilidad de Windows para ejecutar programas antiguos de 16 bits)

todavía estamos en una etapa de transición, por lo que verás personas que quieran bajar a 1.5, por que sus programas (emuladores, etc) no han sido portados a la nueva versión 3.xx.
Nota: esto es aplicable solo a las PSP FAT. Recordad que la PSP Slim no puede ser downgradeada a 1.5, por que el hardware no lo soporta, por tanto, siempre que se hable de 1.5, será en relación con la PSP FAT.

Espero que la explicación se entienda.

Zalu2!
Creo que es mas por desconocimiento de lo que realmente se a logrado en los nuevos firmwares modificados y nada mas, como ya explicaron -y muy bien por cierto- no es necesario hacerlo, pero en fin.
Para k sacar métodos para volver a la 1.5 dsd un cf??? Yo pienso que ademas de las razones que ha dado Deen0X existe otra que es la de tener la libertad de hacerlo sí uno quiere. Yo creo qué no hay mayor historia que eso. Tener la opción de poder hacerlo. [idea]
Deen0X escribió:ahora, desde la versión 3.x (no recuerdo cual, creo que la 3.6), Dark_Alex ha logrado ejecutar código nativo en ese firmware, sin necesidad de depender de las librerías del 1.5, por lo que desde ese momento se empiezan a generar librerías para 3.x



No, desde el primer custom firmware basado en 3.XX, dark alex ya incluía un HEN nativo para dicho firmware, es decir, los programas actuales para 3.XX rulan también e 3.02 OE, que es la más antigua basada en 3.XX, de hecho tengo entendido que también rularían en 2,71 SE.


Si no había programas preparados para 3.XX era `por que no había demasiadas herramientas para programar así, pero desde hace ya bastante existen aplicaciones para 3.XX. Mismamente los juegos de PSX convertidos.
ErDaByz escribió:


No, desde el primer custom firmware basado en 3.XX, dark alex ya incluía un HEN nativo para dicho firmware, es decir, los programas actuales para 3.XX rulan también e 3.02 OE, que es la más antigua basada en 3.XX, de hecho tengo entendido que también rularían en 2,71 SE.


Si no había programas preparados para 3.XX era `por que no había demasiadas herramientas para programar así, pero desde hace ya bastante existen aplicaciones para 3.XX. Mismamente los juegos de PSX convertidos.


puede que tengas razon.
en todo caso, me basaba en la info que venían en los readme de los CF.

ahora mismo, estaba leyendo el readme del 3.71m33, y sale esto:
"- Both version boot now from 3.XX ipl, and are independent of 1.50.
The main installer will not install 1.50 kernel anymore."


osea, que desde esta versión, oficialmente ya no va el kernel de la 1.50 en el CF

en todo caso, una cosa es que no se instale, y la otra como has dicho es que se pueda ejecutar código directo en 3.xx

me parece que este hilo puede resultar mas aclarativo de lo que me imaginaba.

;)

Zalu2 y feliz año nuevo!
Por un lado, el hecho de hacer un downgrade a 1.50 desde cualquier CF, bajo mi punto de vista, se realiza por varias razones:
  1. No te apetece seguir estando con un CF.
  2. Experimentos varios
  3. Problemas con CF
  4. o simplemente porque te da la gana xD
A día de hoy, lo único que tiene el *puro* 1.50 que no tenga el último M33 (ni ningún otro) es el propio kernel, de manera que homebrews hechos bajo dicho kernel (kxploit), no funcionarán en M33.

¿Soluciones para que funcione? Ahora mismo existen varias soluciones; o bien bajas a 1.50 o un cfw inferior que permita dicha ejecución; o bien usas el eLoader 1.0 de Noobz que, tirando muy hacia arriba, puede que cargue un 10% de los homebrews kxploiteados en un M33. (Esto, claro, sin tener en cuenta los cambios de NIDS que joden directamente la carga XD)

Pues bien, la verdad es que este hecho, el de la carga del kernel 1.50 en M33, es fácilmente solucionable, y estuvo durante un tiempo X en mente de AleX, pero cómo es obvio, no ha sido siquiera lanzado ni terminado (supongo) ya que se quiere que los desarrolladores se acostumbren al kernel 3.x y que aprendan de los cambios de NIDS, ya que quedarse atascados en 1.50 es un poco... inservible a largo plazo.

@Deen0X, tu explicación es buena, pero tiene una serie de errores; ya que por un lado en 1.00 y 1.50, sí se cargó código sin firmar, pero no directamente con un copy paste a la MS, sino mediante un xploit como comentan anteriormente xD; en los posteriores (custom) firmwares, no se aprovecha explícitamente de bugs, sino que directamente se usan parcheos en memoria para aprovechar una mala fabricación (fat) de hardware que permite inyectar el propio kernel 1.50 (cosa que no sucede en slim como nos ha mostrado el tiempo) Obviamente, en 2.00 y demás, surgieron los propios downdates o downgrades genéricos para ir directamente a 1.50 como bien has comentado. Por otro lado, el hecho de las librerías o del propio PSPSDK (supongo que te referías a eso), se realizó mediante ingeniería inversa al Puzzle Bubble japonés (xD), a partir de lo cual se empezó a migrar librerías basándose en ese propio sdk y funciones base.

No me meteré más en este asunto ya que, entre otras cosas, tengo una mesa reservada para comer en breves xD Si alguien tiene dudas o algo, que pregunte; me paso a la vuelta y sigo comentando cosillas.
10 respuestas
Archivado
Volver a Firmwares y modchips