Δεδομένου ότι οι πιο πρόσφατες διαρροές για τη σειρά Samsung Galaxy S2 μας έπληξαν δεξιά και αριστερά, οι άνθρωποι πηδούσαν μεταξύ ROM, κυρίως ανάμεσα σε buggy, εκδόσεις ICS πριν από την κυκλοφορία και πολύ σταθερά GB. Αυτό είναι, σε τελική ανάλυση, αυτό που κάνουμε στο XDA ως συνήθεια: Βλέπουμε μια διαρροή, την αναβοσβήνουμε, τη χρησιμοποιούμε και την τροποποιούμε. Αν δεν πετάξει, απλώς γυρνάμε πίσω. Φυσικά, υπάρχει πάντα ένας εγγενής κίνδυνος όταν αναβοσβήνουν πράγματα που δεν πρέπει να υπάρχουν στη συσκευή σας εξαρχής, αλλά ο κίνδυνος πλήρους τούβλου μιας συσκευής στη σημερινή εποχή είναι μάλλον μικρός. Ειδικά, αφού υπάρχουν διαθέσιμα εργαλεία για να επαναφέρετε τις συσκευές σας από τους νεκρούς, όπως π.χ UnBrickable Mod από τον αναγνωρισμένο προγραμματιστή XDA Elite AdamOutler.
Τούτου λεχθέντος, δεν φαίνεται να είναι όλα καλά στον κόσμο των διαρροών. Χάρη στον αναγνωρισμένο προγραμματιστή XDA Elite Εντροπία512, μάθαμε ότι οι περισσότερες συσκευές που λαμβάνουν διαρροές διατρέχουν πολύ υψηλό κίνδυνο να μην ξυπνήσουν ποτέ μετά από ένα φλας. Αποδεικνύεται ότι υπάρχει ένα σημαντικό σφάλμα στον πυρήνα ICS που έχει διαρρεύσει που επηρεάζει το
/data διαμέρισμα στο τσιπ eMMC, το οποίο προφανώς καταστρέφεται κατά τη διάρκεια ορισμένων λειτουργιών, όπως το σκούπισμα και το φλας. Αυτό αρχικά πιστευόταν ότι επηρεάζει μόνο τις λειτουργίες που εκτελούνται σε προσαρμοσμένες ανακτήσεις όπως το CWM. Ωστόσο, υπήρξαν αναφορές για σκληρά τούβλα που παράγονται από την αναλαμπή από ανακτήσεις αποθεμάτων επισης. Οι συσκευές που επηρεάζονται είναι:- Ολα Epic 4G Touch (SPH-D710) Διαρροές ICS
- Ολα Galaxy Note (GT-N7000) Διαρροές ICS
- ο AT&T Galaxy S II (SGH-I777) Διαρροή UCLD3 - και πιθανώς όλες οι άλλες
- Κορεατικές επίσημες εκδόσεις SHW-M250S/K/L και οποιοσδήποτε πυρήνας έχει δημιουργηθεί από την πηγή τους
Η Entropy και άλλοι προγραμματιστές έχουν δημοσιεύσει διάφορες προειδοποιήσεις διάσπαρτες σε όλο τον ιστότοπο, στις οποίες εξηγούν λεπτομερώς τι συμβαίνει. Η πρότασή μας είναι ότι οι χρήστες θα πρέπει να μείνουν μακριά από το ICS που αναβοσβήνει από διαρροές έως ότου επιδιορθωθεί πλήρως το σφάλμα στον πυρήνα, εκτός φυσικά εάν θέλετε να κάνετε hard brick τη συσκευή σας. Θυμηθείτε, αυτό δεν είναι κάτι που μπορεί να αναστηθεί μέσω Unbrickable Mod ή ακόμα και μέσω JTAG, καθώς πρόκειται για σφάλμα υλικολογισμικού στο eMMC. Αυτό είναι απευθείας από τον ίδιο το Entropy για όσους από εσάς ενδιαφέρεστε για λίγο περισσότερες λεπτομέρειες:
ΚΙΝΔΥΝΟΣ: Πολλοί πυρήνες διαρροής Samsung ICS ενδέχεται να βλάψουν τη συσκευή σας!
Όσοι δίνουν προσοχή στα συμβάντα με διάφορες συσκευές Samsung μπορεί να έχουν παρατηρήσει ότι ορισμένες συσκευές παρουσιάζουν μεγάλη ποσότητα σκληρών τούβλων όταν χρησιμοποιούνται πυρήνες με διαρροή ICS. Αυτά τα σκληρά τούβλα είναι ιδιαίτερα δυσάρεστα, καθώς οι προμηθευτές υπηρεσιών JTAG δεν μπόρεσαν να αναβιώσουν αυτές τις συσκευές, σε αντίθεση με τα απλά σκληρά τούβλα που προκαλούν φθορές εκκίνησης. Αυτό οφείλεται στο γεγονός ότι αυτοί οι πυρήνες στην πραγματικότητα καταφέρνουν να προκαλέσουν κάτι που φαίνεται να είναι μόνιμη βλάβη στη συσκευή αποθήκευσης eMMC.
Οι πυρήνες που επιβεβαιώνεται ότι επηρεάζονται είναι:
[*]Διαρροές ICS All Epic 4G Touch (SPH-D710)[*]Διαρροές ICS All Galaxy Note (GT-N7000)[*]Το AT&T Galaxy S II (SGH-I777) Διαρροή UCLD3 - και πιθανώς όλες οι άλλες[*] επίσημες εκδόσεις SHW-M250S/K/L της Κορέας και οποιοσδήποτε πυρήνας που δημιουργήθηκε από πηγή
Οι πυρήνες που ΠΡΕΠΕΙ να είναι ασφαλείς είναι:
[*]Διαρροές GT-I9100 ICS[*]Επίσημες εκδόσεις GT-I9100[*]Πυρήνες που δημιουργήθηκαν από την πηγαία βάση GT-I9100 Update4
Λειτουργίες που είναι πιθανό να προκαλέσουν ζημιά κατά την εκτέλεση ενός επηρεασμένου πυρήνα:
Σκούπισμα στο CWM (και πιθανώς οποιαδήποτε άλλη προσαρμοσμένη ανάκτηση) (επιβεβαιωμένο)
Επαναφορά αντιγράφου ασφαλείας Nandroid στο CWM (σκουπίζει πρώτα)
Αναβοσβήνει άλλου υλικολογισμικού στο CWM (τα περισσότερα φλας σκουπίζονται πρώτα)
Σκούπισμα σε απόθεμα Ανάκτηση 3e (ύποπτο, σκουπίζει επίσης ένα διαμέρισμα)
Διαγραφή μεγάλων αρχείων κατά την εκτέλεση ενός επηρεασμένου πυρήνα (ύποπτο αλλά όχι επιβεβαιωμένο)
Εάν έχετε επηρεασμένο πυρήνα:
Φλακάρετε αμέσως έναν γνωστό καλό πυρήνα χρησιμοποιώντας το Odin/Heimdall. ΜΗΝ χρησιμοποιείτε Mobile Odin, CWM ή οποιαδήποτε μέθοδο στη συσκευή για να αναβοσβήνει. Οι γνωστοί καλοί πυρήνες περιλαμβάνουν:
[*]Σχεδόν οποιοσδήποτε πυρήνας Gingerbread[*]Πυρήνες ICS κατασκευασμένοι από τον πηγαίο κώδικα GT-I9100 Update4
Η βασική αιτία αυτού του προβλήματος δεν έχει ακόμη προσδιοριστεί, ωστόσο, πολλοί Αναγνωρισμένοι Προγραμματιστές στο XDA υποψιάζονται ότι οφείλεται στο ότι η Samsung ενεργοποιεί μια δυνατότητα στο επηρεασμένοι πυρήνες, MMC_CAP_ERASE - Αυτή είναι μια δυνατότητα απόδοσης που μπορεί να αυξήσει σημαντικά την απόδοση εγγραφής flash, αλλά φαίνεται να αναδεικνύει ένα ελάττωμα στο φλας chipset. Οι πυρήνες GT-I9100 ICS δεν έχουν ενεργοποιημένη αυτήν τη δυνατότητα και φαίνονται ασφαλείς. Ωστόσο, δεν είναι αρκετά γνωστό για να δηλωθούν ασφαλείς όλοι οι πυρήνες χωρίς αυτό το χαρακτηριστικό - η μόνη οντότητα που μπορεί να επιβεβαιώσει τη βασική αιτία αυτό το πρόβλημα και να δηλώσετε ότι επιλύθηκε χωρίς να διακινδυνεύσετε μεγάλο (καταστρέφοντας πολλές συσκευές χωρίς τρόπο επισκευής τους) είναι η Samsung τους εαυτούς τους.
Γενικά, μέχρι νεωτέρας, εάν εκτελείτε διαρροή Samsung ICS για οποιαδήποτε συσκευή που βασίζεται σε Exynos εκτός από το GT-I9100, συνιστάται να αναβοσβήσετε κάτι άλλο.
Και αυτό μόλις εμφανίστηκε σήμερα το πρωί και στα φόρουμ μας, ευγενική προσφορά του μέλους του XDA Garwynn. Προφανώς, έχει έρθει σε επαφή με την Google και γνωρίζει το πρόβλημα και ένας μηχανικός ελπίζει να εργαστεί για μια διόρθωση.
Λοιπόν, έχει περάσει αρκετός καιρός, αλλά ευτυχώς ο κύριος Sumrall από το Android μας επισκέφτηκε για τις ερωτήσεις μας. Νομίζω ότι η κοινότητα θα διαπιστώσει ότι άξιζε την αναμονή.Πρόβλημα: το fwrev δεν έχει ρυθμιστεί σωστά.Όπως υποψιαζόμασταν, η επιδιόρθωση σφαλμάτων δεν είναι στην κατασκευή μας. (Η ενημέρωση κώδικα το εφαρμόζει άνευ όρων.)Ερώτηση: Η αναθεώρηση δεν ταιριάζει με την επιδιόρθωση(Δώσε τη δική μου έμφαση με κόκκινο καθώς συζητά το υπερτούβλο θέμα.)Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Κεν Σάμραλ
Η ενημερωμένη έκδοση κώδικα περιλαμβάνει μια γραμμή στο mmc.c με ρύθμιση fwrev στα bit δικαιωμάτων από τον καταχωρητή cid. Πριν από αυτήν την ενημερωμένη έκδοση κώδικα, το αρχείο /sys/class/block/mmcblk0/device/fwrev δεν είχε αρχικοποιηθεί από το CID για συσκευές emmc rev 4 και μεγαλύτερες, και έτσι έδειξε μηδέν.(Σε δεύτερη έρευνα)Το fwrev είναι μηδέν μέχρι να εφαρμοστεί το έμπλαστρο.
Ερώτηση: Γιατί το διαμέρισμα /data;Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Κεν Σάμραλ
Μάλλον έχεις το σφάλμα, αλλά το rev 0x19 ήταν μια προηγούμενη έκδοση του υλικολογισμικού που είχαμε στις πρωτότυπες συσκευές μας, αλλά διαπιστώσαμε ότι είχε ένα άλλο σφάλμα που αν εξέδωσε μια εντολή διαγραφής mmc, θα μπορούσε να βιδώσει τις δομές δεδομένων στο τσιπ και να οδηγήσει στο κλείδωμα της συσκευής μέχρι να ενεργοποιηθεί ποδήλατο. Αυτό το ανακαλύψαμε όταν πολλοί από τους προγραμματιστές μας έκαναν μια γρήγορη εκκίνηση διαγραφής δεδομένων χρήστη ενώ αναπτύσσαμε το ICS. Έτσι, η Samsung διόρθωσε το πρόβλημα και μετακόμισε στην έκδοση υλικολογισμικού 0x25.Ναι, είναι πολύ ενοχλητικό ότι το 0x19 είναι δεκαδικό 25 και αυτό οδήγησε σε μεγάλη σύγχυση κατά την προσπάθεια διάγνωσης προβλημάτων υλικολογισμικού emmc. Τελικά έμαθα να _ΠΑΝΤΑ_ αναφέρεται στην έκδοση emmc σε δεκαεξαδικό και να προηγείται του αριθμού με το 0x για να είναι ξεκάθαρο.Ωστόσο, παρόλο που το 0x19 έχει πιθανώς το σφάλμα που μπορεί να εισάγει 32 Kbyte μηδενικών στο φλας, δεν μπορείτε να χρησιμοποιήσετε αυτήν την ενημέρωση κώδικα σε συσκευές με αναθεώρηση υλικολογισμικού 0x19. Αυτή η ενημερωμένη έκδοση κώδικα κάνει μια πολύ συγκεκριμένη παραβίαση σε δύο byte κώδικα στο υλικολογισμικό της αναθεώρησης 0x25 και η ενημέρωση κώδικα πιο πιθανότατα δεν θα λειτουργήσει σε 0x19 και πιθανότατα θα προκαλέσει δυσλειτουργία του τσιπ στην καλύτερη περίπτωση και απώλεια δεδομένων στο κατισχύω. Υπάρχει λόγος που τα κριτήρια επιλογής είναι τόσο αυστηρά για την εφαρμογή αυτής της ενημέρωσης κώδικα στο υλικολογισμικό emmc.Έδωσα τα αποτελέσματά μας λίγες μέρες αργότερα αναφέροντας ότι το σύστημα αρχείων δεν ήταν κατεστραμμένο μέχρι το σκούπισμα. Αυτή είναι μια απάντηση σε αυτή τη συνέχεια.Όπως ανέφερα στην προηγούμενη ανάρτηση, το firmware rev 0x19 έχει ένα σφάλμα όπου το τσιπ emmc μπορεί να κλειδώσει αφού δοθεί μια εντολή διαγραφής. Όχι κάθε φορά, αλλά αρκετά συχνά. Συνήθως, η συσκευή μπορεί να επανεκκινήσει μετά από αυτό, αλλά στη συνέχεια να κλειδώσει κατά τη διαδικασία εκκίνησης. Πολύ σπάνια, μπορεί να κλειδώσει ακόμα και πριν φορτωθεί το fastboot. Ο δοκιμαστής σας ήταν άτυχος. Δεδομένου ότι δεν μπορείτε καν να ξεκινήσετε το fastboot, η συσκευή είναι πιθανώς bricked. :-( Αν μπορούσε να τρέξει fastboot, τότε η συσκευή θα μπορούσε πιθανώς να ανακτηθεί με τον κωδικό ενημέρωσης υλικολογισμικού που έχω, υποθέτοντας ότι μπορώ να τον κοινοποιήσω. Θα ρωτήσω.
Ερώτηση: Γιατί το JTAG δεν θα λειτουργήσει;Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Ken Sumrall (Android SE)
Επειδή το /data είναι το μέρος του τσιπ που έχει τη μεγαλύτερη δραστηριότητα εγγραφής. Το /system δεν εγγράφεται ποτέ στο (εκτός από μια ενημέρωση συστήματος) και το /cache χρησιμοποιείται σπάνια (κυρίως για λήψη OTA).
Ερώτηση: Μπορεί να επιδιορθωθεί ένα κατεστραμμένο σύστημα αρχείων (στο eMMC);Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Κεν Σάμραλ
Όπως αναφέρω παραπάνω, το υλικολογισμικό της αναθεώρησης 0x19 είχε ένα σφάλμα που μετά από μια εντολή διαγραφής emmc, θα μπορούσε να αφήσει το εσωτερικές δομές δεδομένων του τσιπ emmc σε κακή κατάσταση που προκαλούν το κλείδωμα του τσιπ όταν ήταν ένας συγκεκριμένος τομέας πρόσβαση. Η μόνη λύση ήταν να σκουπίσετε το τσιπ και να ενημερώσετε το υλικολογισμικό. Έχω κώδικα για να το κάνω αυτό, αλλά δεν ξέρω αν μπορώ να τον μοιραστώ. Θα ρωτήσω.
Έτσι, παρόλο που η επιδιόρθωση δεν ισχύει για εμάς αυτή τη στιγμή, μας δόθηκε μια εξαιρετική εικόνα για το πρόβλημα του superbrick καθώς και πληροφορίες σχετικά με μια επιδιόρθωση είναι έχει ήδη αναπτυχθεί (ελπίζουμε να το δούμε να κυκλοφορεί!). Το σφάλμα πιθανότατα ισχύει για εμάς και αν υποθέσουμε ότι έχει δοθεί η επιδιόρθωση για το υλικολογισμικό 0x19, τότε θα ισχύει για τις συσκευές μας.Σε μια πιο ελαφριά σημείωση, ήθελα να συμπεριλάβω το στενό του:Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Κεν Σάμραλ
Το e2fsck μπορεί να επιδιορθώσει το σύστημα αρχείων, αλλά συχνά τα 32 Kbyte εισήχθησαν στην αρχή μιας ομάδας μπλοκ, η οποία διέγραψε πολλά inodes, και έτσι η εκτέλεση του e2fsck συχνά θα είχε ως αποτέλεσμα την απώλεια πολλών αρχείων.
Παραθέτω, αναφορά:
Αναρτήθηκε αρχικά από Κεν Σάμραλ
Παίρνετε μια ματιά στη συναρπαστική ζωή ενός προγραμματιστή πυρήνα Android. :-) Αποδεικνύεται ότι η δουλειά είναι ως επί το πλείστον αγώνας με buggy hardware. Τουλάχιστον, αυτό φαίνεται μερικές φορές.
Μην αναβοσβήσετε οτιδήποτε ICS στις συσκευές σας μέχρι να επιλυθεί αυτό.
Θέλετε κάτι να δημοσιευτεί στην Πύλη; Επικοινωνήστε με οποιονδήποτε συγγραφέα ειδήσεων.
[Ευχαριστώ Εντροπία512 για όλη τη σκληρή δουλειά σας!!!]