Noticia Importante (hardbricks)

[gluch]

Fuente: http://forum.xda-developers.com/show...8&postcount=69

It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).

This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c

As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.

It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.

I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
__________________
Samsung Galaxy S II (SGH-I777) -CM9, sometimes self-debloated/deodexed TW
Samsung Galaxy Player 5.0 (YP-G70) - Stock system + my kernel
Galaxy Tab 10.1 - Cyanogenmod 9
Samsung Confuse 4G (SGH-I997) - Self-deodexed/debloated UCLB3 + my kernel

Last devices - Huawei S7 and AT&T Tilt2 (RHOD300) running XDAndroid FRX06 (still have them collecting dust)

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

TRADUCCION POR VENABLES

Bueno os dejo la Traducción a ver si lo entendéis mejor así:

Sería beneficioso para proporcionar más información sobre el Bug del Brick para evitar que algunas personas no estén tan están asustados (como la mayoría de los usuarios del i9100).

Para este error se necesitan 3 cosas para que pueda estar en peligro, y todas estas condiciones se deben cumplir para el peligro:

1) Un chip defectuoso eMMC / fwrev que es incapaz de controlar los comandos del máster Erasmus Mundus comando ERASE (38) correctamente. (Voy a ofrecer un enlace con más detalles sobre la naturaleza del error más tarde) - Esta condición es nuevos controles de Chainfire para aplicaciones. Por cierto, M8G2FA fwrev 0x11 (visto en algunos Kindle Fire) es también sospechoso de ser defectuoso.

2) Un recovery Binario que intenta borrar las particiones cuando está formateando. La mayoría de los Recoverys Binarios de ICS en esta categoría, la mayoria de las Recuperaciones de Gingerbread no intenta llevar a cabo una operación de borrado así que son seguros.

Hay que tener en cuenta también, una de actualización binaria afectada en un ZIP podría ser una causa de problemas. (Por ejemplo, flashear un firmware ICS que tiene una actualización binaria y formatea la partición podría causar un problema, incluso haciendolo a través de un recovery seguro.) Así que un Kernel puede ser embalados (Repack) de nuevo con un CWM "seguro" (como las más recientes versiones de CF-Root), pero todavía sólo parcialmente a salvo.

3) Un Kernel que permite borrar una partición puede ocurrir en realidad. (En contraposición a la presentación de informes "no compatible" y no hacer nada.) - Una forma común de hacer una copia de un kernel Seguro es eliminar MMC_CAP_ERASE desde / MMC / mshci.c

A partir del 06 de junio 2012, esto es lo que sé en cuanto a los Kernels que cumplen con la condición 3:

GALAXY S2
Todas las ICS Leaks GT-i9100 y oficiales son SEGURAS (MMC_CAP_ERASE no aparece)

Todos los Kernels basados ​​en GT-i9100 ICS Update4 son SEGUROS (MMC_CAP_ERASE no aparece) - Esto incluye todos las CM9 nightlies SGH-I777 para, GT-i9100, y GT-N7000

Todas las ICS LEAKS GT-N7000 son INSEGUROS
Todos los Kernels oficiales ICS son INSEGUROS
Todos los Kernles construidos a partir de las fuentes GT-N7000 son INSEGUROS a menos que la siguiente condición: MMC_CAP_ERASE se se haya retirado de / mmc / host / mshci.c - comprobar las características del Kernel para confirmar esto.
Kernel Franco R3 y posteriores y todos los de Speedmod ICS son SEGUROS debido a esto.

Todos los Kernels SHW-M250S/K/L ICS se sospecha que son INSEGUROS

Todos los ICS Oficiales de SHW-M250S/K/L a partir de esta fecha son INSEGUROS(ACS-M250L Update4 fue la causa del incidente SiyahKernel 3.1rc6. Otras versiones Siyah son SEGUROS)

Todos los comunicados de SPH-D710 ICS partir de esta fecha son INSEGUROS - Se rumorea que la OTA Oficial puede tener un Kernel Fixed, pero se recomienda tener en cuenta este Kernel como INSEGURO hasta que el código fuente esté liberado y pueda ser revisado.

Es difícil obtener todos los casos y evaluarlos, pero en general en términos de niveles de peligro (el 6 de junio de 2012 - esto podría cambiar con el tiempo):

