S3 Muerte Súbita: ¿Por qué? [Técnico]

[Adelaiglesia]

Lo he colocado aquí porque no me encaja en desarrollo, si no lo consideran bien ubicado, muévanlo a donde les parezca oportuno.

Como todo en esta vida, creo que a todos nos gustaría entender qué está pasando con las eMMCs de nuestros S3, y que ha hecho Samsung al respecto. Aquí es donde entra en juego este post.

Pues bien, voy a intentar explicar a que se debe el error, y como lo ha arreglado Samsung. En primer lugar, deciros que es muy difícil leer, en primer lugar el ARM descompilado del kernel, y en segundo lugar, el dump de la RAM del MMC. Así que no estoy seguro al 100% que lo que digo sea cierto, sin embargo si estoy casi seguro al 99.9999%. Leer un DUMP de una RAM es muy complicado.

Asi que, ¿Qué pasa?

En primer lugar nos vamos al parche del firmware para el eMMC que publicó Samsung y encontramos lo siguiente:

(Ver el parche completo)

    if (!strncmp(host->card->cid.prod_name, "VTU00M", 6) &&
        (host->card->cid.prod_rev == 0xf1) &&
        (mmc_start_movi_smart(host->card) == 0x2))
        host->card->movi_ops = 0x2;
 
    if (host->card->movi_ops == 0x2) {
        err = mmc_start_movi_operation(host->card);
        if (err) {
            pr_warning("%s: movi operation is failed\n",
                            mmc_hostname(host));
            goto remove_card;
        }
    }

Esto viene a significar en castellano de cervantes, que cada vez que se encuentra la MMC "VTU00M" con la revisión 0xf1 (La problemática), se lee un Smart report. ¿Qué es un Smart report? Si nos vamos a la documentación de Samsung sobre el chip, nos dice que (página 12) "Samsung provee la herramienta Smart Report para que el cliente se de cuenta de el estado del dispositivo ante un error". Esta funcionalidad está indicada para corregir errores en el desarrollo del controlador de la tarjeta. Pues buen, si estos datos se cumplen, esto nos lleva a la función int mmc_start_movi_smart(struct mmc_card *card) que está en la línea 680 hasta la 715. La vemos abreviada:

int mmc_start_movi_smart(struct mmc_card *card) {
(...)
if (date !=  0x20120413) {
err = -1;
return err;
}
(...)
}

Esto lo primero que nos dice que los chips que están defectuosos llevan fecha de firmware 13/04/2012. (Esto puede significar que si hay chips VTU00M 0xf1 que no tienen ese firmware están sanos, aunque de momento parece que no se ha visto ningún caso, de todas maneras yo avisaría para que cuando la gente lo compruebe, se fijaran en la fecha, y si no es esa, mandarles ejecutar unas cosas para comprobar). En caso de que la fecha no sea esa se lanza -1 y no se aplica el parche. En caso de que la fecha sea esa, la función devuelve 0x2 al nivel superior, por lo que se ejecuta host->card->movi_ops = 0x2;.

A continuación pasa lo siguiente: Cuando la eMMC se inicializa se ejecuta mmc_movi_cmd(card->host, 0xEFAC62EC); y mc_movi_cmd(card->host, 0x10210000);, por lo que la tarjeta entra en modo de escritura a la RAM de la misma. Ahora lo que hace es escribir en la RAM con MMC_ERASE_GROUP_START(Dirección) MMC_ERASE_GROUP_END(Valor) MMC_ERASE(0). Los dos grupos escritos son:

10B5034A9047002800D1FEE710BD0000739D0500 para la dirección 0x40300 y
E3F789FD para la 0x5C7EA

Lo que nos lleva a instrucciones ARM del tipo Thumb, cocretamente una instrucción push.

(Si os interesa aquí os dejo el juego de instrucciones Thumb de ARM)

00040300   PUSH    {R4,LR}
00040302   LDR     R2, =0x59D73
00040304   BLX     R2
00040306   CMP     R0, #0
00040308   BNE     locret_4030C
0004030A
0004030A loc_4030A   ; CODE XREF: loc_4030Aj
0004030A   Bloc_4030A
0004030C 
0004030C
0004030C locret_4030C; CODE XREF: 00040308j
0004030C   POP     {R4,PC}
0004030C

