Depuis que les dernières fuites concernant la gamme Samsung Galaxy S2 nous ont frappé à gauche et à droite, les gens ont sauté entre les ROM, principalement entre les bogues, les versions préliminaires d'ICS et les Go très stables. Après tout, c’est ce que nous faisons habituellement sur XDA: nous voyons une fuite, nous la flashons, nous l’utilisons et nous la peaufinons. S'il ne vole pas, nous reculons simplement. Bien sûr, il y a toujours un risque inhérent à flasher des éléments qui ne devraient pas se trouver sur votre appareil en premier lieu, mais le risque de détruire complètement un appareil de nos jours est plutôt faible. D’autant plus qu’il existe des outils pour ressusciter vos appareils d’entre les morts, comme Mod non briquable par Développeur reconnu XDA Elite AdamOutler.
Cela dit, tout ne semble pas aller pour le mieux dans le monde des fuites. Merci au développeur reconnu XDA Elite Entropie512, nous avons appris que la plupart des appareils qui subissent des fuites courent un risque très élevé de ne jamais se réveiller après un flash. Il s'avère qu'il existe un bug majeur dans le noyau ICS divulgué qui affecte le
/data partition dans la puce eMMC, qui est apparemment corrompue lors de certaines opérations telles que l'effacement et le flashage. On pensait à l'origine que cela affectait uniquement les opérations effectuées dans le cadre de récupérations personnalisées telles que CWM. Cependant, des rapports ont fait état de briques dures produites à partir des solins de récupérations de stocks aussi. Les appareils concernés sont :- Tous Épique 4G Touch (SPH-D710) Fuites ICS
- Tous Galaxy Note (GT-N7000) Fuites ICS
- Le AT&T Galaxy SII (SGH-I777) Fuite UCLD3 - et probablement toutes les autres
- Versions officielles coréennes du SHW-M250S/K/L et tout noyau construit à partir de leur source
Entropy et d'autres développeurs ont publié plusieurs avertissements dispersés sur le site, dans lesquels ils expliquent en détail ce qui se passe. Notre suggestion est que les utilisateurs devraient éviter de faire clignoter ICS en cas de fuite jusqu'à ce que le bogue dans le noyau soit complètement corrigé, à moins bien sûr que vous cherchiez à briquer votre appareil. N'oubliez pas que ce n'est pas quelque chose qui peut être ressuscité via Unbrickable Mod ou même via JTAG, car il s'agit d'une erreur de firmware dans l'eMMC. Ceci vient directement d'Entropy lui-même pour ceux d'entre vous qui sont intéressés par un peu plus de détails :
DANGER: De nombreux noyaux de fuite Samsung ICS peuvent endommager votre appareil !
Ceux qui prêtent attention aux événements sur divers appareils Samsung ont peut-être remarqué que certains appareils subissent une grande quantité de briques matérielles lorsque des noyaux ICS ayant fui sont utilisés. Ces briques matérielles sont particulièrement malveillantes, dans la mesure où les fournisseurs de services JTAG ont été incapables de ressusciter ces appareils, contrairement aux simples briques dures corrompues par le chargeur de démarrage. Cela est dû au fait que ces noyaux parviennent en réalité à causer ce qui semble être des dommages permanents au périphérique de stockage eMMC.
Les noyaux confirmés affectés sont :
[*]Fuites de tous les ICS Epic 4G Touch (SPH-D710)[*]Fuites de tous les ICS Galaxy Note (GT-N7000)[*]AT&T Galaxy S II (SGH-I777) Fuite UCLD3 - et probablement toutes les autres[*]versions officielles coréennes SHW-M250S/K/L et tout noyau construit à partir de leur source
Les noyaux qui DEVRAIENT être sûrs sont :
[*]Fuites du GT-I9100 ICS[*]Communications officielles du GT-I9100[*]Noyaux construits à partir de la base source GT-I9100 Update4
Opérations susceptibles de causer des dommages lors de l'exécution d'un noyau affecté :
Effacement dans CWM (et probablement toute autre récupération personnalisée) (confirmé)
Restauration d'une sauvegarde Nandroid dans CWM (efface d'abord)
Flasher un autre firmware dans CWM (la plupart des flashs s'effacent en premier)
Essuyage en stock 3e recovery (suspect, efface également une partition)
Suppression de fichiers volumineux lors de l'exécution d'un noyau affecté (soupçonné mais non confirmé)
Si vous avez un noyau affecté :
Flashez immédiatement un bon noyau connu en utilisant Odin/Heimdall. N'utilisez PAS Mobile Odin, CWM ou toute autre méthode sur l'appareil pour flasher. Les bons noyaux connus comprennent :
[*]Presque tous les noyaux Gingerbread[*]Noyaux ICS construits à partir du code source GT-I9100 Update4
La cause première de ce problème n'a pas encore été déterminée, cependant, de nombreux développeurs reconnus dans XDA soupçonnent que cela est dû au fait que Samsung a activé une fonctionnalité dans le noyaux concernés, MMC_CAP_ERASE - Il s'agit d'une fonctionnalité de performances qui peut augmenter considérablement les performances d'écriture flash, mais qui semble faire ressortir un défaut dans le flash. jeu de puces. Les noyaux GT-I9100 ICS n'ont pas cette fonctionnalité activée et semblent sûrs. Cependant, on n'en sait pas assez pour déclarer sûrs tous les noyaux dépourvus de cette fonctionnalité - la seule entité capable de confirmer la cause première du problème. ce problème et le déclarer résolu sans prendre de grands risques (détruire plusieurs appareils sans aucun moyen de les réparer), c'est Samsung eux-mêmes.
En général, jusqu'à nouvel ordre, si vous effectuez une fuite Samsung ICS pour un appareil basé sur Exynos autre que le GT-I9100, il est fortement conseillé de flasher autre chose.
Et cela est également apparu ce matin sur nos forums, gracieuseté du membre XDA. garwynn. Apparemment, Google a été contacté et est au courant du problème, et un ingénieur espère trouver un correctif.
Eh bien, cela fait un certain temps, mais heureusement, M. Sumrall d'Android nous a répondu à nos questions. Je pense que la communauté constatera que cela valait la peine d'attendre.Problème: fwrev n'est pas défini correctement.Comme nous le soupçonnions, la correction du bug n'est pas dans notre version. (Le correctif l'applique sans condition.)Question: La révision ne correspond pas au correctif(C'est moi qui souligne en rouge car il aborde le problème de la superbe brique.)Citation:
Publié à l'origine par Ken Sumrall
Le correctif inclut une ligne dans mmc.c définissant fwrev sur les bits de droits du registre cid. Avant ce correctif, le fichier /sys/class/block/mmcblk0/device/fwrev n'était pas initialisé à partir du CID pour les appareils emmc rev 4 et supérieur, et affichait donc zéro.(Sur deuxième enquête)fwrev est nul jusqu'à ce que le correctif soit appliqué.
Question: Pourquoi la partition /data ?Citation:
Publié à l'origine par Ken Sumrall
Vous avez probablement le bug, mais la version 0x19 était une version précédente du micrologiciel que nous avions dans nos prototypes d'appareils, mais nous avons découvert qu'il y avait un autre bug qui a émis une commande d'effacement mmc, cela pourrait gâcher les structures de données dans la puce et conduire au verrouillage de l'appareil jusqu'à ce qu'il soit alimenté fait du vélo. Nous avons découvert cela lorsque beaucoup de nos développeurs effectuaient un effacement rapide des données utilisateur pendant que nous développions ICS. Samsung a donc résolu le problème et est passé à la révision 0x25 du micrologiciel.Oui, il est très ennuyeux que 0x19 soit un nombre décimal de 25, ce qui a conduit à beaucoup de confusion lors de la tentative de diagnostic des problèmes du micrologiciel emmc. J'ai finalement appris à _TOUJOURS_ faire référence à la version emmc en hexadécimal et à faire précéder le nombre de 0x juste pour être sans ambiguïté.Cependant, même si 0x19 a probablement le bug qui peut insérer 32 Ko de zéros dans le flash, vous ne pouvez pas utiliser ce correctif sur les appareils dotés de la révision 0x19 du micrologiciel. Ce patch effectue un hack très spécifique de deux octets de code dans la révision 0x25 du firmware, et le patch le plus ne fonctionnera probablement pas sur 0x19, et entraînera probablement au mieux un dysfonctionnement de la puce et une perte de données à pire. Il y a une raison pour laquelle les critères de sélection sont si stricts pour appliquer ce correctif au firmware emmc.J'ai transmis nos résultats quelques jours plus tard en mentionnant que le système de fichiers n'avait pas été corrompu jusqu'à l'effacement. Ceci est une réponse à ce suivi.Comme je l'ai mentionné dans le post précédent, la version 0x19 du firmware présente un bug qui empêche la puce emmc de se bloquer après qu'une commande d'effacement soit donnée. Pas à chaque fois, mais assez souvent. Habituellement, l'appareil peut redémarrer après cela, mais se bloque ensuite pendant le processus de démarrage. Très rarement, il peut se bloquer avant même le chargement de Fastboot. Votre testeur n'a pas eu de chance. Comme vous ne pouvez même pas démarrer Fastboot, l'appareil est probablement maçonné. :-( S'il pouvait lancer fastboot, alors l'appareil pourrait probablement être récupéré avec le code de mise à jour du micrologiciel dont je dispose, en supposant que je puisse le partager. Je demanderai.
Question: Pourquoi JTAG ne fonctionne pas ?Citation:
Publié à l'origine par Ken Sumrall (Android SE)
Parce que /data est l'endroit où la puce subit le plus d'activité d'écriture. /system n'est jamais écrit (sauf lors d'une mise à jour du système) et /cache est rarement utilisé (principalement pour recevoir des OTA).
Question: Un système de fichiers corrompu peut-il être réparé (sur l'eMMC) ?Citation:
Publié à l'origine par Ken Sumrall
Comme je l'ai mentionné ci-dessus, le firmware de révision 0x19 avait un bug qui, après une commande d'effacement emmc, pouvait quitter le structures de données internes de la puce emmc dans un mauvais état qui provoquent le verrouillage de la puce lorsqu'un secteur particulier était accédé. La seule solution consistait à effacer la puce et à mettre à jour le firmware. J'ai du code pour faire ça, mais je ne sais pas si je peux le partager. Je demanderai.
Ainsi, même si le correctif ne s'applique pas à nous pour le moment, nous avons reçu un excellent aperçu du problème de la superbe brique ainsi que des informations sur la possibilité d'un correctif. est déjà développé (j'espère que nous le verrons sortir !). Le bug s'applique probablement à nous et en supposant que le correctif pour le micrologiciel 0x19 soit fourni, il s'appliquerait à nos appareils.Sur une note plus légère, je voulais inclure sa clôture :Citation:
Publié à l'origine par Ken Sumrall
e2fsck peut réparer le système de fichiers, mais souvent les 32 Ko étaient insérés au début d'un groupe de blocs, ce qui effaçait de nombreux inodes, et ainsi exécuter e2fsck entraînait souvent la perte de nombreux fichiers.
Citation:
Publié à l'origine par Ken Sumrall
Vous avez un aperçu de la vie passionnante d'un développeur de noyau Android. :-) Il s'avère que le travail consiste principalement à se battre avec du matériel bogué. Du moins, cela semble être le cas parfois.
Veuillez éviter de flasher quoi que ce soit d'ICS sur vos appareils jusqu'à ce que le problème soit résolu.
Vous voulez quelque chose publié sur le portail? Contactez n’importe quel rédacteur de nouvelles.
[Merci Entropie512 pour tout votre travail acharné !!!]