Los Usuarios del SPH-D710 están en mayor peligro - No tienen versiones de ICS oficiales y el i9100 Update4 no puede ser utilizado para construir un kernel utilizable para su dispositivo sin un trabajo importante de desarrollador

Los Usuarios del GT-N7000 Están en 2º lugar en la lista - Ellos son los únicos fuera de Corea en recibir actualizaciones oficiales de ICS que provocan el defecto del firmware eMMC. Sin embargo, i9100 el Update4 requiere menor trabajo para la creación de Kernels Seguros, y los desarrolladores saben el procedimiento adecuado para hacer que la oficial N7000 Update3 sea segura.

SGH-I777 usuarios están al lado - I777 Las Leakcs han demostrado ser peligrosas o menos un mes atrás. Sin embargo, el SGH-I777 requiere mucha menor cantidad de trabajo para ser capaz de utilizar el GT-i9100 Update4 base, y como resultado, con la excepción de las propias Leaks, casi todos los Kernels de I777 ICS que se basan fuera del código fuente son seguras.

GT-i9100 Son los usuarios que están en menor peligro - Sin Leaks Oficiales o la liberación del código fuente. Sólo un núcleo de i9100 ha demostrado ser peligroso y que fue retirado rápidamente por el desarrollador.

No estoy evaluando la SHW-M250S/K/L en la lista anterior, ya que mientras aunque yo sé de su fuente y que los binarios son peligrosos, la barrera del idioma / cultura significa que tenemos muy poca información acerca de este Fiasco.

Añadido por ikaos la traduccion de venables para la mejor compresión de todos.

[mislatero]

traducelo amigo.

[keitaro_xp]

Lo principal que saco yo ahí es que el kernel franco para ICS es seguro de bricks... osease, q como eso se confirme mañana mismo me vuelvo a ICS con el kernel de franco y a correr, q en GB me tira de pm jejeje

[ikaos]

Gracias, pero a groso modo explica lo que se habla en los diferentes post que se encuentran por htcmania, dandole una explicación clara y concisa del gran problema que ha creado samsung y sus ingenieros chapuzas.

[yocasta]

Es una recopilación de todo lo que se ha ido sabiendo.
Resumiendo la parte que nos toca; Los únicos kernel seguros en ICS son los que tienen parcheado el bug como el franco desde la r3 y el speedmod. O los que no se basan en el kernel oficial como CM9 (o thor)
Aunque me extraña que no mencione el de chainfire 5.6 que ya incluía parche para esa llamada de borrado.

Edito, el de chainfire es el primero que menciona como ejemplo de seguro.

[serginhocm]

Se puede instalar un kernel (como por ejemplo el de franco) independientemente de la rom que tengas o debe cumplir algun requisito? Yo por ejemplo, por todo el tema de los briks me mantengo en la beta china con rom criskelo v2 y me gustaria actualizar lo mas seguro posible...

Enviado desde mi GT-N7000 usando Tapatalk 2

Por favor que borren todo el tocho ese
Y que lo pongan en español
O que solo dejen el enlace


Enviado desde mi GT-N7000 usando Tapatalk 2

Originalmente Escrito por ikaos

Gracias, pero a groso modo explica lo que se habla en los diferentes post que se encuentran por htcmania, dandole una explicación clara y concisa del gran problema que ha creado samsung y sus ingenieros chapuzas.

Pues yo no entiendo ni papa así que de clara nada

Enviado desde mi GT-N7000 usando Tapatalk 2

[ikaos]

Originalmente Escrito por LtsRacer

Pues yo no entiendo ni papa así que de clara nada

Enviado desde mi GT-N7000 usando Tapatalk 2

Mi ingles es del cole, pero mas o menos lo entiendo despues de leer los diferentes post de aqui y de xda, y lo que no entendía utilice el traductor de google (por cierto que malo que es)...

[VENABLES]

Bueno os dejo la Traducción a ver si lo entendéis mejor así:

Sería beneficioso para proporcionar más información sobre el Bug del Brick para evitar que algunas personas no estén tan están asustados (como la mayoría de los usuarios del i9100).

