[HO] AutoGG 0.9.2 by blaKCat RGH/JTAG

paquitosolo escribió:pregunta de pollito con cual de los 4 archibos programo el squirt para corona???luego solo tengo que pulsar en el autogg para que me de la cpukey???????????lo tengo ya programado con este
SQUIRT_Corona_plusone_nr cuando la enciendo ghiclea y hace un riudillo el ventilador ya se que no me va a mostar el xell cuando para la luz del chip deja de hacerlo y asi como no se si tiene que girar el anillo verde ni parpadea la luz como que no hay lector y no se como se hace eso por red????

Mac1512 escribió:

robitibillo escribió:

chirurico escribió:Buenas otra vez.
Pues efectivamente, he decidido seguir vuestros consejos y ya estoy en marcha preparando el Nand Dumper. La duda que tengo es, si tengo la copia de la Nand de mi Zephyr que me hicieron cuando puse el RGH y la copia que me hice sin ningún badblock ¿Cuál debería restaurar? ¿Si restauro la mas reciente de esas dos me valdría para para continuar el proceso o tendría que resinstalar el Xell otra vez?

Haber con la primera nand que te sacaron al hacer el rgh que es la original, genera una nueva imagen ggbuild con autogg con el último dashboard el 15574 y luego la escribes con el nanddumper así de fácil.

Un saludo luego comentas.

+1, haz como te dice el compañero genera una imagen xebuild, a partir de la original, en el dash deseado y grabala desde nand-dumper, ya sea Lpt o Usb.

Y si no sabes soldar, te suguiero lo que dijo Loren_son, que te dejen ya sea un conector rápido o algo, para poder colocar el nand-dumper a tu antojo y no tener que soldar. Yo todas las consolas que he realizado, les he dejado un conector, por si surge algún problema y no tener que soldar nuevamente.


------------------------------ Aclaración para robitibillo y xboxadicto, así como a quien más le pueda interesar ------------------------------------------------------------



Cita de : robitibillo

No quito razón a nadie ni os contradigo pero creo que no puede ser que el xell sea el que genere los badblock, yo tengo 1 bloque corrupto físicamente en mi nand y hasta con un cygnos que es como programador usb normal el bloque corrupto siempre va a estar hay, lo que hace el programador o el xell es mover la información del bloque corrupto a la última posición de datos y deja escrita su posición de memoria original. No creo que sea el xell el que sea el culpable de generar el bloque corrupto ya que hay mucha gente que actualiza sus imagenes ggbuil flasheadas a través de rawflash desde el xell y la programación es completamente correcta aun teniendo algún bloque corrupto. También deciros que al generar un nuevo ggbuild con autogg el bloque lo remapea y crea una imagen con cada bloque en su ubicación de memoria correcta y luego al escribirla si existe algún bloque físico corrupto en la programación es cuando se reubica al final de todos los bloques de memoria pero siempre apuntando a su posición de memoria original así es como luego se puede remapear.[/spoiler]


Aclaración


Cuando vamos a realizar el RGH por primera vez, necesitamos extraer una copia de nuestra nand, para a partir de ella generar el RGH, pasando por la imagen nandxell y concluyendo en la imagen xebuild.

En este proceso, la nand ideal es la que no tiene ningún badblock, o bloque defectuoso, esto normalmente se corresponde con sectores defectuosos en el chip físico, donde este no es capad de variar el estado de lectura/escritura y por tanto son incaccesibles, siendo necesario el remapearlos en la nueva imagen que generemos. Programas como el AutoGG, lo realizan automáticamente, tanto en la zona xell, con su remapeado especifico así como en cualquier otra parte, remapeado a las utimas posiciones (dirección 3FF, en caso de una nand de 16 Mb).

Si no existiese esta funcionalidad en estos programas, tendríamos que hacerlo manualmente.

Este no es el caso en el que esta chirurico, ya que el lo que ha hecho ha sido generar una nand defectuosa (corrupta) desde un principio y grabarsela al chip físico de la consola. Así como, no llegando con eso genero otras nads y sobreescribio la nand( programa) que albergaba el chip físico a través de rawflah.

Después de todo esto, el programa que se encontraba grabado en el chip físico (NAND), se encontraba totalmente corrupto (datos incoherentes o erróneos), pero con la particularidad de que sólo le permitía ejecutar Xell.

Con lo que chirurico, creyó que podría restaurar su nand nuevamente desde rawflash. Pero para su sorpresa y a pesar de que cuando le realizaron su RGH y que la copia de la nand que le pasaron, así como la copia que el mismo extrajo, no contenía ningún badblock. Al flashear la nand desde rawflash, aparecían un montón de badblock, que le dejarón con la boca abierta y no podía dar crédito a lo que sucedia.

Se encontraba ante una incoherencia, debido a que sus copias de nand no tenían badblock, siendo estas revisadas con AutoGG, y los badblocks que aparecían al tratar de grabar esta nand con rawflash o desde el propio Xell (que incluye rawflash).

Quizas sea un bug del rawflash o quizás aún no este implementada una función en el programa capaz de afrontar el problema.

Quizas esto se resulva en la versión 5 de rawflash, si es que es liberada……

Pero lo cierto es que rawflash, no es capaz de grabar la nand nuevamente, arrojando esa cantidad de badblocks……..(Podríamos decir que Falsos, o que son la respuesta del programa al no saber como actuar ante esta situación).

Es un tostón todo lo que os he comentado en estas líneas, pero realmente es así, a mi me paso en una de mis consolas y el único método posible fue utilizando el nand-dumper, borrando la nand corrupta que se hayaba en el chip de mi consola y grabando una imagen válida de xebuild. (en la extracción de mi nand original, yo tampoco tenía ningún badblock).

Como último dato, rawflash sólo gestiona badblocks en todas las consolas desde la versión 4.

Espero os haya quedado un poco más claro……. Si no es así, podríamos abrir un nuevo hilo para debatir en el y no desviar el contenido original de este.

Un saludo

paquitosolo escribió:ya tengo la cpu key y nand escrita pero no consigo tiempo estable igual arranca a los 30 segundos que a los 2 minutos pienso que es el cable cpu rest

paquitosolo escribió:ok gracias breily voy a probar a jugar un poco con el cable a ver si consigo que sea mas estable un saludo