S3 Muerte Súbita: ¿Por qué? [Técnico]
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)
Código:
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:
Código:
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:
Código:
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)
Código:
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:
Código:
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.
