Pues eso.. que me pongo a leer y es "increible" !!, la gente cambiando a GB de nuevo, tocando sin saber que pasa, haciendo inventos cuando deberiamos estar quietos ....
Estamos locos.. en serio..
Vamos a poner un poco de luz "en castellano" al asunto..., hay un post en XDA donde estan tratando este tema "a fondo", y me parece que deberiamos leer un poco para saber que y como está pasando esto...
El post es este:
http://forum.xda-developers.com/show....php?t=1644364
y este el de Note:
http://forum.xda-developers.com/show....php?t=1648362
Si... no está en el subforo de Note, pero.. nos concierne.
Resumen rapido que podeis sacar leyendo el hilo, voy a intentar no meterme en detalles tecnicos, para no liarla parda:
1.- Pasarse a GB AHORA no es buena idea, luego vereis porque.
Antes en los kernels GB se usaba una version del borrado, digamos.. diferente, pero no exenta de riesgo de brickeo (si que es cierto que sus posibilidades eran de 0,0000001%).
2.- hay SOLO y bien definidas 3 areas problematicas:
a) wipe data/factory reset en Recovery (porque llama a make_ext4fs() (la funcion chunga))
b) privacy / factory reset dentro del telefono Android, ya que graba algunos comandos para el recovery en /cache, entonces... es el recovery quien hace el reset y.. por ende... llama a make_ext4fs().
c) poner una funcion format() en un script (un update-binary leera ese script y cuando encuentre un format()... llamara a make_ext4fs())
ha quedado claro cual es la funcion chunga... (make_ext4fs)
ahora veremos porque:
en llano: antes cuando se formateaba la EMMC, se rellenaba con ceros (0), porque realmente NO borraban nada, y ahora en vez de ceros.. formatean y ... usan NULL (nulos), que no es un valor que se pueda usar...
No se como explicarlo mejor, seguro que algun programador encuentra un simil facil.
El problema es que en cada Wipe, se van dejando "cachos" en "nulo", y quedan irrecuperables, asi que.. si teneis esos cachos en nulo y meteis un kernel GB y al wipear toca un cacho de esos... brick de nuevo.
Como tener alguna idea de si el firm que tenemos es seguro:
Código:
SI tienes busybox instalado:
shell@android:/ $ su
shell@android:/ # cd /sys/class/block/mmcblk0/device
shell@android:/sys/class/block/mmcblk0/device # cat cid | cut -b 19,20
te da la respuesta:
19
si te llevas mal con el teclado (como es mi caso), pon solo esto:
shell@android:/sys/class/block/mmcblk0/device # cat cid
y cuenta manualmente la posicion 19 y 20, es el numero que buscamos
si NO tienes busybox:
shell@android:/ $ su
shell@android:/ # cd /sys/class/block/mmcblk0/device
shell@android:/sys/class/block/mmcblk0/device # cat serial cid
Respuesta:
0xd3f24fe6
1501004d414734464119d3f24fe68e8b
si sale 25 o 19 en esa negrita.... posibilidad de tener superbrick.
Ahora no todo va a ser malo.... veamos lo bueno:
Estos de XDA, que no paran...
, se han puesto en contacto con Samsung, han sacado hasta los emails de los tecnicos que montan los kernels!!!, y parece que:
Samsung hizo una prueba:
Cogieron 20 aparatos, los machacaron exclusivamente para comprobar el bug (y su posible fix, que parece que lo tienen).
Estos aparatos fueron programados con el soft que sabemos que causa el brick al wipear, de esos 20, todos menos 6 tenian el fix instalado, y del total.. solo 4 brickearon, asi que lo han dejado como "resuelto"
Ahora solo falta que saquen el patch, claro....
Y los ultimos datos dicen:
el post en ingles:
http://forum.xda-developers.com/show...3#post26521643
Pregunta: se conocen los comandos para resetear el EMMC y asi recuperarse?
Respuesta: lo pongo a mi manera, una vez el chip se ha frito.. ningun comando lo reseteara, la unica solucion es hacer un update al firm del chip, pero eso incluye datos que deben ser incluidos desde fabrica, el bootloader tambien esta en el chip y tambien debe ser arreglado despues, y deja claro que es una operacion dificil y peligrosa.
Pregunta: Algun documento que nos de mas informacion de como hacerlo?
Respuesta: Es privada, estan preguntando a ver si puede liberarla, pero será que no.
Pregunta: diferencia del wipe entre GB y ICS
Respuesta: En GB cuando se wipeaba, no hacia un borrado primero, solo escribia el sistema encima, claro.. esto no borraba los datos privados del usuario, asi que cambiamos para primero borrar la particion y luego escribir el nuevo sistema de archivos. esta operacion en el firm 0x19 hace que haya superbrick
Y lo mas importante:
el brickeo NO sucede al encender.. el chip no se cuelga hasta que 1 sector corrupto (con nulo) es llamado por "alguna funcion", entonces el chip se cuelga del todo, hasta que reseteamos y otra funcion vuelve a llamar a ese sector... y .. colgados de nuevo
Por eso, si teneis el EEMC con algun sector DAÑADO, NO pongais GB !!!! ni nada por el estilo !!!, estaos QUIETOS, porque mientras no llamen a ese sector.. no pasara nada.
Pero si meteis otro firm, incluyendo GB.. y ese nuevo firm usa ese sector... superbrick.
Simplemente ESPERAD a que samsung saque el fix y pueda escribir todo a ceros.
Espero que esto ayude a alguien
Edito:
el link donde estan hablando DIRECTAMENTE con samsung:
http://innovator.samsungmobile.com/bbs/discussion/view.do?startPage=1&curPage=1&boardId=1132&boardNa me=&messageId=152576&categoryId=800&parentCategory Id=4&platformId=1&selectedSequence=00dgu~&viewMode =3
Edito que parece muy lioso:
1.-Si teneis 19 o 25, PODEIS brickear, no significa que esteis tocados, SOLO significa que PODEIS
2.-Usad este comando para saber si teneis algun sector/trozo/cacho llamadlo como querais defectuoso:
http://www.htcmania.com/showpost.php...1&postcount=26
O sea, que podeis tener el 19 y NO PASAR NADA, ya que el fallo es aleatorio y si NO teneis nada marcado... estais salvados.
Pasad ese comando y ... probemos que pasa... si se cuelga o da error.. no lo dudeis.. tirad de garantia.. la teneis marcada y parece que no se puede arreglar, como? no se.. metiendo una stock rom/firm y wipeando hasta que pete supongo.