Seit die neuesten Leaks zur Samsung Galaxy S2-Reihe uns überall treffen, wechseln die Leute zwischen ROMs, hauptsächlich zwischen fehlerhaften ICS-Builds vor der Veröffentlichung und sehr stabilen GB. Das ist schließlich das, was wir auf XDA aus Gewohnheit tun: Wir sehen ein Leck, flashen es, verwenden es und optimieren es. Wenn es nicht fliegt, rollen wir einfach zurück. Natürlich birgt das Flashen von Dingen, die eigentlich gar nicht auf Ihrem Gerät sein sollten, immer ein gewisses Risiko, aber das Risiko, ein Gerät völlig kaputt zu machen, ist heutzutage eher gering. Vor allem, da es Tools gibt, mit denen Sie Ihre Geräte von den Toten zurückholen können, wie z UnBrickable Mod von XDA Elite Recognised Developer AdamOutler.
Allerdings scheint in der Welt der Leaks nicht alles in Ordnung zu sein. Vielen Dank an XDA Elite Recognised Developer Entropie512, haben wir erfahren, dass bei den meisten Geräten, bei denen Lecks auftreten, ein sehr hohes Risiko besteht, dass sie nach einem Blitz nie wieder aufwachen. Es stellt sich heraus, dass es einen großen Fehler im geleakten ICS-Kernel gibt, der das betrifft
/data Partition im eMMC-Chip, die offenbar bei bestimmten Vorgängen wie Löschen und Flashen beschädigt wird. Ursprünglich ging man davon aus, dass dies nur Vorgänge betrifft, die in benutzerdefinierten Wiederherstellungen wie CWM ausgeführt werden. Es gab jedoch Berichte darüber, dass aus dem Anschlussblech harte Ziegel hergestellt wurden Bestandserholungen sowie. Die betroffenen Geräte sind:- Alle Episches 4G Touch (SPH-D710) ICS-Lecks
- Alle Galaxy Note (GT-N7000) ICS-Lecks
- Der AT&T Galaxy S II (SGH-I777) UCLD3-Leck – und wahrscheinlich alle anderen
- Offizielle koreanische SHW-M250S/K/L-Veröffentlichungen und alle aus ihrer Quelle erstellten Kernel
Entropy und andere Entwickler haben auf der gesamten Website mehrere Warnungen veröffentlicht, in denen sie detailliert erklären, was passiert. Unser Vorschlag ist, dass Benutzer vom Flashen von ICS aufgrund von Leaks fernbleiben sollten, bis der Fehler im Kernel vollständig behoben wurde, es sei denn, Sie möchten Ihr Gerät hart blockieren. Denken Sie daran, dass dies nicht über Unbrickable Mod oder sogar über JTAG wiederhergestellt werden kann, da es sich um einen Firmware-Fehler im eMMC handelt. Dies ist direkt von Entropy selbst für diejenigen unter Ihnen, die sich für etwas mehr Details interessieren:
GEFAHR: Viele Samsung ICS-Leak-Kernel können Ihr Gerät beschädigen!
Diejenigen, die das Geschehen bei verschiedenen Samsung-Geräten beobachten, haben möglicherweise bemerkt, dass bei einigen Geräten eine große Menge an Hardbricks auftritt, wenn ICS-geleakte Kernel verwendet werden. Diese Hardbricks sind besonders schädlich, da es den Anbietern von JTAG-Diensten im Gegensatz zu einfachen Hardbricks, die den Bootloader beschädigen, nicht gelungen ist, diese Geräte wiederzubeleben. Dies liegt daran, dass es diesen Kerneln tatsächlich gelingt, scheinbar dauerhafte Schäden am eMMC-Speichergerät zu verursachen.
Bestätigt sind folgende Kernel betroffen:
[*]Alle Epic 4G Touch (SPH-D710) ICS-Lecks[*]Alle Galaxy Note (GT-N7000) ICS-Lecks[*]Das AT&T Galaxy S II (SGH-I777) UCLD3-Leck – und wahrscheinlich alle anderen[*]offiziellen koreanischen SHW-M250S/K/L-Veröffentlichungen und alle darauf basierenden Kernel Quelle
Kernel, die sicher sein sollten, sind:
[*]GT-I9100 ICS-Lecks[*]Offizielle GT-I9100-Veröffentlichungen[*]Kernel, die auf der GT-I9100 Update4-Quellbasis basieren
Vorgänge, die beim Ausführen eines betroffenen Kernels wahrscheinlich Schaden anrichten:
Löschen in CWM (und wahrscheinlich jeder anderen benutzerdefinierten Wiederherstellung) (bestätigt)
Wiederherstellen eines Nandroid-Backups in CWM (zuerst löschen)
Flashen einer anderen Firmware in CWM (die meisten Flashes werden zuerst gelöscht)
Löschen in der Stock 3e-Wiederherstellung (vermutlich wird auch eine Partition gelöscht)
Löschen großer Dateien beim Ausführen eines betroffenen Kernels (vermutet, aber nicht bestätigt)
Wenn Sie einen betroffenen Kernel haben:
Flashen Sie sofort einen bekanntermaßen guten Kernel mit Odin/Heimdall. Verwenden Sie zum Flashen NICHT Mobile Odin, CWM oder eine andere Methode auf dem Gerät. Zu den bekanntermaßen guten Kerneln gehören:
[*]Fast alle Gingerbread-Kernel[*]ICS-Kernel, die aus dem GT-I9100 Update4-Quellcode erstellt wurden
Die Grundursache für dieses Problem muss noch ermittelt werden. Zahlreiche anerkannte Entwickler in XDA vermuten jedoch, dass es darauf zurückzuführen ist, dass Samsung eine Funktion im XDA aktiviert hat Betroffene Kernel, MMC_CAP_ERASE – Dies ist eine Leistungsfunktion, die die Flash-Schreibleistung erheblich steigern kann, aber offenbar einen Fehler im Flash hervorruft Chipsatz. GT-I9100 ICS-Kernel haben diese Funktion nicht aktiviert und scheinen sicher zu sein. Es ist jedoch nicht genug bekannt, um alle Kernel ohne diese Funktion als sicher zu deklarieren – die einzige Entität, die die Grundursache dafür bestätigen kann Dieses Problem zu beheben und es ohne großes Risiko für behoben zu erklären (Zerstörung mehrerer Geräte ohne Möglichkeit, sie zu reparieren), ist Samsung sich.
Im Allgemeinen wird bis auf weiteres dringend empfohlen, etwas anderes zu flashen, wenn bei Ihnen ein Samsung ICS-Leck für ein anderes Exynos-basiertes Gerät als das GT-I9100 auftritt.
Und dies ist heute Morgen auch in unseren Foren aufgetaucht, mit freundlicher Genehmigung eines XDA-Mitglieds garwynn. Anscheinend wurde Google kontaktiert und ist sich des Problems bewusst, und ein Techniker hofft, auf eine Lösung hinzuarbeiten.
Nun, es ist einige Zeit her, aber zum Glück hat Herr Sumrall von Android auf unsere Fragen geantwortet. Ich denke, die Community wird feststellen, dass sich das Warten gelohnt hat.Problem: fwrev ist nicht richtig eingestellt.Wie wir vermutet haben, ist der Bugfix nicht in unserem Build enthalten. (Der Patch wendet dies bedingungslos an.)Frage: Die Revision stimmte nicht mit dem Fix überein(Hervorhebung von mir in Rot, da es um die Superziegel-Thematik geht.)Zitat:
Ursprünglich gepostet von Ken Sumrall
Der Patch enthält eine Zeile in mmc.c, die fwrev auf die Rechtebits aus dem CID-Register setzt. Vor diesem Patch wurde die Datei /sys/class/block/mmcblk0/device/fwrev nicht von der CID für emmc-Geräte Version 4 und höher initialisiert und zeigte daher Null an.(Auf zweite Anfrage)fwrev ist Null, bis der Patch angewendet wird.
Frage: Warum die /data-Partition?Zitat:
Ursprünglich gepostet von Ken Sumrall
Du hast wahrscheinlich den Fehler, Rev 0x19 war jedoch eine frühere Version der Firmware, die wir in unseren Prototypgeräten hatten. Wir haben jedoch festgestellt, dass sie einen weiteren Fehler aufwies Wenn Sie einen MMC-Löschbefehl ausgeben, könnte dies die Datenstrukturen im Chip beschädigen und dazu führen, dass das Gerät blockiert, bis es mit Strom versorgt wird geradelt. Wir haben dies entdeckt, als viele unserer Entwickler während der Entwicklung von ICS einen Fastboot-Löschvorgang für Benutzerdaten durchführten. Also hat Samsung das Problem behoben und auf die Firmware-Revision 0x25 umgestellt.Ja, es ist sehr ärgerlich, dass 0x19 eine Dezimalzahl von 25 ist, und das führte zu großer Verwirrung bei der Diagnose von emmc-Firmware-Problemen. Endlich habe ich gelernt, mich _IMMER_ auf die emmc-Version im Hexadezimalformat zu beziehen und der Zahl 0x voranzustellen, nur um eindeutig zu sein.Jedoch, obwohl 0x19 wahrscheinlich den Fehler hat, der 32 KByte Nullen in den Flash einfügen kann, können Sie diesen Patch nicht auf Geräten mit der Firmware-Revision 0x19 verwenden. Dieser Patch führt einen sehr spezifischen Hack auf zwei Codebytes in der Firmware-Revision 0x25 durch, und zwar den Patch am meisten Funktioniert wahrscheinlich nicht unter 0x19 und führt wahrscheinlich bestenfalls zu einer Fehlfunktion des Chips und zu Datenverlust am schlimmsten. Es gibt einen Grund, warum die Auswahlkriterien für die Anwendung dieses Patches auf die emmc-Firmware so streng sind.Ein paar Tage später gab ich unsere Ergebnisse weiter und erwähnte, dass das Dateisystem bis zum Löschvorgang nicht beschädigt wurde. Dies ist eine Antwort auf dieses Follow-up.Wie ich im vorherigen Beitrag erwähnt habe, weist die Firmware-Version 0x19 einen Fehler auf, bei dem der EMMC-Chip abstürzen kann, nachdem ein Löschbefehl gegeben wurde. Nicht jedes Mal, aber oft genug. Normalerweise kann das Gerät danach neu starten, stürzt dann aber während des Startvorgangs ab. In sehr seltenen Fällen kann es zu einem Absturz kommen, noch bevor Fastboot geladen wird. Ihr Tester hatte Pech. Da Sie Fastboot nicht einmal starten können, ist das Gerät wahrscheinlich kaputt. :-( Wenn er Fastboot ausführen könnte, dann könnte das Gerät wahrscheinlich mit dem Firmware-Update-Code, den ich habe, wiederhergestellt werden, vorausgesetzt, ich kann ihn weitergeben. Ich werde fragen.
Frage: Warum funktioniert JTAG nicht?Zitat:
Ursprünglich gepostet von Ken Sumrall (Android SE)
Denn /data ist der Chip, der die meiste Schreibaktivität erfährt. /system wird nie beschrieben (außer während einer Systemaktualisierung) und /cache wird selten verwendet (hauptsächlich zum Empfangen von OTAs).
Frage: Kann ein beschädigtes Dateisystem repariert werden (auf der eMMC)?Zitat:
Ursprünglich gepostet von Ken Sumrall
Wie ich oben erwähnt habe, hatte die Firmware der Revision 0x19 einen Fehler, der dazu führen konnte, dass sie nach einem EMMC-Löschbefehl die Datei verlassen konnte Interne Datenstrukturen des EMMC-Chips in einem fehlerhaften Zustand, der dazu führt, dass der Chip blockiert, wenn ein bestimmter Sektor vorhanden ist zugegriffen. Die einzige Lösung bestand darin, den Chip zu löschen und die Firmware zu aktualisieren. Ich habe Code dafür, weiß aber nicht, ob ich ihn teilen kann. Ich werde fragen.
Auch wenn der Fix derzeit nicht auf uns zutrifft, haben wir einen tollen Einblick in das Superbrick-Problem sowie Informationen zu einem Fix erhalten Ist bereits entwickelt (hoffentlich wird es veröffentlicht!). Der Fehler trifft wahrscheinlich auf uns zu, und wenn wir davon ausgehen, dass die Firmware 0x19 behoben ist, würde er auch auf unsere Geräte zutreffen.In einer etwas leichteren Form wollte ich seinen Abschluss einbeziehen:Zitat:
Ursprünglich gepostet von Ken Sumrall
e2fsck kann das Dateisystem reparieren, aber oft wurden die 32 KByte am Anfang einer Blockgruppe eingefügt, wodurch viele Inodes gelöscht wurden und die Ausführung von e2fsck daher oft dazu führte, dass viele Dateien verloren gingen.
Zitat:
Ursprünglich gepostet von Ken Sumrall
Sie erhalten einen Einblick in das aufregende Leben eines Android-Kernel-Entwicklers. :-) Es stellt sich heraus, dass der Job hauptsächlich darin besteht, mit fehlerhafter Hardware zu kämpfen. Zumindest scheint es manchmal so.
Bitte vermeiden Sie das Flashen von ICS auf Ihren Geräten, bis das Problem behoben ist.
Möchten Sie etwas im Portal veröffentlichen? Kontaktieren Sie einen beliebigen Nachrichtenautor.
[Danke Entropie512 für all deine harte Arbeit!!!]