Para este error se necesitan 3 cosas para que pueda estar en peligro, y todas estas condiciones se deben cumplir para el peligro:

1) Un chip defectuoso eMMC / fwrev que es incapaz de controlar los comandos del máster Erasmus Mundus comando ERASE (38) correctamente. (Voy a ofrecer un enlace con más detalles sobre la naturaleza del error más tarde) - Esta condición es nuevos controles de Chainfire para aplicaciones. Por cierto, M8G2FA fwrev 0x11 (visto en algunos Kindle Fire) es también sospechoso de ser defectuoso.

2) Un recovery Binario que intenta borrar las particiones cuando está formateando. La mayoría de los Recoverys Binarios de ICS en esta categoría, la mayoria de las Recuperaciones de Gingerbread no intenta llevar a cabo una operación de borrado así que son seguros.

Hay que tener en cuenta también, una de actualización binaria afectada en un ZIP podría ser una causa de problemas. (Por ejemplo, flashear un firmware ICS que tiene una actualización binaria y formatea la partición podría causar un problema, incluso haciendolo a través de un recovery seguro.) Así que un Kernel puede ser embalados (Repack) de nuevo con un CWM "seguro" (como las más recientes versiones de CF-Root), pero todavía sólo parcialmente a salvo.

3) Un Kernel que permite borrar una partición puede ocurrir en realidad. (En contraposición a la presentación de informes "no compatible" y no hacer nada.) - Una forma común de hacer una copia de un kernel Seguro es eliminar MMC_CAP_ERASE desde / MMC / mshci.c

A partir del 06 de junio 2012, esto es lo que sé en cuanto a los Kernels que cumplen con la condición 3:

GALAXY S2
Todas las ICS Leaks GT-i9100 y oficiales son SEGURAS (MMC_CAP_ERASE no aparece)

Todos los Kernels basados ​​en GT-i9100 ICS Update4 son SEGUROS (MMC_CAP_ERASE no aparece) - Esto incluye todos las CM9 nightlies SGH-I777 para, GT-i9100, y GT-N7000

Todas las ICS LEAKS GT-N7000 son INSEGUROS
Todos los Kernels oficiales ICS son INSEGUROS
Todos los Kernles construidos a partir de las fuentes GT-N7000 son INSEGUROS a menos que la siguiente condición: MMC_CAP_ERASE se se haya retirado de / mmc / host / mshci.c - comprobar las características del Kernel para confirmar esto.
Kernel Franco R3 y posteriores y todos los de Speedmod ICS son SEGUROS debido a esto.

Todos los Kernels SHW-M250S/K/L ICS se sospecha que son INSEGUROS

Todos los ICS Oficiales de SHW-M250S/K/L a partir de esta fecha son INSEGUROS(ACS-M250L Update4 fue la causa del incidente SiyahKernel 3.1rc6. Otras versiones Siyah son SEGUROS)

Todos los comunicados de SPH-D710 ICS partir de esta fecha son INSEGUROS - Se rumorea que la OTA Oficial puede tener un Kernel Fixed, pero se recomienda tener en cuenta este Kernel como INSEGURO hasta que el código fuente esté liberado y pueda ser revisado.

Es difícil obtener todos los casos y evaluarlos, pero en general en términos de niveles de peligro (el 6 de junio de 2012 - esto podría cambiar con el tiempo):

Los Usuarios del SPH-D710 están en mayor peligro - No tienen versiones de ICS oficiales y el i9100 Update4 no puede ser utilizado para construir un kernel utilizable para su dispositivo sin un trabajo importante de desarrollador

Los Usuarios del GT-N7000 Están en 2º lugar en la lista - Ellos son los únicos fuera de Corea en recibir actualizaciones oficiales de ICS que provocan el defecto del firmware eMMC. Sin embargo, i9100 el Update4 requiere menor trabajo para la creación de Kernels Seguros, y los desarrolladores saben el procedimiento adecuado para hacer que la oficial N7000 Update3 sea segura.

SGH-I777 usuarios están al lado - I777 Las Leakcs han demostrado ser peligrosas o menos un mes atrás. Sin embargo, el SGH-I777 requiere mucha menor cantidad de trabajo para ser capaz de utilizar el GT-i9100 Update4 base, y como resultado, con la excepción de las propias Leaks, casi todos los Kernels de I777 ICS que se basan fuera del código fuente son seguras.

