Penso di si...ma se vuoi flashare una rom cucinata basta ke torni dietro a ginger e poi fai qll ke vuoi! I kernel gb sn sicuri...se poi x esempio flashi cm9,cm ho dtt prima loro hanno distribuito un kernel sicuro da flashare! Io nn ho provato ma alcuni la cyano l'hanno già.messa
Inviato dal mio Samsung Galaxy Note con Ics usando Androidiani App
Knowledgement emmc damage tutte le info del caso
Visualizzazione stampabile
-
22-05-12, 19:41rogerthebest
-
22-05-12, 19:58thayFalk ma tu hai realmente chiara la situazione? Mi sembra che la confusione regna sovrana....Quote:
Originariamente inviato da falk88
Ti sembra che un team di sviluppatori che basa il suo lavoro su sistema aosp faccia riferimento ad un kernel buggato per i suoi sviluppi? Cyanogen non ha nulla a che vedere con samsung ed il suo kernel(come anche altri) e sicuro. -
22-05-12, 20:55falk88Onesto la confusione regna sovrana!!!! roftl roftl roftlQuote:
Originariamente inviato da thay
Io sinceramente dopo l'epic fail di samsung non mi fido di nessuno.
quindi scusa thay se ti rompo per l'ennesima volta, il bug in questione si presenta solo con ics stock con relativo kernel oppure anche su tutte le rom?
Scusa ancora se ti sto sfiancando ma cerco di capire il piu che posso x non ribrikkare il note quando lo riavrò -
22-05-12, 21:04thayE' paradossale ma al momento e' piu' sicura la cyanogen che la stock.Parliamo sempre di android 4 perche' con gingerbread non ci sono problemi.Quando riavrai il tuo note non cambiera' nulla sotto questo aspetto quindi prendi le precauzioni del caso e spera samsung rilasci un update per aggirare il bug.Questo probabilmente e' stato un passo falso,qualcosa e' sfuggito dal controllo.Ricordo che potenzialmente il problema e' presente su tutti gli exynos quindi anche il vendutissimo sgs2 con un firm buggato ha lo stesso comportamento.In italia ricordiamo che ancora non e' stato rilasciato nulla per i telefoni nostrani.Questa esperienza e' uscita grazie all'update di molti telefoni acquistati in rete con csc tedesco oppure con il flash del firmware tedesco su odinQuote:
Originariamente inviato da falk88
-
22-05-12, 21:11falk88Grazie per la risposta, quindi volendo passare a ics mi consigli la cyano? io adoro ics ma sto bug mi ha terrorizzato, io necessito dei wipe xke faccio diversi esperimenti che non sto qui ad elencare e quindi mi serve una base ottima come ginger che non si pianti su sti wipe. Cmq scusa ma ancora non capisco perche non possono eliminarlo il bug anzike aggirarlo, mi semvra una solozione non tanto professionale, io mi aspetterei che un utente del nostro forum o di xda possa rilasciare un fix che aggira il problema mentra da samsung mi aspetto che non lo aggirino soltanto ma che lo elimini dalla faccia della mobo.... Son soldoni che si prendono su ogni terminale non bricioleQuote:
Originariamente inviato da thay
-
22-05-12, 21:17thay
Se sai come flashare il firmware di una emmc e rilasciare un update in merito penso che samsung ti assume subito :) Senza gli strumenti adatti per quel che ne so e' impossibile.Ritiro dei dispositivi e' altrettanto improbabile perche' in effetti essi non presentano malfunzionamenti reali .Qui ce' un sottile filo che delimita il tutto sicuramente con questa rev firmware qualcuno ha cannato qualcosa ma si spera porgano rimedio e che serva in futuro
-
25-05-12, 15:05Andromeda1968
What an expert said about eMMc bug!
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Do you know the commands to reset the eMMC controller in question?
Originally Posted by Ken Sumrall (Android)
Once the chip has locked up, no command will reset it. It must be power cycled. If instead you are asking how to clear the metadata so the chip works again, the only solution I know is to update the firmware inside the chip, and that also wipes all the data. This probably includes factory calibration data that must be saved before the firmware is updated, and restored after. Also, the boot loader is probably in the chip, and must be restored after the firmware update, or the device will be bricked. This is a dangerous operation, because if something goes wrong, the device will probably be bricked. (emphasis added)
Q: Is there any documentation available on this issue? If so and it is private is it possible to have it released?
Originally Posted by Ken Sumrall (Android)
It is private, I'm asking if I can release it, along with the code to update the emmc firmware. Don't get your hopes up, my guess is the answer will be no.
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Q: Difference between GB/ICS Wipe
Originally Posted by Ken Sumrall (Android)
IIRC, when using recovery to wipe the phone on GB, the make_ext4fs() library would not issue an erase command first, it would just write one a new blank filesystem. This, of course, doesn't really erase all the private data of the user, so we changed make_ext4fs() to first erase the partition, then write out the new filesystem. You can see the code in system/extras/ext4_utils/wipe.c, which didn't exist in gingerbread, but does in honeycomb and later. It is the erase operation on the rev 0x19 firmware that can cause the emmc chip to lockup. (emphasis added)
Regarding Entropy512's summary of observations:
Originally Posted by Ken Sumrall (Android)
Regarding the notes on MMC_CAP_ERASE, the just lists the cards ability to perform the erase command. In other words, if the mmc_erase() function works. What is more important is if anyone calls the mmc_erase() function. Looking at the mmc driver, in drivers/card/block.c, it is only called when a secure discard or discard request is made. As far as I know, those requests are only sent if the filesystem is mounted with the "discard" option, or if userspace code does an ioctl() to erase a partition, like make_ext4fs does. So check the mount options on the filesystems. *If they don't specify "discard", the erase operations are probably not happening.
Of course, a simple debugging printk() in the mmc_erase() function will tell you if anyone is calling it.
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
http://forum.xda-developers.com/show...&postcount=293 -
25-05-12, 20:25thay
Questo spiega anche le strane situazioni di fasulli wipe su gingerbread ,alla fine non cancellava nulla ma riscriveva semplicemente il file system vuoto e azzzoooo rotfl.alla faccia della sicurezza dei dati personali.Che paccata ...come disse qualcuno
-
25-05-12, 20:27Andromeda1968
penso che ne sentiremo delle belle ancora ;)
-
25-05-12, 21:46tataccio
Temo che se non si correrà ai ripari il note passerà alla storia come il terminale cyano per eccellenza.... La cosa assurda è che ne erano al corrente se su gnexus hanno dovuto sostituire su richiesta di mamma google... Bah.. Per chi dice che sta pensando di passare a sgs3 cosa vi fa pensare che il il problema non esista??
Inviato dal mio GT-N7000 usando Androidiani App