Entonces vemos que se ha escrito la posición el bloque 0x40300 de la RAM del chip. Tras extraer el DUMP de la RAM con las modificaciones del kernel pertinentes:

Nos encontramos con que en la pila de llamadas, están los manejadores de MMC24 y MMC25. Dichos handlers pertenecen a MMC_WRITE_BLOCK y MMC_WRITE_MULTIPLE_BLOCK.

Si vemos este trozo de DUMP:

0005C7DE R4, R0
0005C7E0 R0, SP, #0x1D8+1d4

Nos encontramos con el error (si previamente hemos analizado la ram, que por cuestiones de espacio no voy a pegar un dump aquí, obviamente). Lo que ocurre es que el bit que controla el wear lev cuando trata de escribir al final de la tarjeta, se pasa, devolviendo una dirección de memoria que no corresponde (por desbordamiento), y escribiendo así el bootloader = móvil que no enciende. En resumen (aunque no ocurre así exactamente) el wear, que apunta a donde debe escribir, se le va la pinza y se pone a escribir en direcciones que no existen, estas direcciones provocan que el inicio de la eMMC sea sobreescrito).

Así que un pequeño Q&A:
¿Se degrada la eMMC por tener el bug?
Después de lo visto, me atrevo a afirmar que NO. Una eMMC con el BUG no tiene motivos para estar más degradada que otra.

¿Podemos encontrar algún patrón que describa el problema?
Diría que SI (aunque no puedo confirmarlo). El patrón será teléfonos que contienen muchos datos en su memoria, y que son reescritos habitualmente. Es decir, tienes la memoria casi llena, y cambias los datos de ella de vez en cuando. Por ejemplo, la tienes a tope de música y cambias canciones por otras nuevas porque no te entran.

También entraría en este patrón la gente que no tiene la memoria muy llena, pero si la cambia a menudo. (Instala muchas roms, copia muchas cosas a la memoria interna desde el PC...)

Esto ocurre cuando el wear leveling llega al final de la eMMC, en ciertas ocasiones y tras un numero de ciclos de escrituras, se salta el final de la tarjeta, y bueno, los que lo halláis estudiado, ya sabéis que un bit que no exista en la memoria supone escribir en una parte que no quieres.


¿Debería no fallar con el parche de Samsung?
Si, debería no fallar, sin embargo el parche contiene una singularidad. Si ocurriera el bug durante el funcionamiento del dispositivo (recordemos que qué el bug ocurra desde el punto de la probabilidad es improbable) el kernel entraría en un loop infinito bloqueando el teléfono. Esto es una medida de prevención (a mi parecer). Asi que recuerda, si se te ha quedado el teléfono bloqueado durante el arranque con alguna versión parcheada, y no sabes por qué, quizás sea porque se acaba de producir el bug y el kérnel ha impedido que destroce el teléfono. La probabilidad de que esto ocurra es tan baja que porbablemente tu bloqueo sea motivo de otra cosa. Si esto ocurriera, tras in reinicio volvería a funcionar. De hecho, en estadísitca de andar por casa, esto ocurriría en 1 de cada 20 millones de encendidos, acercándose la probabilidad a 1/128 cada vez que se copian datos a la eMMC en todos los bloques tras unas 10000 lecturas de cada uno de ellos. La probabilidad de que ocurriese en uno de cada 128 reinicios (la más desfavorable) sería tras escribir 156 Teras de información en el chip. Si copiarais en la memoria 10GB al día (cosa que nadie hace) el teléfono quedaría inútil en 43 años con el BUG. Esto indicaría que la memoria moriría antes por uso que el teléfono por el bug con el fix apilcado. No toméis al pie de la letra esta estadística, por favor.

¿Qué modelos fallan?
Curiosamente, según nos indica el kernel, no fallan todos los modelos de VTU00M 0xf1, si no sólo los que tienen el firmware fecha 13/04/2012. Los de otras fechas (si existiesen) no fallarían.

