Siden de siste lekkasjene for Samsung Galaxy S2-serien har truffet oss til venstre og høyre, har folk hoppet mellom ROM hovedsakelig mellom buggy, pre-release ICS builds og svært stabil GB. Dette er tross alt hva vi gjør på XDA som en vane: Vi ser en lekkasje, vi flasher den, bruker den og justerer den. Hvis den ikke flyr, ruller vi rett og slett tilbake. Selvfølgelig er det alltid en iboende risiko ved å blinke ting som ikke burde være på enheten din i utgangspunktet, men risikoen for å mure en enhet fullstendig i denne tiden er ganske liten. Spesielt siden det er verktøy tilgjengelig for å bringe enhetene dine tilbake fra de døde, for eksempel Unbrickable Mod av XDA Elite Recognized Developer AdamOutler.
Når dette er sagt, ser ikke alt ut til å være bra i lekkasjerverdenen. Takk til XDA Elite Recognized Developer Entropi512, har vi lært at de fleste enheter som mottar lekkasjer, har en svært høy risiko for aldri å våkne etter et blits. Det viser seg at det er en stor feil i den lekkede ICS-kjernen som påvirker
/data partisjon i eMMC-brikken, som tilsynelatende blir ødelagt under visse operasjoner som å tørke og blinke. Dette ble opprinnelig antatt å påvirke bare operasjoner utført i tilpassede gjenopprettinger som CWM. Det har imidlertid vært rapporter om hard murstein som ble produsert fra blinkingen fra aksjegjenvinninger også. De berørte enhetene er:- Alle Episk 4G Touch (SPH-D710) ICS-lekkasjer
- Alle Galaxy Note (GT-N7000) ICS-lekkasjer
- De AT&T Galaxy S II (SGH-I777) UCLD3-lekkasje - og sannsynligvis alle andre
- Koreanske SHW-M250S/K/L offisielle utgivelser og enhver kjerne bygget fra deres kilde
Entropy og andre utviklere har lagt ut flere advarsler spredt over hele nettstedet, der de forklarer i detalj hva som skjer. Vårt forslag er at brukere bør holde seg unna å blinke ICS fra lekkasjer inntil feilen i kjernen har blitt fullstendig fikset, med mindre du selvfølgelig ønsker å stenge enheten din hardt. Husk at dette ikke er noe som kan gjenopplives via Unbrickable Mod eller til og med via JTAG, da dette er en fastvarefeil i eMMC. Dette er direkte fra Entropy selv for de av dere som er interessert i litt mer detaljer:
FARE: Mange Samsung ICS-lekkasjekjerner kan skade enheten din!
De som er oppmerksomme på det som skjer med forskjellige Samsung-enheter kan ha lagt merke til at noen enheter opplever en stor mengde harde murstein når ICS-lekkede kjerner brukes. Disse harde mursteinene er spesielt ekle ved at leverandører av JTAG-tjenester ikke har vært i stand til å gjenopplive disse enhetene, i motsetning til enkle bootloader-korrupsjonshardbricks. Dette skyldes det faktum at disse kjernene faktisk klarer å forårsake det som ser ut til å være permanent skade på eMMC-lagringsenheten.
Kjerner som er bekreftet påvirket er:
[*]All Epic 4G Touch (SPH-D710) ICS-lekkasjer[*]Alle Galaxy Note (GT-N7000) ICS-lekkasjer[*]AT&T Galaxy S II (SGH-I777) UCLD3-lekkasje - og sannsynligvis alle andre[*]koreanske SHW-M250S/K/L offisielle utgivelser og enhver kjerne bygget fra deres kilde
Kjerner som BØR være trygge er:
[*]GT-I9100 ICS-lekkasjer[*]GT-I9100 offisielle utgivelser[*]Kjerner bygget av GT-I9100 Update4-kildebasen
Operasjoner som sannsynligvis vil forårsake skade når du kjører en berørt kjerne:
Tørking i CWM (og sannsynligvis annen tilpasset gjenoppretting) (bekreftet)
Gjenopprette en Nandroid-sikkerhetskopi i CWM (tørk først)
Blinker en annen fastvare i CWM (de fleste blinker tørk først)
Tørking på lager 3e-gjenoppretting (mistenkt, tørker også av en partisjon)
Sletting av store filer når du kjører en berørt kjerne (mistenkt, men ikke bekreftet)
Hvis du har en berørt kjerne:
Flash en kjent god kjerne med Odin/Heimdall umiddelbart. IKKE bruk Mobile Odin, CWM eller noen annen metode på enheten for å blinke. Kjente gode kjerner inkluderer:
[*]Nesten hvilken som helst pepperkakekjerne[*]ICS-kjerner bygget fra kildekoden GT-I9100 Update4
Grunnårsaken til dette problemet er ennå ikke fastslått, men mange anerkjente utviklere i XDA mistenker at det skyldes at Samsung har aktivert en funksjon i berørte kjerner, MMC_CAP_ERASE - Dette er en ytelsesfunksjon som kan øke flash-skriveytelsen betraktelig, men ser ut til å få frem en feil i flashen brikkesett. GT-I9100 ICS-kjerner har ikke denne funksjonen aktivert og virker trygge. Imidlertid er ikke nok kjent til å erklære alle kjerner uten denne funksjonen sikre - den eneste enheten som kan bekrefte rotårsaken til dette problemet og erklærer det løst uten å ta stor risiko (ødelegge flere enheter uten mulighet for å reparere dem) er Samsung dem selv.
Generelt, inntil videre, hvis du kjører en Samsung ICS-lekkasje for en annen Exynos-basert enhet enn GT-I9100, anbefales det på det sterkeste å blinke noe annet.
Og dette dukket nettopp opp denne morgenen i forumene våre også, med tillatelse fra XDA-medlem garwynn. Tilsynelatende har Google blitt kontaktet og de er klar over problemet, og en ingeniør håper å jobbe mot en løsning.
Vel, det har gått en stund, men heldigvis kom Mr. Sumrall fra Android tilbake til oss på spørsmålene våre. Jeg tror samfunnet vil finne at dette var verdt å vente på.Problem: fwrev ikke riktig innstilt.Som vi mistenkte, er ikke feilrettingen i bygget vårt. (Lappen bruker dette betingelsesløst.)Spørsmål: Revisjon samsvarte ikke med rettelsen(Uthev min i rødt når den diskuterer superbrick-spørsmålet.)Sitat:
Opprinnelig skrevet av Ken Sumrall
Patchen inkluderer en linje i mmc.c som setter fwrev til rettighetsbitene fra cid-registeret. Før denne oppdateringen ble ikke filen /sys/class/block/mmcblk0/device/fwrev initialisert fra CID for emmc-enheter rev 4 og høyere, og viste derfor null.(På andre henvendelse)fwrev er null til lappen settes på.
Spørsmål: Hvorfor /data-partisjonen?Sitat:
Opprinnelig skrevet av Ken Sumrall
Du har sannsynligvis feilen, men rev 0x19 var en tidligere versjon av fastvaren vi hadde i prototypeenhetene våre, men vi fant ut at den hadde en annen feil som hvis du utstedte en mmc slettekommando, kunne det skru opp datastrukturene i brikken og føre til at enheten låste seg til den ble slått på syklet. Vi oppdaget dette da mange av utviklerne våre gjorde en fastboot-sletting av brukerdata mens vi utviklet ICS. Så Samsung løste problemet og flyttet til firmware revisjon 0x25.Ja, det er veldig irriterende at 0x19 er desimal 25, og det førte til mye forvirring når man prøvde å diagnostisere emmc-fastvareproblemer. Jeg lærte endelig å _ALLTID_ referere til emmc-versjonen i heksadesimal, og gå foran tallet med 0x bare for å være entydig.Derimot, selv om 0x19 sannsynligvis har feilen som kan sette inn 32 Kbyte med nuller i blitsen, kan du ikke bruke denne oppdateringen på enheter med fastvareversjon 0x19. Denne oppdateringen gjør et veldig spesifikt hack til to byte med kode i revisjon 0x25-fastvaren, og oppdateringen mest vil sannsynligvis ikke fungere på 0x19, og vil sannsynligvis føre til at brikken i beste fall ikke fungerer, og mister data kl. verst. Det er en grunn til at valgkriteriene er så strenge for å bruke denne oppdateringen på emmc-fastvaren.Jeg videreformidlet resultatene våre noen dager senere og nevnte at filsystemet ikke ble ødelagt før tørket. Dette er et svar på den oppfølgingen.Som jeg nevnte i forrige innlegg, har firmware rev 0x19 en feil der emmc-brikken kan låse seg etter at en slettekommando er gitt. Ikke hver gang, men ofte nok. Vanligvis kan enheten starte på nytt etter dette, men deretter låses under oppstartsprosessen. Svært sjelden kan det låse seg selv før fastboot er lastet. Testeren din var uheldig. Siden du ikke engang kan starte fastboot, er enheten sannsynligvis murt. :-( Hvis han kunne kjøre fastboot, så kan enheten sannsynligvis gjenopprettes med fastvareoppdateringskoden jeg har, forutsatt at jeg kan dele den. Jeg skal spørre.
Spørsmål: Hvorfor fungerer ikke JTAG?Sitat:
Opprinnelig skrevet av Ken Sumrall (Android SE)
Fordi /data er stedet brikken som opplever mest skriveaktivitet. /system blir aldri skrevet til (bortsett fra under en systemoppdatering) og /cache brukes sjelden (mest for å motta OTA-er).
Spørsmål: Kan et ødelagt filsystem repareres (på eMMC)?Sitat:
Opprinnelig skrevet av Ken Sumrall
Som jeg nevner ovenfor, hadde revisjonen 0x19-fastvaren en feil som etter en emmc-slettekommando kunne forlate interne datastrukturer til emmc-brikken i dårlig tilstand som får brikken til å låse seg når en bestemt sektor var åpnet. Den eneste løsningen var å tørke av brikken og oppdatere fastvaren. Jeg har kode for å gjøre det, men jeg vet ikke om jeg kan dele den. Jeg skal spørre.
Så selv om løsningen ikke gjelder for oss for øyeblikket, har vi fått et godt innblikk i superbrick-problemet, samt informasjon som er en løsning er allerede utviklet (forhåpentligvis får vi se den utgitt!). Feilen gjelder sannsynligvis oss, og forutsatt at reparasjonen for 0x19-fastvaren er gitt, vil den gjelde for enhetene våre.På en lettere måte, jeg ønsket å inkludere hans nære:Sitat:
Opprinnelig skrevet av Ken Sumrall
e2fsck kan reparere filsystemet, men ofte ble de 32 kbytene satt inn i starten av en blokkgruppe, noe som slettet mange inoder, og dermed ville kjøring av e2fsck ofte resultere i at mange filer gikk tapt.
Sitat:
Opprinnelig skrevet av Ken Sumrall
Du får et innblikk i det spennende livet til en Android-kjerneutvikler. :-) Viser seg at jobben for det meste er å slåss med buggy-maskinvare. I det minste virker det sånn noen ganger.
Hold deg unna fra å blinke noe ICS på enhetene dine før dette er løst.
Vil du ha noe publisert i portalen? Kontakt hvilken som helst nyhetsskribent.
[Takk Entropi512 for alt ditt harde arbeid!!!]