Sugerencia para los usuarios bigblock nands y M.U. interna

Archivado
Os voy a comentar mi experiencia al respecto y mi conclusión para que vosotros tengais también vuestras propias conclusiones. No me gustaría llegar a llamarle tutorial a algo tan sencillo.

He estado leyendo a gente que sugiere no utilizar la Memory Unit integrada en estas consolas debido al riesgo de corromper la nand.

Este problema tiene una solución definitiva y muy muy concreta:

1) borra el trozo de la nand utilizada por la M.U. (en una nand de 512 son los bloques 1000h a 7FFFh:
nandpro usb: -e512 1000 7000
(para una de 512 y mediante USB)

2) formatea la M.U. desde el dashboard para poder utilizarla con completa normalidad.

Y esperemos que con ella terminemos con la leyenda urbana de las memorias que se corrompen en las bignands.


A continuación contaré lo que creo que sucede:
En las 3 consolas que he exploiteado me ha pasado siempre lo que le pasó a alguna gente en este foro: Tras conservar la antigua M.U. al instalar cosas, la consola no volvía a arrancar. Pero en esas mismas 3 consolas conseguí que funcionase dicha memoria de forma estable.

Observando el comportamiento de estas consolas (cuando fallaban), siempre terminaba sucediendo lo mismo: la consola fallaba al arrancar cuando en el uso anterior se había escrito en la M.U. (y especialmente si se había escrito algo grande).

Es evidente que algo estropeaba el arranque. Y es evidente que el gran problema de las B.B. no es su tamaño, si no la falta de herramientas que tienen (no hay degraded específico, etc).

Repasando los modelos de consolas y de XBRs disponibles:
- La memoria de una consola de 16MB está formada por 400h bloques exclusivos para la NAND.
- La memoria de una B.B. está formada por 8000h bloques, de los cuales 1000h serán sobreescritos por el XBR y los restantes siempre hemos supuesto que es la M.U.

Por lo que el XBR de una BB está ocupando 4 bloques más por cada bloque de una de 16 (y también cada bloque es del doble de tamaño).

Ahora contaré mi hipótesis:

Por todo ello, es muy probable, que existan bloques desde 0h hasta FFFh que inicialmente se encontrasen borrados y que nosotros los hubieramos "pisado" con el XBR.

Y como en estas memorias, cuando se detecta un bloque defectuoso es posible almacenar el contenido que debiera de tener en el en otra posición que se encontrase libre. Pero por lo visto a nadie se le ha ocurrido pensar que pasa con el espacio donde escribimos el XBR...

Imagen
Gris = dashboard
Amarillo = bloque defectuoso
Rojo = bloque con el contenido de un defectuoso
Azul claro = bloques libres
Azul oscuro = Memory Unit

Por este motivo, en ocasiones, al grabar entre 1000h y 7FFFh podría estar corrompiendose el dashboard.

Y por ese motivo, al borrar la M.U. (desde 1000h hasta 7FFFh) y formatear desde el dashboard esto deja de ser un problema y por eso el problema ya no se vuelve a producir debido a que se borran las redirecciones de los bloques defectuosos y en caso de necesidad se crearían redirecciones a posiciones más adecuadas.


Y si digo que creo que es por esta razón es por que no tengo herramientas para saber que bloques están mal en una BB ni que en que bloque se almacena cada cosa como se puede hacer en las de 16MB.
Me parece bastante lógica tu suposición. [oki]

(eso de pensar tiene que ir bien, a ver si lo pruebo un dia de estos! ;) )
Yo tb comenté algo parecido:

He leído por ahi que si se apagaba desde un juego habia riesgo de que se cascara la Nand y que era mejor borrar la MU y luego formatearla... bueno se me a ocurrido formatearla desde el dash y que si cascaba pues ya la conectaba para borrar la MU y reflashear, a medio formato se a reiniciado la 360 sola y ya estaba pensando pues mira que bien... ahora a reflashear xD (antes de formatear la MU, mostraba 213 MB o algo asi), lo que antes de levantarme del sofa he visto que se ha reiniciado bien y ahora me muestra en la MU 453 MB libres y he probado a reformatear la MU y ya no se apaga, y a apagar la consola desde el mando en medio de un juego y tp me ha pasado nada XD (no lo habia probado antes así que no puedo decir si asi se evita o no), pero a mí me ha funcionado ^^

Decir que no uso la MU ya que tengo HDD y para evitar posibles "fallos" (aunque desconozco si realmente me diera alguno), pero según mi experiencia... no creo que haga falta borrarla antes...

Lo que se me ocurre es que además, el XBR sea una imagen de una Nand de 256... y por eso las de 512 no sepa manejar bien los bloques de espacio libre de serie, y por ello haga falta formatearla si se desea usar...
JaRaBcN escribió:Lo que se me ocurre es que además, el XBR sea una imagen de una Nand de 256... y por eso las de 512 no sepa manejar bien los bloques de espacio libre de serie, y por ello haga falta formatearla si se desea usar...



A mi en su momento no me llegó con formatear. Petaba al copiar un contenido "grande" a la MU.
Shark escribió:
JaRaBcN escribió:Lo que se me ocurre es que además, el XBR sea una imagen de una Nand de 256... y por eso las de 512 no sepa manejar bien los bloques de espacio libre de serie, y por ello haga falta formatearla si se desea usar...



