Desde que las últimas filtraciones de la línea Samsung Galaxy S2 nos han afectado de izquierda a derecha, la gente ha estado saltando entre ROM, principalmente entre versiones ICS preliminares con errores y GB muy estables. Después de todo, esto es lo que hacemos en XDA como hábito: vemos una fuga, la actualizamos, la usamos y la modificamos. Si no vuela, simplemente retrocedemos. Por supuesto, siempre existe un riesgo inherente al flashear cosas que no deberían estar en su dispositivo en primer lugar, pero el riesgo de bloquear completamente un dispositivo hoy en día es bastante pequeño. Especialmente porque hay herramientas disponibles para recuperar sus dispositivos de entre los muertos, como Mod no bloqueable por Desarrollador reconocido de XDA Elite AdamOutler.
Dicho esto, no todo parece ir bien en el mundo de las filtraciones. Gracias al desarrollador reconocido de XDA Elite Entropía512, hemos aprendido que la mayoría de los dispositivos que reciben fugas corren un riesgo muy alto de no despertarse nunca después de un destello. Resulta que hay un error importante en el kernel ICS filtrado que afecta el
/data partición en el chip eMMC, que aparentemente se corrompe durante ciertas operaciones como limpiar y flashear. Originalmente se creía que esto afectaba solo a las operaciones realizadas en recuperaciones personalizadas como CWM. Sin embargo, ha habido informes de que se produjeron ladrillos duros a partir del tapajuntas de recuperaciones de acciones también. Los dispositivos afectados son:- Todo Toque 4G épico (SPH-D710) Fugas en ICS
- Todo Nota Galaxy (GT-N7000) Fugas de ICS
- El AT&T Galaxy SII (SGH-I777) Fuga de UCLD3, y probablemente todas las demás
- Lanzamientos oficiales coreanos del SHW-M250S/K/L y cualquier kernel creado a partir de su fuente
Entropy y otros desarrolladores han publicado varias advertencias repartidas por todo el sitio, en las que explican en detalle lo que está sucediendo. Nuestra sugerencia es que los usuarios se mantengan alejados de actualizar ICS debido a fugas hasta que el error en el kernel se haya solucionado por completo, a menos, por supuesto, que esté buscando bloquear su dispositivo. Recuerde, esto no es algo que pueda resucitar mediante Unbrickable Mod o incluso mediante JTAG, ya que se trata de un error de firmware en el eMMC. Esto es directamente del propio Entropy para aquellos que estén interesados en un poco más de detalle:
PELIGRO: ¡Muchos núcleos de fugas de ICS de Samsung pueden dañar su dispositivo!
Aquellos que prestan atención a lo que sucede con varios dispositivos Samsung pueden haber notado que algunos dispositivos experimentan una gran cantidad de ladrillos duros cuando se utilizan núcleos filtrados de ICS. Estos ladrillos duros son particularmente desagradables, ya que los proveedores de servicios JTAG no han podido resucitar estos dispositivos, a diferencia de los simples ladrillos duros que corrompen el gestor de arranque. Esto se debe al hecho de que estos núcleos en realidad logran causar lo que parece ser un daño permanente al dispositivo de almacenamiento eMMC.
Los granos que se confirman afectados son:
[*]Todas las fugas de ICS de Epic 4G Touch (SPH-D710)[*]Todas las fugas de ICS de Galaxy Note (GT-N7000)[*]El AT&T Galaxy S II (SGH-I777) Fuga de UCLD3, y probablemente todas las demás[*]Lanzamientos oficiales coreanos del SHW-M250S/K/L y cualquier kernel creado a partir de su fuente
Los núcleos que DEBEN ser seguros son:
[*]Fugas de ICS del GT-I9100[*]Lanzamientos oficiales del GT-I9100[*]Kernels creados a partir de la base fuente GT-I9100 Update4
Operaciones que probablemente causen daños al ejecutar un kernel afectado:
Limpieza en CWM (y probablemente cualquier otra recuperación personalizada) (confirmada)
Restaurar una copia de seguridad de Nandroid en CWM (limpiar primero)
Actualización de otro firmware en CWM (la mayoría de los flashes se borran primero)
Limpiando en stock 3e recovery (sospechoso, también limpia una partición)
Eliminar archivos grandes al ejecutar un kernel afectado (sospechado pero no confirmado)
Si tienes un kernel afectado:
Actualice inmediatamente un kernel en buen estado utilizando Odin/Heimdall. NO utilice Mobile Odin, CWM ni ningún otro método del dispositivo para flashear. Los buenos núcleos conocidos incluyen:
[*]Casi cualquier núcleo Gingerbread[*]Núcleos ICS creados a partir del código fuente GT-I9100 Update4
La causa raíz de este problema aún no se ha determinado; sin embargo, numerosos desarrolladores reconocidos en XDA sospechan que se debe a que Samsung habilitó una función en el Kernels afectados, MMC_CAP_ERASE: esta es una característica de rendimiento que puede aumentar en gran medida el rendimiento de escritura flash, pero parece resaltar una falla en la memoria flash. conjunto de chips. Los núcleos GT-I9100 ICS no tienen esta característica habilitada y parecen seguros. Sin embargo, no se sabe lo suficiente como para declarar seguros todos los núcleos sin esta característica: la única entidad que puede confirmar la causa raíz de este problema y declararlo solucionado sin correr grandes riesgos (destruir múltiples dispositivos sin forma de repararlos) es Samsung ellos mismos.
En general, hasta nuevo aviso, si está ejecutando una fuga de ICS de Samsung para cualquier dispositivo basado en Exynos que no sea el GT-I9100, se recomienda encarecidamente actualizar algo más.
Y esto también apareció esta mañana en nuestros foros, cortesía del miembro de XDA. garwynn. Aparentemente, se ha contactado a Google y están al tanto del problema, y un ingeniero espera trabajar para solucionarlo.
Bueno, ha pasado algún tiempo, pero afortunadamente el Sr. Sumrall de Android nos respondió nuestras preguntas. Creo que la comunidad encontrará que la espera valió la pena.Problema: fwrev no está configurado correctamente.Como sospechábamos, la corrección de errores no está en nuestra compilación. (El parche aplica esto incondicionalmente).Pregunta: La revisión no coincidía con la solución(El énfasis es mío en rojo, ya que analiza el tema del superladrillo).Cita:
Publicado originalmente por Ken Sumrall
El parche incluye una línea en mmc.c que configura fwrev en los bits de derechos del registro cid. Antes de este parche, el archivo /sys/class/block/mmcblk0/device/fwrev no se inicializaba desde el CID para dispositivos emmc rev 4 y superiores y, por lo tanto, mostraba cero.(En la segunda consulta)fwrev es cero hasta que se aplica el parche.
Pregunta: ¿Por qué la partición /data?Cita:
Publicado originalmente por Ken Sumrall
Probablemente tengas el error, pero la rev 0x19 era una versión anterior del firmware que teníamos en nuestros dispositivos prototipo, pero descubrimos que tenía otro error que si emitió un comando de borrado mmc, podría estropear las estructuras de datos en el chip y hacer que el dispositivo se bloquee hasta que se encienda ciclado. Descubrimos esto cuando muchos de nuestros desarrolladores estaban haciendo un arranque rápido para borrar datos de usuario mientras estábamos desarrollando ICS. Entonces Samsung solucionó el problema y pasó a la revisión de firmware 0x25.Sí, es muy molesto que 0x19 sea el decimal 25, y eso generó mucha confusión al intentar diagnosticar problemas de firmware emmc. Finalmente aprendí a _SIEMPRE_ referirme a la versión emmc en hexadecimal y anteponer el número con 0x para que no quede ambiguo.Sin embargo, aunque 0x19 probablemente tenga el error que puede insertar 32 Kbytes de ceros en la memoria flash, no puedes usar este parche en dispositivos con revisión de firmware 0x19. Este parche realiza un hack muy específico a dos bytes de código en la revisión de firmware 0x25, y el parche más probablemente no funcionará en 0x19 y, en el mejor de los casos, provocará que el chip funcione mal y pierda datos en el peor. Hay una razón por la que los criterios de selección son tan estrictos para aplicar este parche al firmware emmc.Le transmití nuestros resultados unos días después y mencioné que el sistema de archivos no se corrompió hasta el borrado. Esta es una respuesta a ese seguimiento.Como mencioné en la publicación anterior, la versión 0x19 del firmware tiene un error por el cual el chip emmc puede bloquearse después de que se da un comando de borrado. No siempre, pero sí con la suficiente frecuencia. Por lo general, el dispositivo puede reiniciarse después de esto, pero luego se bloquea durante el proceso de inicio. En muy raras ocasiones, puede bloquearse incluso antes de que se cargue fastboot. Tu probador tuvo mala suerte. Como ni siquiera puedes iniciar fastboot, es probable que el dispositivo esté bloqueado. :-( Si pudiera ejecutar fastboot, entonces el dispositivo probablemente podría recuperarse con el código de actualización de firmware que tengo, suponiendo que pueda compartirlo. Preguntare.
Pregunta: ¿Por qué JTAG no funciona?Cita:
Publicado originalmente por Ken Sumrall (Android SE)
Porque /data es el lugar donde se encuentra el chip que experimenta la mayor actividad de escritura. Nunca se escribe en /system (excepto durante una actualización del sistema) y /cache rara vez se usa (principalmente para recibir OTA).
Pregunta: ¿Se puede reparar un sistema de archivos dañado (en el eMMC)?Cita:
Publicado originalmente por Ken Sumrall
Como mencioné anteriormente, la revisión de firmware 0x19 tenía un error que después de un comando de borrado emmc, podía dejar el Estructuras de datos internas del chip emmc en mal estado que hacen que el chip se bloquee cuando se activa un sector en particular. accedido. La única solución fue borrar el chip y actualizar el firmware. Tengo un código para hacer eso, pero no sé si puedo compartirlo. Preguntare.
Entonces, si bien la solución no se aplica a nosotros en este momento, se nos ha brindado una gran información sobre el problema del superladrillo, así como información de que una solución es ya desarrollado (¡con suerte lo veremos lanzado!). Es probable que el error se aplique a nosotros y, suponiendo que se proporcione la solución para el firmware 0x19, se aplicaría a nuestros dispositivos.En una nota más ligera, quería incluir su cierre:Cita:
Publicado originalmente por Ken Sumrall
e2fsck puede reparar el sistema de archivos, pero a menudo los 32 Kbytes se insertaban al comienzo de un grupo de bloques, lo que borraba muchos inodos y, por lo tanto, ejecutar e2fsck a menudo resultaba en la pérdida de muchos archivos.
Cita:
Publicado originalmente por Ken Sumrall
Estás vislumbrando la apasionante vida de un desarrollador del kernel de Android. :-) Resulta que el trabajo consiste principalmente en luchar contra hardware con errores. Al menos eso parece a veces.
Manténgase alejado de actualizar cualquier ICS en sus dispositivos hasta que esto se haya resuelto.
¿Quieres publicar algo en el Portal? Póngase en contacto con cualquier redactor de noticias.
[Gracias Entropía512 ¡¡¡Por todo tu arduo trabajo!!!]