[astraopc2010]

Excelente post, clarifica muchas cosas!!!! y pese a que es técnico no es difícil de entender....muy bien explicado..saludos desde chile.

[oscar.feas]

los de otras fechas si existiesen? existen y bastantes el mio es un VTU00M 0xf1 y es de noviembre el chip, y el movil de diciembre, quiere decir que no tengo peligro?

[Adelaiglesia]

 Cita: Originalmente Escrito por oscar.feas

los de otras fechas si existiesen? existen y bastantes el mio es un VTU00M 0xf1 y es de noviembre el chip, y el movil de diciembre, quiere decir que no tengo peligro?

Supuestamente (y estoy convencido de ello) no, pero no te lo puedo asegurar porque mi certeza depende del fix que ha realizado Samsung. Yo diría que NO.

[astraopc2010]

 Cita: Originalmente Escrito por oscar.feas

los de otras fechas si existiesen? existen y bastantes el mio es un VTU00M 0xf1 y es de noviembre el chip, y el movil de diciembre, quiere decir que no tengo peligro?

y como supiste que es de noviembre?? lo pregunto porque se ha dicho reiteradamente que la fecha que aparece al ejecutar el programa EMMC CHECK no es la que corresponde a la fecha de firmware de dicho chip, por lo tanto aunque te aparezca noviembre (como mi caso también) también podrías estar afectado.

[Adelaiglesia]

 Cita: Originalmente Escrito por astraopc2010

y como supiste que es de noviembre?? lo pregunto porque se ha dicho reiteradamente que la fecha que aparece al ejecutar el programa EMMC CHECK no es la que corresponde a la fecha de firmware de dicho chip, por lo tanto aunque te aparezca noviembre (como mi caso también) también podrías estar afectado.

Desde luego, si el eMMC checker no lee la fecha mediante el método descrito en el post, de poco va a servir. Sería contactar con el desarollador a ver de donde saca la fecha.

[oscar.feas]

aa pues si, me basaba en eso, entonces ni idea, bueno, estoy parcheado ya con la 4.1.2

[sehergar]

¿Entonces a partir de ahora todas la rom que salgan tienen que llevar el parche?

[alfvg]

Muy buen post, si señor...
Aclarado y más tranquilo aún, por si no lo estaba...

[tanyo85]

Muy buen post,me quito el sombrero si señor. Yo soy uno de los que tiene el VTU00M 0xf1 y estaba preocupado por el desgaste que pudiera haber sufrido en estos meses, pero la verdad, ojalá tengas razón y no exista tal desgaste.

[ephreon]

Me ha gustado mucho la explicación, muy entendible.

Una duda, si el eMMC Check no da la fecha del firmware, como se puede obtener?

[kikolacalle]

Muchas gracias, es un trabajo extraordinario y muy útil.

[CopyRight90]

Uau! Alucinante.... llevaba dias buscando un Post asi me has acalarado muchas cosas. Gracias!

[rcortes]

Preguntilla tonta. Aunque yo se programar, reconozco que se me queda grande el problema. ¿Es muy complicado hacer un pequeño programilla que chequee la fecha del chip?

Creo que hay gran parte del código del parche que se puede reutilizar... el problema es disponer del entorno de desarrollo adecuado.

[wiki wiki]

Te hubiera entendido más si hubieras escrito en Chino :confused::confused::confused:pero te pongo el gracias, por el curro que te has pegado!! Saludos

[jlocke]

Gracias por la descripción del problema. Muy clara a la vez que rigurosa . Otras explicaciones que hay por ahí sobre las repetidas lecturas en el chip me sonaban tan extrañas que me hacian dudar de que el bug hubiese sido cazado. Ahora estoy más tranquilo.

[revengeofdoh]

Gracias por el curro y compartirlo.

[loco_tuning]

Gracias tío, muy buena explicación +10

[kanai87]

muchas gracias, la verdad que el post esta genial.
gracias

[ThePunisher]

Muy útil el post y excelentemente explicado.