A mi en su momento no me llegó con formatear. Petaba al copiar un contenido "grande" a la MU.


Bueno, es probable que al formatear mantenga las redirecciones de los "bloques defectuosos" hacia bloques del XBR y por ello siga fallando, la verdad como también he dicho, como no la utilizo no es algo que haya podido comprobar a ciencia cierta, lo que si es cierto es que almenos formateando no me ha petado apagando desde los juegos ...

No sé, me imagino que acabaré probando a escribir algo "gordo" de 453 MB para llenar la MU a ver si funciona, y si no, pues ya probaré lo que has comentado, que parece del todo correcto. Lo que no tengo tan claro es que al encontrarse con un bad block, la 360 automáticamente redirija ese bloque hacia un bloque funcional de la misma MU o hacia espacio no utilizado... y que no afecte al XBR.

Mi pregunta es, siguiendo el metodo que has comentado, ¿has probado a llenar al 100% la MU sin que llegue a petar la consola?
He usado la memoria bastante pero no la he llegado a petar.

Esta tarde miro.
JaRaBcN escribió:Lo que no tengo tan claro es que al encontrarse con un bad block, la 360 automáticamente redirija ese bloque hacia un bloque funcional de la misma MU o hacia espacio no utilizado... y que no afecte al XBR.


Hay un rango de direccioes reservado a los bad block redirect. y no es al final de la memoria sinó los últimos 32 bloqes de los 66Mb primeros megas. Osea del bloque FCE al 1000. Del 1001 hasta el final es la memory unit y no tendría porque alterar el XBR.

Hace poco recuperé una arcade al que le arrancaba el xell pero no el XBR. Se habia corrompido el perfil.
Ejem...

Antes del 1000h viene el 0FFFh no el 0999h :)
RastaMan escribió:Ejem...

Antes del 1000h viene el 0FFFh no el 0999h :)


tienes razón, pero es un desliz que se me escapo solo una vez en todo el texto. (Era un gazapo obvio)

Fíjate que en el resto del texto indico valores como 8000h-1h=7FFF, pero en fin ahora lo cambio.
por eso se recomienda borrar toda la nand antes de grabar
cpu2009 escribió:por eso se recomienda borrar toda la nand antes de grabar


Pocos manuales recomiendan de forma expresa borrar toda la nand de una bigblock.
Shark escribió:
cpu2009 escribió:por eso se recomienda borrar toda la nand antes de grabar


Pocos manuales recomiendan de forma expresa borrar toda la nand de una bigblock.


yo me guio por mi sentido común , reinstalar xp encima de otro xp con el correspondiente problema del c:\windows.1? o formatear? , si no dice lo contrario siempre formatearé.
cpu2009 escribió:
Shark escribió:
cpu2009 escribió:por eso se recomienda borrar toda la nand antes de grabar


Pocos manuales recomiendan de forma expresa borrar toda la nand de una bigblock.


yo me guio por mi sentido común , reinstalar xp encima de otro xp con el correspondiente problema del c:\windows.1? o formatear? , si no dice lo contrario siempre formatearé.


En todo caso sería a borrar todas las particiones (al fin y al cabo es lo que hay en esa nand) o como poco, parecido a borrar c:\archivos de programa, c:\windows, c:\documents and settings y los ficherillos ocultos de c:\.

Es decir: en las posiciones de 0h a FFFh hay al menos 1 sistema de ficheros y desde 1000 hasta 7FFFF hay al menos otro. Es por eso por lo que esos tutoriales no dicen nada del formateo de la M.U.

El problema viene estando en como se gestionan los bloques defectuosos, no en morralla que quede de una instalación previa como te pasa con tu c:\windows.1
Che, y que onda con Jasper de 256?

Se sabe algo si el team de XBRebooter esta fixeando estos errores? (Como el de las 3 Luces verdes, las 2 luces rojas en diagonal, el 0020 aleatorio, etc?).
Esto es aplicable para alguien como yo, que haya flaseado desde debian con xbrflash con la opcion borrar MU? La tengo sin formatear por la recomendacion que vi hace tiempo.


Saludos
Acabo de meterle el xbr a mi jasper 512 y le he hecho lo de tu post Shark, por lo pronto va de lujo, gracias
Shark escribió:He usado la memoria bastante pero no la he llegado a petar.

Esta tarde miro.


¿Finalmente probaste a llenarla?

Lo comento porque me da flojera intentar llenarla solo habiendo formateado esta, para que si falla tener que re-hacer el proceso de flasheo de la NAND, añadiendo borrar la MU para luego formatearla... para que vuelva a fallar nuevamente xD
weno yo tengo que comentar que ayer metí los avatares sin actualización, que ocupan 128mb, en la memoria interna de 512 y 0 fallos por ahora
Confirmo que teniendo flasheado con debian+xbrflash0.3.6 y opcion -ep (borrado de mu), me ha corrompido la memoria despues de formatear y llenar la memoria al completo.
Por si alguien le sirve.

Saludos.
18 respuestas
Archivado
Volver a Exploits y homebrew