Sondaggio Galaxy S2 con Chip eMMC sano

Ciao a tutti. Sto aprendo questo thread per fare un sondaggio per verificare quanti di voi si ritrovano con un cellulare che viene identificato come "chip sano" dal programma eMMC chek. Inoltre se postate anche la vostra FwRev è anche meglio! Questo thread serve semplicemente per fare una statistica e per capirci qualcosa di più riguardo questa anomalia.
Se avete voglia di raccontare la vostra esperienza, qui è il posto giusto!

Se vuoi fare il sondaggio aggiungi anche le caselle da flaggare nell'intestazione della discussione.... Sano/buggato... O quello che ctedi.

Sopra il tuo post dovresti aprire i vari menù e cercare quello per il sondaggio

Ma così facendo si potrà solo cliccare Si/No oppure gli utenti potranno ugualmente rispondere al thread?

Quote:

---

Originariamente inviato da Mattyx89

Ma così facendo si potrà solo cliccare Si/No oppure gli utenti potranno ugualmente rispondere al thread?

---

Possono rispondere ugualmente :)

Intanto comincio io: il mio chip purtroppo non è sano (eMMC brickbug checker mi ha aiutato a scoprirlo), ma fortunatamente su rom stock ci sono stato da dicembre 2011 a metà gennaio, per poi passare alla CM 7 ed alla CM 9, rom che ho tenuto un'eternità insieme al kernel Siyah, cosa che mi ha permesso di saltare a piè pari il brickbug dovuto alle leaked ICS e JB rotfl
Ho assistito da spettatore alla moria di Galaxy SII nel thread che c'è stickato nella sezione e ci sono rimasto male anche e soprattutto per i numerosi dev (tipo blueflight ricordo che ne è stato vittima) che si son visti mancare lo strumento di "lavoro" primario per un errore non loro.

Adesso, grazie al bug introdotto nel codice del kernel, vivo tranquillo tra Siyah, Dorimanx, cm kernel e aosp kernel, ovviamente solo su rom aosp rotfl

Chip non sano, ma non mi tange minimamente in quanto l'ho comprato usato già con JB ufficiale :P adesso vado tranquillo di custom roms e kernel non ufficiali :D

Quote:

---

Originariamente inviato da Dionysus

Possono rispondere ugualmente :)

Intanto comincio io: il mio chip purtroppo non è sano (eMMC brickbug checker mi ha aiutato a scoprirlo), ma fortunatamente su rom stock ci sono stato da dicembre 2011 a metà gennaio, per poi passare alla CM 7 ed alla CM 9, rom che ho tenuto un'eternità insieme al kernel Siyah, cosa che mi ha permesso di saltare a piè pari il brickbug dovuto alle leaked ICS e JB rotfl
Ho assistito da spettatore alla moria di Galaxy SII nel thread che c'è stickato nella sezione e ci sono rimasto male anche e soprattutto per i numerosi dev (tipo blueflight ricordo che ne è stato vittima) che si son visti mancare lo strumento di "lavoro" primario per un errore non loro.

Quote:

---

Originariamente inviato da Armar

Chip non sano, ma non mi tange minimamente in quanto l'ho comprato usato già con JB ufficiale :P adesso vado tranquillo di custom roms e kernel non ufficiali :D

---

Adesso, grazie al bug introdotto nel codice del kernel, vivo tranquillo tra Siyah, Dorimanx, cm kernel e aosp kernel, ovviamente solo su rom aosp rotfl

---

Dopo il modding avete provato a reinstallare l'app eMMC check?

Quote:

---

Originariamente inviato da Mattyx89

Dopo il modding avete provato a reinstallare l'app eMMC check?

---

Io si, bug prima e bug dopo

Quote:

---

Originariamente inviato da Mattyx89

Dopo il modding avete provato a reinstallare l'app eMMC check?

---

Ovviamente sì, ma il risultato è lo stesso perché non è propriamente un "bug" nel senso stretto del software, ma un difetto del chip, quindi cambia poco che tu abbia un kernel safe o non safe, il chip difettoso ce l'hai e basta.

Quote:

---

Originariamente inviato da Dionysus

Ovviamente sì, ma il risultato è lo stesso perché non è propriamente un "bug" nel senso stretto del software, ma un difetto del chip, quindi cambia poco che tu abbia un kernel safe o non safe, il chip difettoso ce l'hai e basta.