GT-i9100 Son los usuarios que están en menor peligro - Sin Leaks Oficiales o la liberación del código fuente. Sólo un núcleo de i9100 ha demostrado ser peligroso y que fue retirado rápidamente por el desarrollador.

No estoy evaluando la SHW-M250S/K/L en la lista anterior, ya que mientras aunque yo sé de su fuente y que los binarios son peligrosos, la barrera del idioma / cultura significa que tenemos muy poca información acerca de este Fiasco.

[NOTEmate]

Yo lo que no entiendo es lo de la parte de flashear un Zip incluso desde un recowery seguro puede causar problemas??osea q no podemos flashear nada?

Enviado desde mi GT-N7000 usando Tapatalk 2

[ATLANTIS1976]

pues vamos apañaos... los chip's defectuosos creo que todo los tenemos (segun la app de chainfire) ..y quien no ha instalado la ics con sus kernel?.. segun creo entender que con el kernel de franco no hay peligro pero si ya hemos instalado anteriormente el kernel de ics original aunque haya sido rooteado el bug se activaria y joderia las celdas de chip emmc.. en fin que es custion de tiempo que nuestros notes vayan cayendo....

Enviado desde Galaxy Note

[yocasta]

Originalmente Escrito por NOTEmate

Yo lo que no entiendo es lo de la parte de flashear un Zip incluso desde un recowery seguro puede causar problemas??osea q no podemos flashear nada?

Enviado desde mi GT-N7000 usando Tapatalk 2

Dice que puede pasar, no que vaya a pasar, es distinto.

Esto es como cuanto tienes una operación y firmas la renuncia de responsabilidad, si lees lo que pone sales corriendo del hospital con la bata con el culo al aire.


Lo que se puede deducir de todo esto es que si bien existe un riesgo (pequeño) de brick lo mejor sería quedarse quietecitos en la mata hasta una solución definitiva.
Y tener el triángulo quitado con el contador a cero no está de más.

[yocasta]

Originalmente Escrito por ATLANTIS1976

pues vamos apañaos... los chip's defectuosos creo que todo los tenemos (segun la app de chainfire) ..y quien no ha instalado la ics con sus kernel?.. segun creo entender que con el kernel de franco no hay peligro pero si ya hemos instalado anteriormente el kernel de ics original aunque haya sido rooteado el bug se activaria y joderia las celdas de chip emmc.. en fin que es custion de tiempo que nuestros notes vayan cayendo....

Enviado desde Galaxy Note

No es así. Sólo por instalar ICS no "activas" el bug necesariamente, el bug puede ser activado o no.
Es un porcentaje pequeño de brick, y si no andas todo el día flasheando de aquí para allá no hay mucho riesgo (no estoy diciendo que sea seguro, sino que las probabilidades de joder el teléfono son bajas).

[mapache73]

cual es esa app de chainfire que te dice si tienes el movil con ese chip o si esta con riesgo de brick? yo siempre que he instalado la ics, lo he hecho con odin mobile pro y por lo visto ese programa nunca instala el kernel original, sino uno que instala el propio programa

[yocasta]

El odin móvil no instala su kernel, usa su kernel basado en ginger para el proceso, lo cual hace qué en si usarlo sea seguro, pero si metes un kernel de los de riesgo es el qué te grabará.
Qué alguien me corrija si me equivoco, qué tampoco tengo muchas horas de vuelo con la versión móvil del odin.

[nemo31416]

Originalmente Escrito por yocasta

Es una recopilación de todo lo que se ha ido sabiendo.
Resumiendo la parte que nos toca; Los únicos kernel seguros en ICS son los que tienen parcheado el bug como el franco desde la r3 y el speedmod. O los que no se basan en el kernel oficial como CM9 (o thor)
Aunque me extraña que no mencione el de chainfire 5.6 que ya incluía parche para esa llamada de borrado.

Edito, el de chainfire es el primero que menciona como ejemplo de seguro.

