Puede que esto no sea una solución directa a tu problema, pero comparto mis ideas al respecto.
RESPUESTA CORTA
-
No es muy probable que la RAM de los sistemas embebidos esté defectuosa. Y si lo hace, es posible que las soluciones no estén disponibles fácilmente, excepto si alguien ya lo ha hecho específicamente para su dispositivo.
-
Los dispositivos de almacenamiento flash modernos gestionan los bloques defectuosos por sí mismos, los usuarios no tienen mucho que hacer en este sentido.
Si alguno de ambos problemas requiere la intervención del usuario, normalmente es el momento de sustituir el teléfono.
- Este error aparece en el registro de TRWP:
E:Invalid block device on /sdcard ext4 [][][]flags=display="Internal SD" ; symlink ', 'flags=display="Internal SD" ; symlink' , 27
- Al intentar cambiar el tipo de partición o reparar "Almacenamiento interno" en TRWP dice
Invalid partition selection (¿quizás por el 7?)
Para mí estos síntomas parecen los de una eMMC moribunda.
BLOQUES DEFECTUOSOS EN LA RAM
Supongo que se refiere a un teléfono o dispositivo similar.
Los teléfonos tienen SoCs, el módulo que incluye la CPU, la GPU, la RAM, la eMMC, el módem, el WiFi, el Bluetooth y el GPS junto con otros componentes críticos. Además, en la mayoría de los casos, la LPDRAM y la eMMC se fabrican juntas como un único paquete multichip (MCP).
Dicho esto, lo que dices es muy poco probable que ocurra en los teléfonos. En los PC, la RAM se instala como módulos independientes que son propensos a sufrir daños físicos y desgaste, por ejemplo, debido a la humedad, el óxido, el polvo, los movimientos bruscos, las vibraciones, las conexiones sueltas, la presión (durante la instalación), el calor (debido al overclocking o la ventilación inadecuada), etc. Así que hay herramientas como memtest86 para comprobar regularmente si hay fallos en la memoria. Todos estos factores son ignorables para los teléfonos porque la RAM está estrechamente integrada con un chip SoC de menos de una pulgada cuadrada, teniendo en cuenta todos los factores anteriores.
Otra posible razón es el fallo eléctrico de los circuitos/componentes, por ejemplo, debido a una descarga eléctrica en un apagón repentino que lo inutiliza por completo. Esto tampoco parece muy probable en el caso de los teléfonos, ya que la RAM forma parte del SoC, por lo que todo el SoC debería fallar junto con otros mecanismos de protección contra sobretensiones (si los hubiera).
Como la RAM es una memoria volátil, sus celdas nunca cambian físicamente mientras se leen/escriben datos, a diferencia de las eMMC. Las eMMC son un almacenamiento persistente, por lo que las propiedades físicas de las celdas de silicio cambian durante las operaciones de E/P. Por eso las eMMC tienen una vida limitada, pero las RAM no están sujetas a esa limitación.
Por lo tanto, si la RAM está defectuosa, lo más probable es que se haya fabricado con fallos. El fallo de la RAM debido al crecimiento de bloques defectuosos no es un caso común, al menos no antes que otros componentes del dispositivo, pero aún así no se puede rechazar por completo. Entonces, ¿cómo solucionarlo?
Dado que el hardware es manejado por el kernel, la única manera de marcar algunas direcciones de memoria como malas es haciendo que el kernel no asigne esas direcciones a ningún programa de espacio de usuario (como se puede hacer en Linux con BadRAM que modifica el código fuente del kernel). Y eso también si la mala memoria permite que el dispositivo arranque en la etapa del kernel. De lo contrario, tendrá que manejar el asunto en la etapa del SoC/cargador de arranque donde la RAM se está inicializando después del encendido (como se puede hacer en Linux con GRUB y en Windows con BCD ). Es definitivamente imposible en los teléfonos ya que los cargadores de arranque son de código cerrado . Si tu bootloader es configurable como en el caso de las placas de desarrollo, es una excepción. Pero en cada caso es probable que tenga que pasar por miles de líneas de código.
BadRAM ya no se mantiene después de la versión 2.6.28 del kernel, que fue hace más de 10 años (probablemente porque no fue aceptada en el árbol del núcleo principal). Puedes preguntar al desarrollador si puede ayudarte a portar el parche a ARM (si es que es posible). O tal vez usted puede explotar parámetros del núcleo mem y/o memmap de alguna manera para lograr lo que quieres. De nuevo, la situación puede ser muy diferente cuando no hay ACPI y sin BIOS. Personalmente nunca me he encontrado con esta situación en los teléfonos móviles.
BLOQUES DEFECTUOSOS EN EL ALMACÉN
Volviendo al otro punto, arreglar los bloques defectuosos sólo tiene sentido con los discos duros o, como máximo, con los antiguos discos NAND sin procesar ( ref ) . Los discos duros tienen un mapeo lineal de LBA a CHS, lo que significa que un sistema de archivos sabe en qué ubicación física se están escribiendo los datos. Los dispositivos modernos de almacenamiento de memoria flash (incluyendo eMMCs, tarjetas SD y SSDs) tienen un controlador de firmware integrado llamado Flash Translation Layer (FTL). La FTL se encarga de la asignación de LBA a PBA, que el sistema de archivos y el SO desconocen. Como estrategia de nivelación de desgaste, FTL no mapea secuencialmente y el mapeo es dinámico. El primer LBA podría corresponder al último PBA y el último LBA podría apuntar a algún lugar en el medio, cambiando continuamente con la recolección de basura.
FTL también escanea y hace un seguimiento de todos los sectores defectuosos (más concretamente de las celdas de silicio) y reasigna los bits desgastados del espacio sobreaprovisionado (tipo de libre) si es necesario. Los sistemas de archivos nunca identificarán un sector malo, a menos que llegue el momento en que se alcance el límite de ciclos E/P de la memoria flash y ésta comience a comportarse de forma extraña, se convierta en de sólo lectura y, finalmente se bloquea . Incluso si un software comprado identifica un sector malo, no puede marcarlo como no asignable ; se refieren a la naturaleza dinámica del mapeo de LBA a PBA. Usted marca un sector malo en el sistema de archivos y después de unos minutos que se trasladó a alguna otra partición.
Los discos duros no suelen morir de golpe. Su firmware incorporado mantiene una lista ( Lista G ) de sectores defectuosos desde el día de la fabricación ( ref ) . Los LBA correspondientes a los sectores defectuosos se sustituyen por los sectores de reserva que tiene cada disco duro. Una vez que el grupo de sectores de reserva se agota, cualquier sector defectuoso que aparezca (posiblemente de forma parcial) queda expuesto al sistema operativo/archivos. Así que cuando un programa como chkdsk , e2fsck o badblocks identifica un sector defectuoso, puede manejarlo a nivel del SO o hacer que sea marcado como defectuoso por el firmware del HDD. Citado de aquí :
Si da permiso para sobrescribir un sector defectuoso, SeaTools intentará escribir un patrón de ceros en ese sector. Normalmente, esta acción ayudará al firmware de la unidad de disco a gestionar el problema retirando el LBA problemático y activando un repuesto en su lugar.
Eso es lo que hdparm --write-sector lo hace.
La mayoría de los sistemas de archivos también pueden mantener una lista de sectores defectuosos para ser ignorados durante las operaciones de lectura/escritura. Por ejemplo en ext4, dumpe2fs -b muestra una lista de bloques malos reservados en el inodo de bloques malos.
La mayoría de los discos duros (así como los SSD) también se construyen con SMART para supervisar la salud del dispositivo, pero no las eMMC. En el caso de las eMMC, lo único que e2fsck hace es identificar los errores dentro del sistema de archivos (y posiblemente reparar usando, por ejemplo, la información de jornal), no en la memoria flash. Todos los sistemas operativos, incluido Android, realizan comprobaciones del sistema de archivos en el arranque antes de montarlo, por lo que no es necesaria la comprobación manual.
