Da quando le ultime indiscrezioni sulla linea Samsung Galaxy S2 ci hanno colpito a destra e sinistra, le persone sono passate da una ROM all'altra, principalmente tra build ICS pre-release buggate e GB molto stabili. Dopotutto, questo è ciò che facciamo su XDA come abitudine: vediamo una perdita, la mostriamo, la usiamo e la ottimizziamo. Se non vola, semplicemente torniamo indietro. Naturalmente, c'è sempre un rischio intrinseco nel flashare cose che non dovrebbero essere sul tuo dispositivo in primo luogo, ma il rischio di murare completamente un dispositivo al giorno d'oggi è piuttosto piccolo. Soprattutto perché sono disponibili strumenti per riportare in vita i tuoi dispositivi, come ad esempio Mod UnBrickable dallo sviluppatore riconosciuto XDA Elite AdamOutler.
Detto questo, non tutto sembra andare bene nel mondo dei leak. Grazie allo sviluppatore riconosciuto XDA Elite Entropia512, abbiamo appreso che la maggior parte dei dispositivi che subiscono perdite corrono un rischio molto elevato di non riattivarsi mai dopo un lampo. Si scopre che c'è un grosso bug nel kernel ICS trapelato che colpisce il file
/data partizione nel chip eMMC, che apparentemente viene danneggiata durante alcune operazioni come la cancellazione e il flashing. Inizialmente si riteneva che ciò interessasse solo le operazioni eseguite nei ripristini personalizzati come CWM. Tuttavia, ci sono state segnalazioni di mattoni duri prodotti dalla scossalina recuperi di titoli anche. I dispositivi interessati sono:- Tutto Tocco epico 4G (SPH-D710) Perdite ICS
- Tutto Galaxy Nota (GT-N7000) Perdite dell'ICS
- IL AT&TGalaxy S II (SGH-I777) Perdita UCLD3 - e probabilmente tutte le altre
- Versioni ufficiali coreane SHW-M250S/K/L e qualsiasi kernel creato dalla relativa sorgente
Entropy e altri sviluppatori hanno pubblicato diversi avvisi sparsi in tutto il sito, in cui spiegano in dettaglio cosa sta succedendo. Il nostro suggerimento è che gli utenti dovrebbero evitare di eseguire il flashing di ICS in caso di perdite finché il bug nel kernel non sarà stato completamente risolto, a meno che, ovviamente, non si stia cercando di eseguire l'hard brick del proprio dispositivo. Ricorda, questo non è qualcosa che può essere resuscitato tramite Unbrickable Mod o anche tramite JTAG, poiché si tratta di un errore del firmware nell'eMMC. Questo proviene direttamente dallo stesso Entropy per quelli di voi interessati a un po' più di dettagli:
PERICOLO: molti kernel Samsung ICS leak potrebbero danneggiare il tuo dispositivo!
Coloro che prestano attenzione a ciò che accade con i vari dispositivi Samsung potrebbero aver notato che alcuni dispositivi subiscono una grande quantità di hardbrick quando vengono utilizzati i kernel trapelati da ICS. Questi hardbrick sono particolarmente dannosi, in quanto i fornitori di servizi JTAG non sono stati in grado di resuscitare questi dispositivi, a differenza dei semplici hardbrick che corrompono il bootloader. Ciò è dovuto al fatto che questi kernel riescono effettivamente a causare quello che sembra essere un danno permanente al dispositivo di archiviazione eMMC.
I kernel che risultano interessati sono:
[*]Tutti i leak ICS di Epic 4G Touch (SPH-D710)[*]Tutti i leak ICS di Galaxy Note (GT-N7000)[*]L'AT&T Galaxy S II (SGH-I777) Perdita di UCLD3 - e probabilmente tutte le altre[*]versioni ufficiali coreane di SHW-M250S/K/L e qualsiasi kernel costruito da loro fonte
I kernel che DOVREBBERO essere sicuri sono:
[*]Perdite di ICS GT-I9100[*]Versioni ufficiali di GT-I9100[*]Kernel basati sulla base sorgente GT-I9100 Update4
Operazioni che potrebbero causare danni durante l'esecuzione di un kernel interessato:
Cancellazione in CWM (e probabilmente qualsiasi altro ripristino personalizzato) (confermato)
Ripristino di un backup Nandroid in CWM (prima pulisce)
Flashing di un altro firmware in CWM (la maggior parte dei flash si cancella prima)
Cancellazione nel ripristino stock 3e (sospetto, cancella anche una partizione)
Eliminazione di file di grandi dimensioni durante l'esecuzione di un kernel interessato (sospetto ma non confermato)
Se hai un kernel interessato:
Flasha immediatamente un kernel sicuramente funzionante utilizzando Odin/Heimdall. NON utilizzare Mobile Odin, CWM o qualsiasi metodo sul dispositivo per eseguire il flashing. I buoni kernel noti includono:
[*]Quasi tutti i kernel Gingerbread[*]Kernel ICS creati dal codice sorgente GT-I9100 Update4
La causa principale di questo problema deve ancora essere determinata, tuttavia, numerosi sviluppatori riconosciuti in XDA sospettano che sia dovuto al fatto che Samsung abbia abilitato una funzionalità nel kernel interessati, MMC_CAP_ERASE - Questa è una funzionalità prestazionale che può aumentare notevolmente le prestazioni di scrittura flash, ma sembra mettere in evidenza un difetto nella flash chipset. I kernel GT-I9100 ICS non hanno questa funzione abilitata e sembrano sicuri. Tuttavia, non si sa abbastanza per dichiarare sicuri tutti i kernel senza questa funzionalità, l'unica entità che può confermarne la causa principale Samsung ha risolto questo problema e lo dichiara risolto senza correre grandi rischi (distruggendo più dispositivi senza alcun modo per ripararli). loro stessi.
In generale, fino a nuovo avviso, se stai riscontrando un leak di Samsung ICS per qualsiasi dispositivo basato su Exynos diverso dal GT-I9100, ti consigliamo vivamente di eseguire il flashing di qualcos'altro.
E questo è apparso proprio stamattina anche nei nostri forum, per gentile concessione del membro XDA garwynn. Apparentemente, Google è stata contattata ed è a conoscenza del problema, e un ingegnere spera di lavorare per una soluzione.
Bene, è passato un po' di tempo ma per fortuna il signor Sumrall di Android ci ha risposto alle nostre domande. Penso che la comunità scoprirà che valeva la pena aspettare.Problema: fwrev non impostato correttamente.Come sospettavamo, la correzione del bug non è presente nella nostra build. (La patch lo applica incondizionatamente.)Domanda: La revisione non corrispondeva alla correzione(Sottolinea il mio in rosso poiché discute la questione dei supermattoni.)Citazione:
Originariamente inviato da Ken Sumrall
La patch include una riga in mmc.c che imposta fwrev sui bit dei diritti dal registro cid. Prima di questa patch, il file /sys/class/block/mmcblk0/device/fwrev non era inizializzato dal CID per i dispositivi emmc rev 4 e successivi e quindi mostrava zero.(Alla seconda richiesta)fwrev è zero finché non viene applicata la patch.
Domanda: Perché la partizione /data?Citazione:
Originariamente inviato da Ken Sumrall
Probabilmente hai il bug, ma la rev 0x19 era una versione precedente del firmware che avevamo nei nostri dispositivi prototipo, ma abbiamo scoperto che conteneva un altro bug che se si ha inviato un comando di cancellazione mmc, potrebbe rovinare le strutture dei dati nel chip e causare il blocco del dispositivo fino all'accensione pedalato. Lo abbiamo scoperto quando molti dei nostri sviluppatori stavano eseguendo un avvio rapido per cancellare i dati utente mentre stavamo sviluppando ICS. Quindi Samsung ha risolto il problema ed è passato alla revisione del firmware 0x25.Sì, è molto fastidioso che 0x19 sia decimale 25 e ciò ha creato molta confusione durante il tentativo di diagnosticare i problemi del firmware emmc. Alla fine ho imparato a fare _SEMPRE_ riferimento alla versione emmc in esadecimale e a far precedere il numero con 0x solo per essere inequivocabile.Tuttavia, anche se probabilmente 0x19 ha il bug che può inserire 32 Kbyte di zeri nella flash, non è possibile utilizzare questa patch su dispositivi con revisione firmware 0x19. Questa patch esegue un hack molto specifico su due byte di codice nella revisione 0x25 del firmware, e la patch più probabilmente non funzionerà su 0x19 e probabilmente causerà il malfunzionamento del chip nella migliore delle ipotesi e la perdita di dati peggio. C'è una ragione per cui i criteri di selezione sono così rigidi per applicare questa patch al firmware emmc.Ho trasmesso i nostri risultati qualche giorno dopo, menzionando che il file system non si era danneggiato fino alla cancellazione. Questa è una risposta a quel seguito.Come ho accennato nel post precedente, il firmware rev 0x19 presenta un bug in cui il chip emmc può bloccarsi dopo che è stato dato un comando di cancellazione. Non tutte le volte, ma abbastanza spesso. Di solito, il dispositivo può riavviarsi dopo questo, ma poi bloccarsi durante il processo di avvio. Molto raramente, può bloccarsi anche prima che venga caricato l'avvio rapido. Il tuo tester è stato sfortunato. Dato che non riesci nemmeno ad avviare il fastboot, probabilmente il dispositivo è bloccato. :-( Se potesse eseguire l'avvio rapido, quindi il dispositivo potrebbe probabilmente essere ripristinato con il codice di aggiornamento del firmware in mio possesso, supponendo che possa condividerlo. Chiederò.
Domanda: Perché JTAG non funziona?Citazione:
Originariamente inviato da Ken Sumrall (Android SE)
Perché /data è il luogo in cui il chip sperimenta la maggior parte dell'attività di scrittura. /system non viene mai scritto (tranne durante un aggiornamento del sistema) e /cache viene utilizzato raramente (principalmente per ricevere OTA).
Domanda: è possibile riparare un file system danneggiato (sull'eMMC)?Citazione:
Originariamente inviato da Ken Sumrall
Come accennato in precedenza, il firmware della revisione 0x19 presentava un bug che, dopo un comando di cancellazione emmc, poteva lasciare il strutture dati interne del chip emmc in cattivo stato che causano il blocco del chip quando si trova un particolare settore avuto accesso. L'unica soluzione era cancellare il chip e aggiornare il firmware. Ho il codice per farlo, ma non so se posso condividerlo. Chiederò.
Quindi, anche se la correzione non si applica al nostro caso al momento, ci è stata fornita una visione approfondita del problema del superbrick, nonché informazioni su come risolverla. È già sviluppato (speriamo di vederlo rilasciato!). Probabilmente il bug si applica a noi e, presupponendo che venga fornita la correzione per il firmware 0x19, si applicherebbe ai nostri dispositivi.Con una nota più leggera, volevo includere la sua chiusura:Citazione:
Originariamente inviato da Ken Sumrall
e2fsck può riparare il filesystem, ma spesso i 32 Kbyte venivano inseriti all'inizio di un gruppo di blocchi, cancellando molti inode, e quindi l'esecuzione di e2fsck spesso comportava la perdita di molti file.
Citazione:
Originariamente inviato da Ken Sumrall
Stai dando uno sguardo all'entusiasmante vita di uno sviluppatore del kernel Android. :-) Si scopre che il lavoro consiste principalmente nel combattere con hardware difettoso. Almeno, a volte sembra così.
Ti preghiamo di evitare di eseguire il flashing di qualsiasi contenuto ICS sui tuoi dispositivi finché il problema non sarà risolto.
Vuoi pubblicare qualcosa nel Portale? Contatta qualsiasi scrittore di notizie.
[Grazie Entropia512 per tutto il tuo duro lavoro!!!]