---

Quote:

---

Originariamente inviato da 0raziel0

Io si, bug prima e bug dopo

---

Cosa avete cambiato esattamente? Sia kernel che firmware?

Quote:

---

Originariamente inviato da Mattyx89

Cosa avete cambiato esattamente? Sia kernel che firmware?

---

Tutto :D in pratica e rimasto solo l'hardware

Mh capisco capisco.. okok! Allora attendiamo nuovi iscritti e continuiamo con la caccia al tesoro! (cioè al chip d'oro)

Piccolo OT
Ma quindi in parole povere, il cellulare come fa ad eseguire il format se gli manca quel comando? Questo non l'ho mica capito rotfl

Quote:

---

Originariamente inviato da Mattyx89

Mh capisco capisco.. okok! Allora attendiamo nuovi iscritti e continuiamo con la caccia al tesoro! (cioè al chip d'oro)

Piccolo OT
Ma quindi in parole povere, il cellulare come fa ad eseguire il format se gli manca quel comando? Questo non l'ho mica capito rotfl

---

Perche funzionava solo su gingerbread lo script, solo in 2 casi si riattivava, chalifire root ( ma non subito, possono passare mesi) e rom 4.0.4 stock e leaked 4.1.2
Dato che dalla 2.3 alla 4.0 android e stato rifatto daccapo il comando non serviva più

Ultima cosa, mi sono domandato di chiedervi sempre in nell'app emmc la versione FwRev che avete, e se anche esse è rimasta tale dopo i modding. Dovevo scriverlo nell'intestazione topic

Quote:

---

Originariamente inviato da Mattyx89

Ultima cosa, mi sono domandato di chiedervi sempre in nell'app emmc la versione FwRev che avete, e se anche esse è rimasta tale dopo i modding. Dovevo scriverlo nell'intestazione topic

---

Quello cambia, perche sarebbe firmware review, se metto una aokp 4.2 mi darà 4.2

Quote:

---

Originariamente inviato da Mattyx89

Cosa avete cambiato esattamente? Sia kernel che firmware?

---

Quote:

---

Originariamente inviato da Mattyx89

Mh capisco capisco.. okok! Allora attendiamo nuovi iscritti e continuiamo con la caccia al tesoro! (cioè al chip d'oro)

Piccolo OT
Ma quindi in parole povere, il cellulare come fa ad eseguire il format se gli manca quel comando? Questo non l'ho mica capito rotfl

---

Ovviamente tutto. Adesso monto la SlimSaber con il suo Slimkernel che sono kernel safe (senza il comando MMC_CAP_ERASE).
Non manca il comando di format (puoi wipare e formattare ogni partizione da recovery), manca il comando che ho appena citato che, per colpa del chip difettoso, cancella l'allocazione in blocchi della memoria nand e brucia il chip della memoria in pratica.

Quoto il messaggio quotato nel post del brickbug per una maggiore comprensione da chi vede questo argomento per la prima volta.

Quote:

---

Originariamente inviato da UMBERTO1978

COS'E' il COSIDDETTO HARD BRICK BUG

Non è un bug propriamente detto, ma una fatale conseguenza, dovuta ad una combinazione altrettanto fatale: un kernel con un flag attivo nella gestione driver dell'mmc e dell'sdhc combinata ad una serie di microchip di memoria flash (la sd interna) che equipaggiano buona parte dei galaxy s2 in commercio, dotati di controller firmware difettoso.

L'entità del danno che ne deriva non è costante ed ha una tempestività randomica, non è un errore di programmazione o un semplice FC: a volte può semplicemente corrompersi una partizione di sistema (come è successo a Darham Maniar, lo sviluppatore del exDarkNight kernel) o altre volte può capitare di danneggiare irreparabilmente il device (come successo a steULM o altri) e in ogni caso il danno non mostra subito i denti, possono essere necesari giorni o minuti successivi allo scatenarsi dell'evento per far si che si presenti il bug nella peggiore delle sue forme.

I recenti kernel STOCK samsung derivati dall'update 7 (i codici opensource rilasciati dalla stessa samsung), gli unici ad assicurare la piena compatibilità con i firmware 4.0.4 ICS, hanno un "opzione" attivata esattamente nei moduli dei driver delle memorie interna (mmhc) ed esterna (sdhc) che consentono di eseguire da recovery (specialmente CWM ) una cancellazione diciamo "pesante" dei blocchi di memoria allocati rispettivamente. Il firmware del controller del chip mmc (che è dove risiedono, tra le altre, le partizioni system, data e comunque tutto ciò che serve al device per effettuare il boot e quant'altro) non gestisce in maniera appropriata lo svolgimento delle operazioni, dando luogo ad un errore che risulta tanto più grave quanto più grossa è la quantità di dati da eliminare in una sola sessione (un wipe data ad esempio). Da precisare che l' MMC_CAP_ERASE è attivo sia su sd interna che esterna: IL DANNO lo subirà solo la prima, perchè la esterna non è dotata di alcun controller attivo e quindi di nessun firmware.

Nella peggiore delle ipotesi, in casi di brick, è necessaria la sostituzione della scheda madre: l'mmc non è una scheda sd così come la intendiamo comunemente, si tratta di un chip che è saldato alla scheda madre stessa.

QUALI CONDIZIONI SONO NECESSARIE PERCHE' SI VERIFICHI IL BUG

La condizione sfavorevole:

- Un kernel Stock basato su update 7, ad esempio quello che trovate nelle stock 4.0.4 XWLPM e a seguire

- Una recovery CWM

- Un chip difettoso

MA COSA C'ENTRA LA CWM RECOVERY

Il kernel pericoloso è la bomba e una recovery CWM è il detonatore. La recovery ClockWorkMod contiene una serie di istruzioni precaricate che servono per eseguire svariate operazioni, tra cui il wipe data. Il comando di wipe data, ad esempio, eseguito da recovery CWM è costituito da una serie di "format" di varie partizioni ed è proprio il comando format che richiama il bug in questione. Dovete sapere che comunque non è solo la recovery ad essere pericolosa: anche senza eseguire alcun wipe volontario ci si può trovare con un mattone di 500 euro in mano. La maggior parte delle custom rom possiede ad esempio una cartella meta-inf, all'interno della quale si trova parcheggiato un update.binary. Non è altro che un binario (eseguibile) contenente tutti i comandi basilari specifici per un device: operazioni di format, di mount ecc. ecc. le quali possono essere richiamate (senza che l'utente medio ne sia a conoscenza) in qualunque fase dell'installazione di una rom o un tema (anche il wipe cache è letale) generando gli stessi effetti di un wipe eseguito volontariamente da recovery.

COME POSSO EVITARE DI FAR DANNI (a prescindere che il chip sia difettoso o meno)

Ecco la procedura corretta e a seguire qualche spiegazione

- flash con Odin della rom stock 4.0.4, (non eseguite alcuna operazione di format o cancellazione dati personali successivamente all' installazione) e avviate normalmente

- flash sempre con Odin di un kernel, sempre update 7, ma reso SICURO dallo sviluppatore

Da questo memento in poi potrete fare tutti i wipe data (o simili) che volete in assoluta sicurezza.

I kernel compilati dagli sviluppatori (tutti i più recenti TRANNE il cfroot) sono stati resi sicuri grazie alla rimozione dell'opzione dai driver che costituiranno il kernel: in questo modo la catena di eventi viene interrotta in maniera inequivocabile prima che si possano ottenere danni.

MA QUALI SONO I KERNEL SICURI, NOOB CHE NON SEI ALTRO??!!

Quelli per i quali ad oggi mi risulta essere sicuri sono:

- Siyah kernel

- Phenomenal

- NEAK

- DM KERNEL

- SpeedMOD kernel

- Galaxian Kernel

- SpeedWizz kernel

- sicuramente altri lo sono, bisogna informarsi nel relativo thread informativo o chiedendo allo sviluppatore

Gli sviluppatori dei relativi kernel compilano lo zImage (kernel) direttamente dai sorgenti: sanno dove scovare il flag e lo disabilitano, solo successivamente compilano l'immagine del kernel. Vi consiglio di non usare il CF_Root: chainfire è solito realizzare il proprio kernel SENZA compilare dai sorgenti; decomprime il kernel della rom stock , aggiunge gli initramfs (CWM recovery, superuser , busybox applets, supporto alla bootanimation) e ricomprime il tutto. Il motivo della strage di devices è proprio da ricercarsi nel fatto che, a differenza di un codice sorgente non compilato (costituito da file di testo, script e driver), l'immagine di un kernel compilato è interpretabile solo usando un editor esadecimale e sapendo con esattezza cosa andare a cercare.

IMPORTANTE: Anche se nelle ultime versioni di CFroot è stata introdotta una nuova recovery inserendone una che non possiede i comandi di format (ma solo di cancellazione e sovrascrittura) sono stati riportati casi (molto recenti ad esempio quelli sulla Wanam Lite 12.3 XWLPU, equipaggiata proprio con CF root) di hard Brick irreversibile, molto probabilmente dovuti all'uso involontario di update.binary (non importa se sono eseguiti con recovery stock o CWM) su un kernel pericoloso come il CFroot.

IN BUONA SOSTANZA SIAMO AL SICURO OPPURE NO??!!

Cito le parole del noto sviluppatore Entropy512 di XDA:

"....annullando il flag dell' MMC_CAP_ERASE non abbiamo fatto altro che introdurre un bug nel codice di un kernel potenzialmente pericoloso...."

Ai posteri l'ardua sentenza!

---

anche il mio è "insane"..ma quindi cosa cambia??

Quote:

---

Originariamente inviato da chriter90

anche il mio è "insane"..ma quindi cosa cambia??

---

Nulla se non hai usato cf root e se hai un firmware 4.1.2 ufficiale e anche se hai un qualsiasi kernel safe

Quote:

---

Originariamente inviato da 0raziel0

Quello cambia, perche sarebbe firmware review, se metto una aokp 4.2 mi darà 4.2

---

No aspetta, di Firmware review dovrebbe darti un risultato tipo "0x19" una cosa del genere

Quote:

---

Originariamente inviato da Dionysus

Ovviamente tutto. Adesso monto la SlimSaber con il suo Slimkernel che sono kernel safe (senza il comando MMC_CAP_ERASE).
Non manca il comando di format (puoi wipare e formattare ogni partizione da recovery), manca il comando che ho appena citato che, per colpa del chip difettoso, cancella l'allocazione in blocchi della memoria nand e brucia il chip della memoria in pratica.

Quoto il messaggio quotato nel post del brickbug per una maggiore comprensione da chi vede questo argomento per la prima volta.

---

Siamo sicuri che questo chip si bruci nel vero senso elettronico, oppure non riesce più ad essere letto/scritto?
Comunque ieri notte ho scoperto una cosa che sicuramente vi interessa! Spulciando tra youtube e google, mi sono avventurato in un sacco di metodi di recupero Fullbrick! Per questo andrebbe aperta una nuova discussione, infatti ora posto sinteticamente come funziona e poi sarà il moderatore a scegliere cosa fare.
Praticamente tutti i cellulari che sono dotati di un processore di tipo omap cpu, e che magari sono finiti sotto full brick (schermo completamente morto), possono essere resuscitati tramite un software chiamato omapflash che a quanto pare riesce a riscrivere il bootloader ed il telefono riparte! Ho letto di possessori di Nexus che tramite questo programma sono riusciti dal vero brick e poi spulciando bene xda ho scoperto che appunto il programma va bene per tutti i cellulari con Cpu Omap (Galaxy S2 compreso)
Ora servirebbe qualcuno che ha un cellulare completamente morto

Edit
Uff scusate..mi tocca cancellare questo metodo perchè leggendo bene.....solo il samsung GT-I9100G monta questo tipo di cpu :( mi sono lasciato prendere dall'euforia

insane anche a me mi da fwrev 0x19. Monto la cyano 10.2 ultima nightly kernel cyano

Sane. Stock Jelly Bean 4.1.2 LSW ITA rootato.

Quote:

---

Originariamente inviato da lucisimo

Sane. Stock Jelly Bean 4.1.2 LSW ITA rootato.

---

Allora esistono sani ;)

lucissimo potresti dare le altre informazioni che ti da il programma, come il fwrev? Inoltre, quando hai comprato questo cellulare? (stiamo cercando di capire da quale data è stato risolto il problema)

Anche io nel gruppo degli insane! Organizziamo un viaggio in Corea? XD

Io ho bruciato la scheda madre a distanza di 1 anno dall'acquisto. Garanzia con sostituzione scheda completa e ora faccio parte dei "sane cip"

https://www.androidiani.com/extra/im...mage_J46EG.jpg