Hola @yocasta me parece que la minirecopilacion que haces en este post es IMPRESCINDIBLE QUE SE DIFUNDA AL MAXIMO, se chincheté o se haga una version mas elaborada del mismo y se ponga como tema fijo. Para los que como yo hemos adquirido el Note en el ultimo mes, mes y medio su contenido es ORO PURO, y mas después del palo que ha sido conseguir, al fin...., nuestro Note y encontrate que te has metido en un callejon sin salida.
Soy miembro del foro desde hace años y estoy muy agradecido a administradores, cocineros y usuarios veteranos por toda la ayuda que me han dado, pero a veces se olvida que no todo es utilizar el buscador...., hay temas de la importancia de este, (estamos hablando que las ACTUALIZACIONES OFICIALES pueden PROVOCAR UN BRICK TOTAL del cacharro..., no es el típico brickeo por toqueteo incontrolado....) que hacen que los que mas controlais el Note debeis ser lo mas explicitos posible para ayudar a los nuevos.
Si tienes falta de tiempo me ofrezco voluntario a compactar en un post toda la info a día de hoy con los enlaces a kernels seguros, etc....en cualquier caso muchas gracias y si pudieras reconfirmar el contenido de tu post pues muchas gracias mas.

[beerbong]

Originalmente Escrito por yocasta

El odin móvil no instala su kernel, usa su kernel basado en ginger para el proceso, lo cual hace qué en si usarlo sea seguro, pero si metes un kernel de los de riesgo es el qué te grabará.
Qué alguien me corrija si me equivoco, qué tampoco tengo muchas horas de vuelo con la versión móvil del odin.

Chainfire dice que no está seguro de que flashear desde MO sea del todo seguro (estando en ICS Samsung).

Aquí sus dos últimas informaciones al respecto:
http://forum.xda-developers.com/show...postcount=1730
http://forum.xda-developers.com/show...postcount=1361

[yocasta]

Originalmente Escrito por nemo31416

Hola @yocasta me parece que la minirecopilacion que haces en este post es IMPRESCINDIBLE QUE SE DIFUNDA AL MAXIMO, se chincheté o se haga una version mas elaborada del mismo y se ponga como tema fijo. Para los que como yo hemos adquirido el Note en el ultimo mes, mes y medio su contenido es ORO PURO, y mas después del palo que ha sido conseguir, al fin...., nuestro Note y encontrate que te has metido en un callejon sin salida.
Soy miembro del foro desde hace años y estoy muy agradecido a administradores, cocineros y usuarios veteranos por toda la ayuda que me han dado, pero a veces se olvida que no todo es utilizar el buscador...., hay temas de la importancia de este, (estamos hablando que las ACTUALIZACIONES OFICIALES pueden PROVOCAR UN BRICK TOTAL del cacharro..., no es el típico brickeo por toqueteo incontrolado....) que hacen que los que mas controlais el Note debeis ser lo mas explicitos posible para ayudar a los nuevos.
Si tienes falta de tiempo me ofrezco voluntario a compactar en un post toda la info a día de hoy con los enlaces a kernels seguros, etc....en cualquier caso muchas gracias y si pudieras reconfirmar el contenido de tu post pues muchas gracias mas.

Muchas gracias por los halagos

Todo este tema está muy hablado por varios sitios, incluso hay un anuncio bien grande en el foro que avisa del riesgo de brick en ICS por culpa de los kernel
No está de más que la gente tenga miedo a trastear, ya que últimamente debido a que nos vamos confiando cada vez prestamos menos atención.
Hay muchos mas bricks todos días por gente que no se preocupa por el detalle que por el fallo este del kernel.

[RAUL TIBURCIO]

En verdad es una lastima que.esto pase en nuestro Note a perdido muchos seguidores por este tema y ya muchos nos manejamos cambiar de equipo. Por que no es solomante cuando flashea que se jode ya a varios conocido se la jodido hasta instalando cualquier aplicacion o actualizando alguna que otra y samsung no le importa ese mientras el bicho funcione para ellos es suficiente pero al que le guste trastear con el esta bien jodio por que no se puede hacer nada a menos que corras el riesgo de.quedarte sin equipo. Como que me voy a pasar al lado oscuro por lo menos se que lo que.hace lo hace.bien y sin fallas alguna.

Enviado desde mi GT-N7000 usando Tapatalk 2