Od zadnjega uhajanja novic o liniji Samsung Galaxy S2 nas pretresajo levo in desno, ljudje skačejo med ROM-i, predvsem med različicami ICS pred izdajo, ki vsebujejo napake, in zelo stabilnimi GB. To je navsezadnje tisto, kar počnemo na XDA kot navada: opazimo puščanje, ga zasvetimo, uporabimo in prilagodimo. Če ne leti, se preprosto vrnemo nazaj. Seveda vedno obstaja neločljivo tveganje pri utripanju stvari, ki sploh ne bi smele biti v vaši napravi, vendar je tveganje, da bi napravo popolnoma zaklenili v današnjem času, precej majhno. Še posebej, ker so na voljo orodja za vrnitev vaših naprav iz mrtvih, kot je npr UnBrickable Mod avtor XDA Elite Recognized Developer AdamOutler.
Ob tem se zdi, da v svetu uhajanja ni vse v redu. Zahvaljujoč priznanemu razvijalcu XDA Elite Entropija512, smo izvedeli, da je večina naprav, ki prejemajo puščanje, izpostavljena zelo visokemu tveganju, da se po blisku nikoli ne prebudijo. Izkazalo se je, da je v razkritem jedru ICS velika napaka, ki vpliva na /data
particijo v čipu eMMC, ki se očitno poškoduje med določenimi operacijami, kot sta brisanje in utripanje. Prvotno je veljalo, da to vpliva samo na operacije, ki se izvajajo v obnovitvah po meri, kot je CWM. Vendar pa obstajajo poročila o trdih opekah, proizvedenih iz utripanja iz izterjava zalog prav tako. Prizadete naprave so:- Vse Epic 4G Touch (SPH-D710) Puščanje ICS
- Vse Galaxy Note (GT-N7000) Puščanje ICS
- The AT&T Galaxy S II (SGH-I777) Puščanje UCLD3 - in verjetno vsi drugi
- Korejske uradne izdaje SHW-M250S/K/L in vsa jedra, zgrajena iz njihovega izvora
Entropy in drugi razvijalci so objavili več opozoril, raztresenih po spletnem mestu, v katerih podrobno pojasnjujejo, kaj se dogaja. Naš predlog je, da se morajo uporabniki izogibati utripanju ICS pred uhajanjem, dokler napaka v jedru ni popolnoma odpravljena, razen če seveda želite svojo napravo močno zagraditi. Ne pozabite, da tega ni mogoče obuditi prek Unbrickable Mod ali celo prek JTAG, saj je to napaka vdelane programske opreme v eMMC. To je neposredno od samega Entropyja za tiste, ki vas zanima malo več podrobnosti:
NEVARNOST: Veliko puščajočih jeder Samsung ICS lahko poškoduje vašo napravo!
Tisti, ki so pozorni na dogajanje z različnimi napravami Samsung, so morda opazili, da se nekatere naprave soočajo z veliko količino trdih kock, ko se uporabljajo jedra, ki so ušla iz ICS. Ti hardbricks so še posebej neprijetni, ker prodajalci storitev JTAG teh naprav niso mogli oživiti, za razliko od preprostih hardbricks, ki poškodujejo zagonski nalagalnik. To je posledica dejstva, da ta jedra dejansko uspejo povzročiti, kar se zdi trajna škoda na napravi za shranjevanje eMMC.
Potrjeno prizadeta jedra so:
[*]Uhajanje vseh Epic 4G Touch (SPH-D710) ICS[*]Uhajanje vseh Galaxy Note (GT-N7000) ICS[*]AT&T Galaxy S II (SGH-I777) Uhajanje UCLD3 - in verjetno vse druge [*] uradne izdaje korejskih SHW-M250S/K/L in vsa jedra, zgrajena iz njihovih vir
Jedra, ki MORAJO biti varna, so:
[*]Uhajanje GT-I9100 ICS[*]Uradne izdaje GT-I9100[*]Jedra, zgrajena iz izvorne baze GT-I9100 Update4
Operacije, ki lahko povzročijo škodo pri izvajanju prizadetega jedra:
Brisanje v CWM (in verjetno v kateri koli drugi obnovitvi po meri) (potrjeno)
Obnovitev varnostne kopije Nandroid v CWM (najprej izbriše)
Utripanje druge vdelane programske opreme v CWM (večina bliskavic najprej izbriše)
Brisanje na zalogi 3e recovery (domnevno, izbriše tudi particijo)
Brisanje velikih datotek med izvajanjem prizadetega jedra (domnevno, vendar nepotrjeno)
Če imate prizadeto jedro:
Z Odin/Heimdallom takoj zaženite znano dobro jedro. Za bliskavico NE uporabljajte Mobile Odin, CWM ali katere koli druge metode v napravi. Znana dobra jedra vključujejo:
[*]Skoraj vsa jedra Gingerbread[*]Jedra ICS, zgrajena iz izvorne kode GT-I9100 Update4
Glavni vzrok te težave še ni bil ugotovljen, vendar številni priznani razvijalci v XDA domnevajo, da je posledica tega, da je Samsung omogočil funkcijo v prizadeta jedra, MMC_CAP_ERASE – To je funkcija zmogljivosti, ki lahko močno poveča zmogljivost zapisovanja v bliskovni ključ, vendar se zdi, da odkrije napako v bliskovnem ključu nabor čipov. Jedra ICS GT-I9100 nimajo omogočene te funkcije in se zdijo varna. Vendar ni dovolj znanega, da bi vsa jedra brez te funkcije razglasili za varna – edina entiteta, ki lahko potrdi temeljni vzrok to težavo in razglasite, da je odpravljena brez velikega tveganja (uničenje več naprav, ne da bi jih bilo mogoče popraviti), je Samsung sebe.
Na splošno velja, da do nadaljnjega priporočamo, da če imate puščanje Samsung ICS za katero koli napravo, ki temelji na Exynosu, razen GT-I9100, močno priporočljivo, da flešujete nekaj drugega.
In to se je zjutraj pokazalo tudi na naših forumih, z dovoljenjem člana XDA garwynn. Očitno so kontaktirali Google in so seznanjeni s težavo, en inženir pa upa, da bo poskušal odpraviti težavo.
No, minilo je že nekaj časa, a na srečo nam je g. Sumrall iz Androida odgovoril na naša vprašanja. Mislim, da bo skupnost ugotovila, da je bilo to vredno čakanja.Težava: fwrev ni pravilno nastavljen.Kot smo sumili, popravek napake ni v naši zgradbi. (Popravek to uporablja brezpogojno.)Vprašanje: Revizija se ni ujemala s popravkom(Poudari moje z rdečo, ko razpravlja o vprašanju superbrick.)Kvota:
Prvotno objavil Ken Sumrall
Popravek vključuje vrstico v mmc.c, ki nastavi fwrev na bite pravic iz registra cid. Pred tem popravkom datoteka /sys/class/block/mmcblk0/device/fwrev ni bila inicializirana iz CID-ja za naprave emmc rev 4 in višje, zato je prikazana nič.(Na drugo poizvedbo)fwrev je nič, dokler ni popravek nameščen.
Vprašanje: Zakaj particija /data?Kvota:
Prvotno objavil Ken Sumrall
Verjetno imate napako, toda rev. 0x19 je bila prejšnja različica vdelane programske opreme, ki smo jo imeli v naših prototipnih napravah, vendar smo ugotovili, da ima še eno napako, ki jo, če izda ukaz za brisanje mmc, lahko pokvari podatkovne strukture v čipu in povzroči, da se naprava zaklene, dokler se ne napaja ciklirano. To smo odkrili, ko je veliko naših razvijalcev izvajalo brisanje uporabniških podatkov s hitrim zagonom, medtem ko smo razvijali ICS. Tako je Samsung odpravil težavo in prešel na revizijo vdelane programske opreme 0x25.Da, zelo moteče je, da je 0x19 decimalno 25, kar je povzročilo veliko zmede pri poskusu diagnosticiranja težav z vdelano programsko opremo emmc. Končno sem se naučil _VEDNO_ sklicevati se na različico emmc v šestnajstiški obliki in pred številko postaviti 0x samo zaradi nedvoumnosti.vendar čeprav ima 0x19 verjetno napako, ki lahko v flash vstavi 32 Kbajtov ničel, tega popravka ne morete uporabiti v napravah z različico vdelane programske opreme 0x19. Ta popravek zelo specifično vdre v dva bajta kode v vdelani programski opremi revizije 0x25 in popravek najbolj verjetno ne bo delovalo na 0x19 in bo verjetno v najboljšem primeru povzročilo okvaro čipa in izgubo podatkov pri najhujši. Obstaja razlog, da so izbirna merila tako stroga za uporabo tega popravka v vdelani programski opremi emmc.Naše rezultate sem posredoval nekaj dni kasneje in omenil, da se datotečni sistem ni pokvaril do brisanja. To je odgovor na to nadaljevanje.Kot sem omenil v prejšnji objavi, ima vdelana programska oprema rev 0x19 napako, pri kateri se lahko čip emmc zaklene po podanem ukazu za brisanje. Ne vsakič, a dovolj pogosto. Običajno se lahko naprava po tem znova zažene, vendar se med postopkom zagona zaklene. Zelo redko se lahko zaklene, še preden se naloži hitri zagon. Vaš tester ni imel sreče. Ker ne morete niti zagnati hitrega zagona, je naprava verjetno zaklenjena. :-( Če bi lahko zagnal hitri zagon, potem bi napravo verjetno lahko obnovili s kodo za posodobitev vdelane programske opreme, ki jo imam, ob predpostavki, da jo lahko delim. Bom vprašal.
Vprašanje: Zakaj JTAG ne deluje?Kvota:
Prvotno objavil Ken Sumrall (Android SE)
Ker je /data mesto na čipu, kjer je največ zapisovalne dejavnosti. V /system se nikoli ne piše (razen med posodobitvijo sistema) in /cache se redko uporablja (večinoma za prejemanje OTA).
Vprašanje: Ali je mogoče poškodovan datotečni sistem popraviti (na eMMC)?Kvota:
Prvotno objavil Ken Sumrall
Kot sem omenil zgoraj, je imela vdelana programska oprema revizije 0x19 napako, da je po ukazu za brisanje emmc lahko zapustila notranje podatkovne strukture čipa emmc v slabem stanju, zaradi česar se čip zaklene, ko je bil določen sektor dostopali. Edina rešitev je bila brisanje čipa in posodobitev vdelane programske opreme. Imam kodo za to, vendar ne vem, ali jo lahko delim. Bom vprašal.
Torej, čeprav popravek trenutno ne velja za nas, smo dobili odličen vpogled v težavo superbrick in informacije, da popravek je že razvit (upajmo, da ga bomo videli izdanega!). Napaka verjetno velja za nas in ob predpostavki, da je popravek za vdelano programsko opremo 0x19 podan, potem velja za naše naprave.Na lažji način sem želel vključiti njegovo bližino:Kvota:
Prvotno objavil Ken Sumrall
e2fsck lahko popravi datotečni sistem, vendar je bilo pogosto 32 Kbajtov vstavljenih na začetku skupine blokov, kar je izbrisalo veliko inodov, zato bi izvajanje e2fsck pogosto povzročilo izgubo številnih datotek.
Kvota:
Prvotno objavil Ken Sumrall
Dobili boste vpogled v razburljivo življenje razvijalca jedra Android. :-) Izkazalo se je, da se delo večinoma bori s hroščasto strojno opremo. Vsaj včasih se zdi tako.
Prosimo, izogibajte se utripanju česar koli ICS na vaše naprave, dokler to ni rešeno.
Želite nekaj objaviti na portalu? Obrnite se na katerega koli pisca novic.
[Hvala Entropija512 za ves tvoj trud!!!]