Deoarece cele mai recente scurgeri pentru gama Samsung Galaxy S2 ne-au lovit în stânga și în dreapta, oamenii au sărit între ROM-uri, în principal între versiuni cu erori, versiuni ICS pre-lansare și GB foarte stabil. La urma urmei, asta este ceea ce facem pe XDA ca un obicei: vedem o scurgere, o fulgerăm, o folosim și o modificăm. Dacă nu zboară, pur și simplu ne întoarcem. Desigur, există întotdeauna un risc inerent în clipirea lucrurilor care nu ar trebui să fie pe dispozitivul dvs. în primul rând, dar riscul de a bloca complet un dispozitiv în zilele noastre este destul de mic. Mai ales că există instrumente disponibile pentru a vă aduce dispozitivele înapoi din morți, cum ar fi Mod necărămibil de XDA Elite Recognized Developer AdamOutler.
Acestea fiind spuse, nu totul pare să fie bine în lumea scurgerilor. Mulțumim dezvoltatorului recunoscut XDA Elite Entropia512, am aflat că majoritatea dispozitivelor care primesc scurgeri prezintă un risc foarte mare de a nu se trezi niciodată după un fulger. Se pare că există o eroare majoră în nucleul ICS scurs care afectează
- Toate Epic 4G Touch (SPH-D710) Scurgeri ICS
- Toate Galaxy Note (GT-N7000) Scurgeri de ICS
- The AT&T Galaxy S II (SGH-I777) Scurgere UCLD3 - și probabil toate celelalte
- Lansările oficiale coreene SHW-M250S/K/L și orice nucleu construit din sursa lor
Entropy și alți dezvoltatori au postat mai multe avertismente împrăștiate pe site, în care explică în detaliu ce se întâmplă. Sugestia noastră este că utilizatorii ar trebui să stea departe de a intermite ICS de la scurgeri până când eroarea din nucleu a fost complet remediată, fără, desigur, că doriți să vă blocați dispozitivul. Amintiți-vă, acesta nu este ceva care poate fi reînviat prin Unbrickable Mod sau chiar prin JTAG, deoarece aceasta este o eroare de firmware în eMMC. Acesta este direct de la Entropy însuși pentru cei dintre voi interesați de puțin mai multe detalii:
PERICOL: Multe nuclee Samsung ICS cu scurgeri vă pot deteriora dispozitivul!
Cei care acordă atenție evenimentelor cu diferite dispozitive Samsung ar fi putut observa că unele dispozitive se confruntă cu o cantitate mare de cărămizi tari atunci când sunt utilizate nuclee scurse de ICS. Aceste cărămizi rigide sunt deosebit de urâte, deoarece furnizorii de servicii JTAG nu au reușit să resusciteze aceste dispozitive, spre deosebire de cărămizile simple de bootloader-corupție. Acest lucru se datorează faptului că aceste nuclee reușesc de fapt să provoace ceea ce pare a fi daune permanente dispozitivului de stocare eMMC.
Kernelurile care sunt confirmate afectate sunt:
[*]Scurgeri ale tuturor ICS Epic 4G Touch (SPH-D710)[*]Scurgeri ale tuturor ICS Galaxy Note (GT-N7000)[*]AT&T Galaxy S II (SGH-I777) Scurgere UCLD3 - și probabil toate celelalte[*]Versiunile oficiale coreene SHW-M250S/K/L și orice nucleu construit din lor sursă
Kernel-urile care TREBUIE să fie sigure sunt:
[*]Scurgeri ICS GT-I9100[*]Versiuni oficiale GT-I9100[*]Nuclee construite din baza sursă GT-I9100 Update4
Operațiuni care pot provoca daune atunci când rulează un nucleu afectat:
Ștergerea în CWM (și probabil orice altă recuperare personalizată) (confirmată)
Restaurarea unei copii de rezervă Nandroid în CWM (ștergeți mai întâi)
Afișarea intermitentă a unui alt firmware în CWM (cele mai multe flash-uri se șterg mai întâi)
Ștergerea în stoc 3e recuperare (suspectată, șterge și o partiție)
Ștergerea fișierelor mari atunci când rulați un nucleu afectat (suspectat, dar neconfirmat)
Dacă aveți un nucleu afectat:
Flashează imediat un nucleu cunoscut bun folosind Odin/Heimdall. NU utilizați Mobile Odin, CWM sau orice metodă de pe dispozitiv pentru a flash. Nuezele bune cunoscute includ:
[*]Aproape orice nucleu Gingerbread[*]kernel-uri ICS construit din codul sursă GT-I9100 Update4
Cauza principală a acestei probleme nu a fost încă determinată, cu toate acestea, numeroși dezvoltatori recunoscuți din XDA bănuiesc că se datorează faptului că Samsung a activat o funcție în nuclee afectate, MMC_CAP_ERASE - Aceasta este o caracteristică de performanță care poate crește considerabil performanța de scriere flash, dar pare să scoată la iveală o defecțiune în flash chipset. Nucleele GT-I9100 ICS nu au această caracteristică activată și par sigure. Cu toate acestea, nu se cunoaște suficient pentru a declara toate nucleele fără această caracteristică sigure - singura entitate care poate confirma cauza principală a această problemă și declarați-o rezolvată fără să vă asumați riscuri mari (distrugerea mai multor dispozitive fără nicio modalitate de a le repara) este Samsung înșiși.
În general, până la o nouă notificare, dacă executați o scurgere ICS Samsung pentru orice dispozitiv bazat pe Exynos, altul decât GT-I9100, este recomandat să flashați altceva.
Și acest lucru tocmai a apărut în această dimineață și pe forumurile noastre, prin amabilitatea membrului XDA garwynn. Aparent, Google a fost contactat și sunt conștienți de problemă, iar un inginer speră să lucreze la o remediere.
Ei bine, a trecut ceva timp, dar din fericire domnul Sumrall de la Android ne-a răspuns la întrebările noastre. Cred că comunitatea va descoperi că a meritat așteptarea.Problemă: fwrev nu este setat corect.După cum am bănuit, remedierea erorilor nu este în versiunea noastră. (Patch-ul aplică acest lucru necondiționat.)Întrebare: Revizia nu s-a potrivit cu remedierea(Sublinierea mea în roșu, deoarece discută problema superbrick.)Citat:
Postat inițial de Ken Sumrall
Patch-ul include o linie în mmc.c setarea fwrev la biții de drepturi din registrul cid. Înainte de acest patch, fișierul /sys/class/block/mmcblk0/device/fwrev nu a fost inițializat din CID pentru dispozitivele emmc rev 4 și mai mari, și astfel arăta zero.(La a doua întrebare)fwrev este zero până când plasturele este aplicat.
Întrebare: De ce partiția /data?Citat:
Postat inițial de Ken Sumrall
Probabil ai bug-ul, dar rev 0x19 era o versiune anterioară a firmware-ului pe care îl aveam în dispozitivele noastre prototip, dar am constatat că avea un alt bug pe care dacă a emis o comandă de ștergere mmc, ar putea distruge structurile de date din cip și ar putea duce la blocarea dispozitivului până când este alimentat ciclată. Am descoperit acest lucru când mulți dintre dezvoltatorii noștri făceau o ștergere rapidă a datelor utilizatorului în timp ce dezvoltam ICS. Așa că Samsung a remediat problema și a trecut la versiunea firmware 0x25.Da, este foarte enervant că 0x19 este zecimalul 25 și asta a dus la multă confuzie atunci când încercam să diagnosticezi problemele cu firmware-ul emmc. În cele din urmă, am învățat să mă refer la versiunea emmc în hexazecimal și să preced numărul cu 0x doar pentru a fi clar.In orice caz, chiar dacă 0x19 are probabil eroarea care poate introduce 32 Kbytes de zerouri în flash, nu puteți utiliza acest patch pe dispozitive cu versiunea de firmware 0x19. Acest patch efectuează un hack foarte specific la doi octeți de cod în firmware-ul revizuirii 0x25, iar patch-ul cel mai probabil că nu va funcționa pe 0x19 și, probabil, va cauza defecțiunea cipul în cel mai bun caz și va pierde date la cel mai rău. Există un motiv pentru care criteriile de selecție sunt atât de stricte pentru aplicarea acestui patch la firmware-ul emmc.Am transmis rezultatele noastre câteva zile mai târziu, menționând că sistemul de fișiere nu s-a corupt până la ștergere. Acesta este un răspuns la această urmărire.După cum am menționat în postarea anterioară, firmware-ul rev 0x19 are o eroare în care cipul emmc se poate bloca după ce este dată o comandă de ștergere. Nu de fiecare dată, dar destul de des. De obicei, dispozitivul se poate reporni după aceasta, dar apoi se poate bloca în timpul procesului de pornire. Foarte rar, se poate bloca chiar înainte ca fastboot să fie încărcat. Testerul tău a avut ghinion. Deoarece nici măcar nu puteți porni fastboot, dispozitivul este probabil blocat. :-( Dacă ar putea rula fastboot, atunci dispozitivul ar putea fi probabil recuperat cu codul de actualizare a firmware-ului pe care îl am, presupunând că îl pot partaja. Voi întreba.
Întrebare: De ce nu funcționează JTAG?Citat:
Postat inițial de Ken Sumrall (Android SE)
Deoarece /data este locul cipul care experimentează cea mai mare activitate de scriere. /system nu este niciodată scris în (cu excepția unei actualizări de sistem) și /cache este rar folosit (mai ales pentru a primi OTA).
Întrebare: Poate fi reparat un sistem de fișiere corupt (pe eMMC)?Citat:
Postat inițial de Ken Sumrall
După cum am menționat mai sus, firmware-ul revizuirii 0x19 a avut o eroare care, după o comandă de ștergere emmc, ar putea lăsa structurile de date interne ale cipului emmc într-o stare proastă care provoacă blocarea cipului atunci când un anumit sector a fost accesat. Singura soluție a fost să ștergeți cipul și să actualizați firmware-ul. Am cod pentru a face asta, dar nu știu dacă îl pot distribui. Voi întreba.
Deci, deși remedierea nu se aplică în cazul nostru momentan, ni s-au oferit o perspectivă excelentă asupra problemei superbrick, precum și informații despre o remediere este deja dezvoltat (sperăm că îl vom vedea lansat!). Eroarea probabil se aplică nouă și presupunând că este dată remedierea pentru firmware-ul 0x19, atunci s-ar aplica dispozitivelor noastre.Într-o notă mai ușoară, am vrut să includ închiderea lui:Citat:
Postat inițial de Ken Sumrall
e2fsck poate repara sistemul de fișiere, dar deseori cei 32 Kbytes au fost inserați la începutul unui grup de blocuri, ceea ce a șters multe inoduri și, astfel, rularea e2fsck ar duce adesea la pierderea multor fișiere.
Citat:
Postat inițial de Ken Sumrall
Obțineți o privire asupra vieții captivante a unui dezvoltator de kernel Android. :-) Se pare că munca se luptă mai ales cu hardware-ul cu probleme. Cel puțin, așa pare uneori.
Vă rugăm să rămâneți departe de a afișa orice ICS pe dispozitivele dvs. până când acest lucru este rezolvat.
Vrei ceva publicat în Portal? Contactați orice redactor de știri.
[Mulțumiri Entropia512 pentru toată munca ta grea!!!]