Ce n'est peut-être pas une solution directe à votre problème, mais je vous fais part de mes réflexions à ce sujet.
RÉPONSE COURTE
-
Il est peu probable que la RAM des systèmes embarqués soit défectueuse. Et si c'est le cas, il se peut que les solutions ne soient pas facilement disponibles, sauf si quelqu'un l'a déjà fait spécifiquement pour votre appareil.
-
Les dispositifs de stockage flash modernes gèrent eux-mêmes les mauvais blocs, les utilisateurs n'ont pas grand-chose à faire à cet égard.
Si l'un de ces deux problèmes nécessite une intervention de l'utilisateur, il est généralement temps de remplacer le téléphone.
- Cette erreur apparaît dans le journal de TRWP :
E:Invalid block device on /sdcard ext4 [][][]flags=display="Internal SD" ; symlink ', 'flags=display="Internal SD" ; symlink' , 27
- Lorsque vous essayez de changer le type de partition ou de réparer le "stockage interne" à TRWP, le message suivant s'affiche
Invalid partition selection
(peut-être à cause de 7 ?)
Pour moi, ces symptômes ressemblent à ceux d'une eMMC mourante.
BLOCS DÉFECTUEUX SUR LA RAM
Je suppose que vous parlez d'un téléphone ou d'un appareil similaire.
Les téléphones sont équipés de SoC, le module qui comprend le CPU, le GPU, la RAM, l'eMMC, le modem, le WiFi, le Bluetooth et le GPS ainsi que d'autres composants essentiels. En outre, la LPDRAM et la eMMC sont dans la plupart des cas fabriquées ensemble sous la forme d'un seul boîtier multipuce (MCP).
Cela dit, il est très peu probable que ce que vous dites se produise sur les téléphones. Sur les PC, la RAM est installée sous forme de modules indépendants qui sont susceptibles d'être endommagés physiquement et de s'user, par exemple à cause de l'humidité, de la rouille, de la poussière, des mouvements saccadés, des vibrations, des connexions desserrées, de la pression (pendant l'installation), de la chaleur (à cause de l'overclocking ou d'une mauvaise ventilation), etc. Il existe donc des outils tels que memtest86 pour vérifier régulièrement les défauts de la mémoire. Tous ces facteurs sont ignorables pour les téléphones, car la RAM est étroitement intégrée à une puce SoC de moins d'un pouce carré, en tenant compte de tous les facteurs ci-dessus.
Une autre raison possible est la défaillance électrique des circuits/composants, par exemple à la suite d'un choc électrique lors d'une soudaine panne de courant, qui rendrait l'appareil totalement inutile. Une fois de plus, cela ne semble pas très probable pour les téléphones car la RAM fait partie du SoC, donc le SoC entier devrait tomber en panne ainsi que d'autres mécanismes de protection contre les surtensions (s'il y en a).
La RAM étant une mémoire volatile, ses cellules ne sont jamais modifiées physiquement lors de la lecture/écriture de données, contrairement aux eMMC. Les eMMC étant des mémoires persistantes, les propriétés physiques des cellules de silicium changent pendant les opérations d'écriture/écriture. C'est pourquoi les eMMC ont une durée de vie limitée, alors que les RAM ne sont pas soumises à une telle limitation.
Ainsi, si la RAM est défectueuse, le plus probable est qu'elle a été fabriquée avec des défauts. La défaillance de la RAM due à la croissance de blocs défectueux n'est pas un cas courant, du moins pas plus que d'autres composants de l'appareil, mais elle ne peut pas être totalement rejetée. Alors comment la réparer ?
Puisque le matériel est géré par le noyau, la seule façon de marquer certaines adresses mémoire comme mauvaises est de faire en sorte que le noyau n'alloue pas ces adresses à un programme de l'espace utilisateur (comme on peut le faire sous Linux avec BadRAM qui modifie les sources du noyau). Et cela aussi si la mauvaise mémoire permet au périphérique de démarrer au stade du noyau. Sinon, vous devrez gérer le problème au niveau du SoC/bootloader où la RAM est initialisée après la mise sous tension (comme on peut le faire sous Linux avec GRUB et sous Windows avec BCD ). C'est définitivement impossible sur les téléphones depuis les chargeurs de démarrage sont des sources fermées . Si votre bootloader est configurable comme dans le cas des cartes de développement, c'est une exception. Mais dans chaque cas, vous devez probablement passer par des milliers de lignes de code.
BadRAM n'est plus maintenue après la version 2.6.28 du noyau, c'était il y a plus de 10 ans (probablement parce qu'elle n'a pas été accepté dans l'arbre du noyau principal). Vous pouvez demander au développeur s'il peut vous aider à porter le patch sur ARM (si c'est possible). Ou peut-être pouvez-vous exploit paramètres du noyau mem
et/ou memmap
d'une manière ou d'une autre pour obtenir ce que vous voulez. Encore une fois, la situation peut être très différente lorsqu'il n'y a pas d'argent. ACPI et pas de BIOS. Personnellement, je n'ai jamais rencontré une telle situation pour les téléphones portables.
BLOCS DÉFECTUEUX SUR LE STOCKAGE
Pour en venir à l'autre point, la réparation des blocs défectueux n'a de sens que pour les disques durs ou, au maximum, pour les anciens disques NAND bruts. ( réf. ) . Les disques durs ont un mappage linéaire entre LBA et CHS, ce qui signifie qu'un système de fichiers sait à quel emplacement physique les données sont écrites. Les périphériques de stockage modernes à mémoire flash (y compris les eMMC, les cartes SD et les SSD) possèdent un contrôleur de micrologiciel intégré appelé Flash Translation Layer (FTL). FTL gère le mappage LBA vers PBA, ce que le système de fichiers et le système d'exploitation ignorent totalement. En tant que stratégie de réduction de l'usure, la FTL n'effectue pas de mappage séquentiel et le mappage est dynamique. Le premier LBA peut correspondre au dernier PBA et le dernier LBA peut pointer quelque part au milieu, ce qui change continuellement avec le Garbage Collection.
FTL scanne également et garde la trace de tous les mauvais secteurs (plus spécifiquement les cellules de silicium) et remappe les bits usés de l'espace surprovisionné (en quelque sorte libre) si nécessaire. Les systèmes de fichiers n'identifieront jamais un secteur défectueux, à moins que la limite des cycles E/P de la mémoire flash ne soit atteinte et qu'elle ne commence à se comporter bizarrement, à devenir en lecture seule et, en fin de compte, à ne plus être disponible. crashs . Même si un logiciel acheté identifie un secteur mauvais, vous ne pouvez pas le marquer comme non attribuable ; font référence à la nature dynamique du mappage LBA vers PBA. Vous marquez un secteur mauvais dans le système de fichiers et après quelques minutes, il sera déplacé vers une autre partition.
Les disques durs ne meurent généralement pas d'un coup. Leur micrologiciel intégré maintient une liste ( Liste G ) de mauvais secteurs depuis le jour de la fabrication ( réf. ) . Les LBA correspondant aux secteurs défectueux sont remplacés par des secteurs de réserve que chaque disque dur possède. Une fois que le pool de secteurs de rechange est épuisé, tous les nouveaux secteurs défectueux (éventuellement partiellement) sont exposés au système d'exploitation/système de fichiers. Ainsi, lorsqu'un programme comme chkdsk
, e2fsck
o badblocks
identifie un secteur défectueux, il peut le gérer au niveau du système d'exploitation ou le faire marquer comme défectueux par le micrologiciel du disque dur. Cité par aquí :
Si vous donnez la permission d'écraser un secteur défectueux, SeaTools tentera d'écrire un motif de zéros sur ce secteur. En général, cette action aide le microprogramme du lecteur de disque à gérer le problème en retirant la LBA problématique et en activant une LBA de rechange à sa place.
C'est ce que hdparm --write-sector
fait.
La plupart des systèmes de fichiers peuvent également maintenir une liste de mauvais secteurs à ignorer pendant les opérations de lecture/écriture. Par exemple sur ext4, dumpe2fs -b
montre une liste de mauvais blocs réservés dans l'inode de mauvais bloc.
La plupart des disques durs (ainsi que les disques SSD) sont aussi construits avec SMART pour surveiller la santé des appareils, mais pas les eMMC. Dans le cas des eMMC, la seule chose e2fsck
permet d'identifier les erreurs dans le système de fichiers (et éventuellement de les réparer en utilisant, par exemple, des informations provenant de Jornal), et non dans la mémoire flash. Tous les systèmes d'exploitation, y compris Android, vérifient le système de fichiers au démarrage avant le montage, de sorte qu'une vérification manuelle n'est pas nécessaire.