Como parece que este es un tema caliente he decidido hacer esta pequeña recopilacion de informacion de lo que me queda claro sobre el tema de los nuevos bricks que estan produciendo con las nuevas ROM 4.0.4. Son las conclusiones a las que he llegado yo, si veis que algo no esta correcto o os parece discutible lo añadire al post, con la intencion de que la gente lo tenga lo mas claro posible a la hora de flashear las nueva ROM y evitar visitas al SAT.
De que bricks estamos hablando?
Propiamente dicho estaríamos hablando de 2 clases de bricks:
SuperHardBrick: despues de hacer un wipe/format, restaurar un backup con nandroid o instalar una ROM en formato ZIP desde el recovery, el telefono se queda colgado o se apagas solo y despues de esto no enciende de ninguna de las maneras, ni arrancando normalmente, ni en recovery ni en download.
Para este brick no hay solucion conocida posible, ni siquiera mediante JTAG ni por supuesto con un JIG USB, unicamente envio al SAT.
En realidad parece ser que no es un daño de hardware a nivel fisico, se especula que podria arreglar haciendo una especie de "low-level format" a la memoria completa pero a dia de hoy no hay software para hacer esto, de hecho parece ser que ni el SAT de Samsung hace esto, simplemente cambian la placa base y punto.
SemiHardBrick: despues de hacer un wipe/format, restaurar un backup con nandroid o instalar una ROM en formato ZIP desde el recovery, el teléfono se cuelga o se apaga, pero cuando reiniciamos puede acceder al modo download, pero ocurren errores al flashear algunas de las particiones, bien sea con Odin, MobileOdin, Heimdall, KIES, CWM, etc.
El brick seria el mismo pero en este caso los errores no habrian afectado a las areas de la memoria necesarias para que el telefono arranque en modo download (bootloader y sbl), sino que alguna de las particiones de sistema o datos tiene sectores dañados que hacen que el telefono se cuelgue al acceder ellos, tanto en lectura (usando el telefono) como escritura (flasheando la particion de sistema).
El daño es el mismo, lo sectores defectuosos no pueden ser recuperados o remapeados con ningun software conocido ni siquiera por Samsung, si se envia el telefono al SAT con este problema lo mas probable es que tambien cambien la placa base...
Si bien los sectores dañados no se pueden recuperar de ninguna forma conocida, lo que se puede hacer en este caso es reparticionar la memoria del telefono de forma que se muevan fisicamente de sitio en la memoria la localizacion de las particiones de forma que, a costa de reducir el tamaño de otras particiones, evitemos aquellas zonas con sectores dañados. Esto solo seria una solucion de compromiso para aquellos que necesitan usar el telefono o no pueden llevarlo al SAT. (Fuente:
XDA)
Que factores influyen para que pueda suceder estos bricks:
1) El chip o el firmware del chip de memoria del telefono: algunas revisiones de chips y/o firmwares del chip mmc parece ser que tienen un defecto de fabricacion o incorporan un firmware que no es compatible con una funcion del kernel Linux llamada MMC_CAP_ERASE que se usa al borrar/formatear las particiones de la memoria interna en modo seguro.
Con la aplicacion
GotBrickBug de ChainFire (XDA) se puede comprobar si nuestro telefono tiene alguno de los chips conocidos como defectuosos.
Tambien con el programa
eMMC Brickbug Check (Market)
NOTA: en general los programas estos funcionan detectando los ids de los chipse que se conoce hasta ahora que tiene el defecto, es decir que no pueden asegurar al 100% que tengamos un chip que NO lo tiene, de ahi que la app de ChainFire simplemente diga "Unknown" cuando NO tenemos un chip entre los conocidos como defectuosos.
2) El kernel: algunos kernels habilitan estan funcion, otros no. La diferencia entre tener este flag habilitado o no es como se hace el borrado de particiones, si no esta habilitado las particiones no se borran "a fondo" pero NO corremos riesgo de brick, si esta habilitado las particiones se borran en modo seguro pero SI nos arriesgamos a tener un brick.
Que kernels tienen el flag actiivado y por lo tanto son peligrosos':
Los kernels Stock Samsung 4.0.4 conocidos hasta el momento:
PDA: I9100XXLQ5 / Kernel: 3.0.15-I9100XXLQ5-CL753921 se.infra@SEP-85 #3
PDA: I9100XWLPM / Kernel: 3.0.15-I9100XWLPM-CL837163 dpi@DELL145 #3
PDA: I9100XWLPO / Kernel: ?
Siyah v3.1rc6: una version antigua que no deberia ser facil de encontrar. Cualquier otra version de Siyah se considera segura.
Se considera que todos los kernels stock Samsung 4.0.3 y anteriores serian seguros por no tener el flag habilitado
Asi mismo todos los kernels custom (realizados por desabolladores independientes) actuales deshabilitan esta funcion al compilar el kernel y por lo tanto serian tambien seguros (aunque en este caso no estaria de mas consultar al desarrollador del kernel en cuestion).
No hay forma que se sepa para comprobar si un kernel stock de Samsung tiene esta funcion habilitada si no se dispone del codigo fuente del kernel, como seria el caso de aquellas ultimas versiones de kernel stock Samsung para los que no ha publicado el codigo fuente todavia.
Por lo tanto en mi opinion, ya que hasta las versiones v4.0.3 todos los kernels Samsung stock eran seguros, y por algun motivo que solo ellos conocen han habilitado esta funcion en las nuevas ROM v4.0.4 (tanto en la XXLQ5, version leak, beta, no-oficial, como en la XWLPM, version oficial y publica),
lo mas sensato seria considerar que, mientras no se demuestre lo contrario, todos los kernels 4.0.4 Samsung Stock podrian ser peligrosos.
3A) Wipes/Formats desde el Recovery hacer wipes/formats intenta borrar la particion antes de formatearla. Parece ser que hay la mayoria de las versions de recovery CWM estan afectadas. Aunque en principio el recovery stock que viene con los kernel oficiales de Samsung estaria parcheado para que no ejecutara esta funcion, ya hay informes de usuarios que parece sufrido bricks con el recovery stock.
3B) Restaurar un copia de seguridad Nandroid: al restaurar un backup nandroid normalmente borra la particion antes de restaurarla. Hacer el backup seria seguro, el brick estaria causado al restaurar un backup.
3C) Instalar un paquete en formato ZIP (una ROM, un parche, cualquier cosa) desde el Recoverty: si el paquete que estamos instalando contiene algun comando en el update-script que borra o formatea particiones (p.e. "format("ext4", "EMMC", "/dev/block/mmcblk0p9");) podriamos causar el brick si el update-binary que viene en el paquete ZIP intenta ejecutar el borrado de la particion. En este caso no lo tengo claro porque no hay versiones claras de los update-binary, pero por lo que se comenta en XDA aquellos que esten basados en Gingerbread serian seguro pero aquellos basados en IceCreamSandwich serian peligrosos.
Para que ocurra el brick es necesario que se den los 3 factores juntos 1 + 2 + 3A / 3B / 3C.
El factor determinante es el kernel, con un kernel seguro nunca tendremos el brick.
Sin embargo tener un kernel inseguro no es suficiente para tener el brick, deben juntarse con alguno de los otros factores.
Es decir p.e. si usamos un kernel que no tiene el MMC_CAP_ERASE habilitado estariamos seguros.
O si p.e. usamos un kernel stock Samsung 4.0.4 pero nunca hacemos wipes, nandroids, ni instalamos una ROM/Radio/Kernel en formato ZIP.
Tambien hay que recordar que tener un chip/firmware aparentemente seguro nunca significa 100% de seguridad en el caso de que se una con los otros 2 factores, digamos que tendriamos un riesgo menor.
Que se sepa hasta el momento flashear cualquier cosas desde Odin en modo Download seria seguro, porque en este caso nunca borramos las particiones, simplemente sobreescribimos la imagen encima, la unica excepcion seria tal vez si marcamos la opcion de "Repartition" en Odin, y probablemente en este caso ni siquiera estemos usando las funciones del kernel para esto, por lo que es bastante posible que en mi opinion tambien sea seguro.
Integracion kernel+recovery:
Como sabemos Samsung a diferencia de otros fabricantes integra el kernel y el recovery en la misma particion, es decir, no se puede flashear un recovery sin un kernel ni un kernel sin recovery, cuando se arranca desde el recovery no se arranca desde un kernel diferente, sino desde el mismo que cuando se arranca en modo normal. Esto hace que se puedan dar una serie de combinaciones peligrosas que puede que no este claras si no entendemos lo que estamos haciendo.
A) Kernel Stock + Recovery Stock: una ROM oficial al instalarse de partida contiene el kernel stock de Samsung + el recovery stock de Android (normalmente identificado como 3e). Aunque en principio parecia que era 100% seguro hacer wipes desde este recovery, empiezan a aparecer informes de gente que ha sufrido bricks haciendo wipes con el, por lo que deberian realizarse con precaucion. Se especula que Samsung ha modificado el recovery para evitar borrar las particiones en el modo que provoque el brick pero no esta claro si esto es efectivo o no. Ademas hay que tener en cuenta dos factores mas:
- El brick parece que ocurre cuando el controlador de la memoria se cuelga y corrompe una serie de estructuras del firmware, y este cuelgue no es algo que occurra el 100% de las veces, es un cuelgue que puede o no puede ocurrir, es posible hacer wipes sin que se cuelgue el controlador en varias ocasiones. Esto quiere decir que el hecho de que hayamos hecho un wipe y no hayamos tenido el brick no quiere decir que no vaya a suceder y estemos seguros.
- El recovery stock solo borra las particiones /data y /cache, por lo que un posible cuelgue del controlador de memoria al realizar estos wipes parece que es menos probable que afecte a otras particiones como el /kernel o el bootloader. Esto quiere decir que es menos probable que se produzca un SuperHardBrick desde el recovery stock que haciendo wipes de la particion /system de cwm (dado de que esta particion esta fisicamente en la memoria mas cerca del bootloader).
RESUMEN: no es recomendable hacer wipes desde el recovery stock sobre todo si se tiene un chip marcado como defectuoso
B) Kernel Stock + Recovery CWM temporal: con los metodos de root por recovery temporal o Fake CWM se puede cargar un CWM Recovery sin flashearlo, en este caso estamos corriendo el mismo kernel stock pero arrancando el recovery desde el ZIP que hacemos el "fake-flash", por lo aunque ejecutemos comandos como wipe o nandroid desde el CWM lo estamos haciendo sobre el kernel stock. Esta combinacion podria causar el brick mas facilmente siempre y cuando el recovery CWM temporal que estemos usando no este parcheando y este parece ser el caso de la mayoria de los que circulan actualmente.
RESUMEN: NUNCA SE DEBE DESDE ESTE Recovery CWM Temporal nada de esto:
- Wipes / Formats.
- Restaurar nandroid backups.
- Instalar ROMs, Kernels o cualquier otro ZIP que contenga comandos format en su update-script.
C) Kernel CF-Root o ChainFire + Recovery CWM: en este caso parece ser que el kernel es exactamente igual al stock, con la misma flag que causa el brick habilitada, dado que Chainfire no recompila los kernels, sino simplemente añade root, su, busybox y demas, aparte claro esta de sustituir el recovery stock por el CWM. Es decir tendriamos un kernel inseguro, pero para contrarrestar esto lo que parece ser que ha hecho Chainfire seria
cambiar el codigo del recovery CWM que hace wipes para evitar invocar la funcion problematica.
Este kernel seria mas seguro que el stock dado que a pesar de tener un kernel inseguro estariamos relativamente protegidos por un recovery parcheado que ejecuta los wipes en un modo que invoca la funcion que causa el brick
CF-Root-SGS2_XX_OXA_LQ5-v5.6-CWM5
Fuente XDA
No existe kernel CF-Root para la LPM Rusa, sin embargo como las versiones de los kernels en las 2 ROMs son lo bastante parecidas es posible que el mismo CF-Root funcione en la LPM.
En el caso de que se compruebe que el parche de ChainFire en el CWM es efectivo este kernel seria mas seguro que el stock y dado que es exactamente igual a el en el tema de drivers de hardware no deberia causas problemas con camara, bluetooth, etc.
Sin embargo hay que tener en cuenta que instalar una ROM en formato ZIP desde este recovery que contenga el update-binary/update-script problematicos mencionados mas arriba si podria provocar el bug.
RESUMEN: no es recomendable instalar ROMs, Kernels o cualquier otro ZIP que contenga comandos format en su update-script desde el Recovery CWM del CF-Root LQ5
D) Otros kernel (Siyah, Fluxxi, etc.) + Recovery CWM: ninguno de estos kernels (excepto el muy antiguo Siyah v3.1rc6) tiene el MMC_CAP_ERASE flag habilitado por lo que todos los wipes formats que se ejecuten desde el recovery serian seguros. Sin embargo la mayoria o todos estos kernels no han sido actualizados para funcionar con las ROMs stock 4.0.4 de Samsung y parece ser que tienem varios bugs (Bluetooth, Camera Preview...).
Para soluciona esto se puede usar la ultima version de Siyah a la que se le han añadido los drivers bluetooth del Note con lo que se solucionan los posibles bugs:
SiyahKernel S2-v3.4.1
(USAR la version TAR para flashear por Odin en modo download, NO USAR la version ZIP desde un kernel 4.0.4 puesto que el update-script formatea la particion /cache)
Esto no solucionaria los bugs de la camara, para esto es necesario instalar unas librerias parcheadas que son validas para cualquier kernel no-stock
I9100-404-CameraFix-CustomKernels.zip
Estas librerias si se pueden instalar desde cualquier CWM ya que simplemente añaden una serie de archivos sin formatear nada.
O sea con la version esta de Siyah + estas librerias se podria mantener una de estas ROM 4.0.4 sin sufrir los bugs conocidos ni tener ningun peligro de brick,
dado que desde el Recovery CWM de Siyah es posible hacer cualquier wipe, format, restaurar nandroid backups o instalar cualquier tipo de paquete ZIP.
Fuente:
XDA
Actualizado: 2012/07/13 - Parece ser que el recovery stock no es 100% seguro...
Actualizado: 2012/07/17 - Reescrito varios parrafos ahora que tengo las cosas un poco mas claras, añadido el kernel CF-Root LQ5 con CWM Recovery parcheado y el parche de drivers para kernels non-stock
Actualizado: 2012/07/22 - Añadido el Siyah v3.4 parcheado y las librerias parcheadas para la camara para poder usar las ROMs 4.0.4 con un kernel completamente seguro.
Actualizado: 2012/07/25 - Añadido el kernel de la XWLPO