Siden de seneste lækager til Samsung Galaxy S2-serien har ramt os til venstre og højre, har folk hoppet mellem ROM hovedsageligt mellem buggy, pre-release ICS builds og meget stabil GB. Det er trods alt, hvad vi gør på XDA som en vane: Vi ser en lækage, vi flasher den, vi bruger den, og vi justerer den. Hvis den ikke flyver, ruller vi bare tilbage. Selvfølgelig er der altid en iboende risiko ved at blinke ting, som ikke burde være på din enhed i første omgang, men risikoen for fuldt ud at mure en enhed i denne dag og alder er ret lille. Især da der findes værktøjer til at bringe dine enheder tilbage fra de døde, som f.eks Ubrikkelig Mod af XDA Elite Recognized Developer AdamOutler.
Når dette er sagt, ser ikke alt ud til at være i orden i lækagerverdenen. Tak til XDA Elite Recognized Developer Entropi512, har vi erfaret, at de fleste enheder, der modtager lækager, har en meget høj risiko for aldrig at vågne efter et blitz. Det viser sig, at der er en stor fejl i den lækkede ICS-kerne, der påvirker
/data partition i eMMC-chippen, som tilsyneladende bliver ødelagt under visse operationer, såsom at tørre og blinke. Dette blev oprindeligt antaget kun at påvirke operationer udført i tilpassede gendannelser såsom CWM. Der har dog været rapporter om, at der er blevet fremstillet hårde mursten fra inddækningen fra lagergenvindinger såvel. De berørte enheder er:- Alle Episk 4G Touch (SPH-D710) ICS-lækager
- Alle Galaxy Note (GT-N7000) ICS-lækager
- Det AT&T Galaxy S II (SGH-I777) UCLD3-lækage - og sandsynligvis alle andre
- Koreanske SHW-M250S/K/L officielle udgivelser og enhver kerne bygget fra deres kilde
Entropy og andre udviklere har postet adskillige advarsler spredt ud over webstedet, hvor de forklarer i detaljer, hvad der sker. Vores forslag er, at brugere skal holde sig væk fra at blinke ICS fra lækager, indtil fejlen i kernen er blevet fuldstændig rettet, medmindre du selvfølgelig søger at mure din enhed hårdt. Husk, at dette ikke er noget, der kan genoplives via Unbrickable Mod eller endda via JTAG, da dette er en firmwarefejl i eMMC. Dette er direkte fra Entropy selv for dem af jer, der er interesseret i lidt flere detaljer:
FARE: Mange Samsung ICS-lækkerner kan beskadige din enhed!
De, der er opmærksomme på, hvad der foregår med forskellige Samsung-enheder, har måske bemærket, at nogle enheder oplever en stor mængde hårde mursten, når ICS-lækkede kerner bruges. Disse hardbricks er særligt grimme, idet leverandører af JTAG-tjenester ikke har været i stand til at genoplive disse enheder, i modsætning til simple bootloader-korruption hardbricks. Dette skyldes det faktum, at disse kerner faktisk formår at forårsage, hvad der ser ud til at være permanent skade på eMMC-lagerenheden.
Kerner, der er bekræftet påvirket, er:
[*]Alle Epic 4G Touch (SPH-D710) ICS-lækager[*]Alle Galaxy Note (GT-N7000) ICS-lækager[*]AT&T Galaxy S II (SGH-I777) UCLD3 læk - og sandsynligvis alle andre[*]koreanske SHW-M250S/K/L officielle udgivelser og enhver kerne bygget fra deres kilde
Kerner, der BØR være sikre er:
[*]GT-I9100 ICS-lækager[*]GT-I9100 officielle udgivelser[*]Kerner bygget af GT-I9100 Update4-kildebasen
Handlinger, der sandsynligvis vil forårsage skade, når en berørt kerne kører:
Sletning i CWM (og sandsynligvis enhver anden tilpasset gendannelse) (bekræftet)
Gendannelse af en Nandroid-sikkerhedskopi i CWM (tør først)
Flashing af en anden firmware i CWM (de fleste blink slettes først)
Aftørring på lager 3e recovery (mistænkt, tørrer også en partition)
Sletning af store filer, når en berørt kerne kører (mistænkt, men ikke bekræftet)
Hvis du har en berørt kerne:
Flash en kendt god kerne ved hjælp af Odin/Heimdall med det samme. Brug IKKE Mobile Odin, CWM eller nogen anden metode på enheden til at flashe. Kendte gode kerner inkluderer:
[*]Næsten enhver Gingerbread-kerne[*]ICS-kerner bygget fra GT-I9100 Update4-kildekoden
Grundårsagen til dette problem er endnu ikke fastlagt, men adskillige anerkendte udviklere i XDA formoder, at det skyldes, at Samsung har aktiveret en funktion i berørte kerner, MMC_CAP_ERASE - Dette er en ydeevnefunktion, der i høj grad kan øge flash-skriveydelsen, men ser ud til at frembringe en fejl i flashen chipsæt. GT-I9100 ICS-kerner har ikke denne funktion aktiveret og virker sikre. Der er dog ikke kendt nok til at erklære alle kerner uden denne funktion sikre - den eneste enhed, der kan bekræfte årsagen til dette problem og erklærer det løst uden at tage stor risiko (ødelægge flere enheder uden mulighed for at reparere dem) er Samsung dem selv.
Generelt, indtil videre, hvis du kører en Samsung ICS-lækage for en hvilken som helst Exynos-baseret enhed, bortset fra GT-I9100, anbefales det kraftigt at flashe noget andet.
Og dette dukkede også lige op i morges i vores fora, høfligt af XDA-medlem garwynn. Tilsyneladende er Google blevet kontaktet, og de er opmærksomme på problemet, og en ingeniør håber at arbejde hen imod en løsning.
Nå, det er noget tid siden, men heldigvis vendte Mr. Sumrall fra Android tilbage til os med vores spørgsmål. Jeg tror, samfundet vil finde, at dette var ventetiden værd.Problem: fwrev ikke indstillet korrekt.Som vi havde mistanke om, er fejlrettelsen ikke i vores build. (Pachen anvender dette ubetinget.)Spørgsmål: Revisionen matchede ikke rettelsen(Fremhæv min med rødt, da det diskuterer superbrick-spørgsmålet.)Citere:
Oprindeligt indsendt af Ken Sumrall
Patchen inkluderer en linje i mmc.c, der indstiller fwrev til rettighedsbittene fra cid-registret. Før denne patch blev filen /sys/class/block/mmcblk0/device/fwrev ikke initialiseret fra CID'et for emmc-enheder rev 4 og nyere og viste derfor nul.(Ved anden forespørgsel)fwrev er nul, indtil plasteret er påsat.
Spørgsmål: Hvorfor /data-partitionen?Citere:
Oprindeligt indsendt af Ken Sumrall
Du har sikkert fejlen, men rev 0x19 var en tidligere version af den firmware, vi havde i vores prototypeenheder, men vi fandt ud af, at den havde en anden fejl, som hvis du udstedte en mmc slettekommando, kunne det skrue op for datastrukturerne i chippen og føre til, at enheden låste sig, indtil den blev tændt cyklet. Vi opdagede dette, da mange af vores udviklere lavede en fastboot-sletning af brugerdata, mens vi udviklede ICS. Så Samsung løste problemet og flyttede til firmwarerevision 0x25.Ja, det er meget irriterende, at 0x19 er decimal 25, og det førte til masser af forvirring, når man forsøgte at diagnosticere emmc-firmwareproblemer. Jeg lærte endelig at _ALTID_ henvise til emmc-versionen i hexadecimal og foran tallet med 0x bare for at være utvetydig.Imidlertid, selvom 0x19 sandsynligvis har fejlen, der kan indsætte 32 kbytes nuller i flashen, du kan ikke bruge denne patch på enheder med firmwareversion 0x19. Denne patch gør et meget specifikt hack til to bytes kode i revision 0x25 firmwaren, og patchen mest vil sandsynligvis ikke fungere på 0x19, og vil sandsynligvis få chippen til at fungere i bedste fald og miste data kl. værst. Der er en grund til, at udvælgelseskriterierne er så strenge for at anvende denne patch til emmc-firmwaren.Jeg videregav vores resultater et par dage senere og nævnte, at filsystemet ikke korrupte, før vi tørrede. Dette er et svar på den opfølgning.Som jeg nævnte i det forrige indlæg, har firmware rev 0x19 en fejl, hvor emmc chippen kan låse sig efter en slettekommando er givet. Ikke hver gang, men ofte nok. Normalt kan enheden genstarte efter dette, men derefter låses under opstartsprocessen. Meget sjældent kan det låse sig selv før fastboot er indlæst. Din tester var uheldig. Da du ikke engang kan starte fastboot, er enheden sandsynligvis muret. :-( Hvis han kunne køre fastboot, så kunne enheden sandsynligvis gendannes med den firmwareopdateringskode, jeg har, forudsat at jeg kan dele den. Jeg vil spørge.
Spørgsmål: Hvorfor virker JTAG ikke?Citere:
Oprindeligt indsendt af Ken Sumrall (Android SE)
Fordi /data er det sted, hvor chippen oplever mest skriveaktivitet. /system skrives aldrig til (undtagen under en systemopdatering), og /cache bruges sjældent (for det meste til at modtage OTA'er).
Spørgsmål: Kan et beskadiget filsystem repareres (på eMMC)?Citere:
Oprindeligt indsendt af Ken Sumrall
Som jeg nævnte ovenfor, havde revision 0x19 firmwaren en fejl, som efter en emmc slettekommando kunne forlade interne datastrukturer i emmc-chippen i en dårlig tilstand, der får chippen til at låse, når en bestemt sektor var tilgået. Den eneste rettelse var at tørre chippen og opdatere firmwaren. Jeg har kode til at gøre det, men jeg ved ikke, om jeg kan dele den. Jeg vil spørge.
Så selvom rettelsen ikke gælder for os i øjeblikket, har vi fået et godt indblik i superbrick-problemet samt information om, at en rettelse er allerede udviklet (forhåbentlig vil vi se det frigivet!). Fejlen gælder sandsynligvis for os, og forudsat at rettelsen til 0x19-firmwaren er givet, så vil den gælde for vores enheder.På en lettere bemærkning ville jeg inkludere hans nære:Citere:
Oprindeligt indsendt af Ken Sumrall
e2fsck kan reparere filsystemet, men ofte blev de 32 Kbytes indsat i starten af en blokgruppe, hvilket slettede mange inoder, og derfor ville kørsel af e2fsck ofte resultere i, at mange filer gik tabt.
Citere:
Oprindeligt indsendt af Ken Sumrall
Du får et indblik i det spændende liv for en Android-kerneudvikler. :-) Det viser sig, at jobbet for det meste er kampe med buggy hardware. Sådan virker det i hvert fald nogle gange.
Hold dig væk fra at blinke noget ICS på dine enheder, indtil dette er løst.
Vil du have noget offentliggjort i portalen? Kontakt enhver nyhedsforfatter.
[Tak Entropi512 for alt dit hårde arbejde!!!]