Amióta a Samsung Galaxy S2 termékcsalád legújabb kiszivárogtatásai balra és jobbra ütnek minket, az emberek főleg a hibás, kiadás előtti ICS buildek és a nagyon stabil GB között ugrálnak a ROM-ok között. Végül is ez az, amit az XDA-n szokásként csinálunk: látunk egy szivárgást, felvillantjuk, használjuk, és módosítjuk. Ha nem repül, egyszerűen visszagurulunk. Természetesen mindig van benne rejlő kockázat a villogó cuccokban, amelyeknek eleve nem kellene az eszközén lenniük, de a mai korban meglehetősen kicsi annak a kockázata, hogy egy eszközt teljesen leblokkolnak. Főleg, hogy rendelkezésre állnak olyan eszközök, amelyekkel visszahozhatod a halálból az eszközeidet, mint pl Unbrickable Mod az XDA Elite elismert fejlesztője AdamOutler.
Ha ezt elmondjuk, úgy tűnik, nincs minden rendben a kiszivárogtatások világában. Köszönet az XDA Elite elismert fejlesztőnek Entrópia512, megtudtuk, hogy a legtöbb olyan eszköz, amely szivárog, nagyon nagy a kockázata annak, hogy soha nem ébred fel villanás után. Kiderült, hogy a kiszivárgott ICS kernelben van egy nagy hiba, amely a
- Minden Epic 4G Touch (SPH-D710) ICS szivárog
- Minden Galaxy Note (GT-N7000) ICS szivárog
- A AT&T Galaxy S II (SGH-I777) UCLD3 szivárgás - és valószínűleg az összes többi
- A koreai SHW-M250S/K/L hivatalos kiadásai és a forrásukból épített kernel
Az Entropy és más fejlesztők számos figyelmeztetést tettek közzé az oldalon, amelyekben részletesen elmagyarázzák, mi történik. Javasoljuk, hogy a felhasználók tartózkodjanak attól, hogy a rendszermagban lévő hibát teljesen kijavítsák, amíg az ICS-t kiszivárogtatják, kivéve, ha természetesen meg akarja védeni eszközét. Ne feledje, ezt nem lehet feltámasztani Unbrickable Mod vagy akár JTAG segítségével, mivel ez egy firmware hiba az eMMC-ben. Ez közvetlenül magától az Entropytól származik azok számára, akiket kicsit részletesebben érdekel:
VESZÉLY: Sok Samsung ICS szivárgó kernel károsíthatja készülékét!
Azok, akik odafigyelnek a különféle Samsung-eszközökkel kapcsolatos folyamatokra, észrevehették, hogy egyes eszközök nagy mennyiségű keménytéglát tapasztalnak, amikor ICS-ből kiszivárgott kerneleket használnak. Ezek a hardbrickek különösen csúnyaak, mivel a JTAG-szolgáltatások szállítói nem tudták újraéleszteni ezeket az eszközöket, ellentétben az egyszerű bootloader-korrupciós hardbrickekkel. Ez annak a ténynek köszönhető, hogy ezek a kernelek ténylegesen tartósnak tűnő károsodást okoznak az eMMC tárolóeszközben.
A megerősített érintett kernelek a következők:
[*]Az összes Epic 4G Touch (SPH-D710) ICS szivárog[*]Minden Galaxy Note (GT-N7000) ICS szivárog[*]Az AT&T Galaxy S II (SGH-I777) UCLD3 kiszivárog – és valószínűleg az összes többi[*]koreai SHW-M250S/K/L hivatalos kiadása és a belőlük készült kernel forrás
A következő kerneleknek KELL biztonságosnak lenniük:
[*]A GT-I9100 ICS kiszivárog[*]A GT-I9100 hivatalos kiadása[*]A GT-I9100 Update4 forrásbázisára épülő kernelek
Műveletek, amelyek valószínűleg kárt okozhatnak az érintett kernel futtatásakor:
Törlés CWM-ben (és valószínűleg bármilyen más egyéni helyreállítás) (megerősítve)
Nandroid biztonsági mentés visszaállítása CWM-ben (először törölje le)
Egy másik firmware felvillantása CWM-ben (a legtöbb villanás törlése először)
Törlés raktáron 3e helyreállítás (gyanús, partíciót is töröl)
Nagy fájlok törlése érintett kernel futtatásakor (gyanús, de nem megerősített)
Ha érintett kernellel rendelkezik:
Azonnal villog egy ismert jó kernelt Odin/Heimdall segítségével. NE használjon Mobile Odint, CWM-et vagy bármilyen eszközön lévő módszert a villogáshoz. Az ismert jó kernelek a következők:
[*]Majdnem minden Gingerbread kernel[*]ICS kernel a GT-I9100 Update4 forráskódból
A probléma kiváltó okát még nem határozták meg, azonban számos elismert fejlesztő az XDA-ban azt gyanítja, hogy ez annak köszönhető, hogy a Samsung engedélyezte a funkciót a érintett kernelek, MMC_CAP_ERASE – Ez egy olyan teljesítményfunkció, amely nagymértékben növelheti a flash írási teljesítményét, de úgy tűnik, hogy kihozza a flash hibáját lapkakészlet. A GT-I9100 ICS kernelekben nincs engedélyezve ez a funkció, és biztonságosnak tűnnek. Nem ismeretes azonban eleget ahhoz, hogy minden rendszermagot biztonságossá nyilvánítsunk anélkül, hogy ez a szolgáltatás nélkülözné – ez az egyetlen entitás, amely meg tudja erősíteni a hiba kiváltó okát. ezt a problémát, és nagy kockázat vállalása nélkül (több eszköz megsemmisítése, javítás nélkül) kijelenti, hogy javítva a Samsung maguk.
Általánosságban elmondható, hogy további értesítésig, ha Samsung ICS-szivárgást futtat a GT-I9100-on kívüli bármely Exynos-alapú eszközön, erősen ajánlott valami más villogása.
És ez ma reggel megjelent a fórumainkon is, az XDA tag jóvoltából garwynn. Úgy tűnik, felvették a kapcsolatot a Google-lal, és tudatában vannak a problémának, és az egyik mérnök abban reménykedik, hogy dolgozhat a megoldáson.
Nos, eltelt egy kis idő, de szerencsére Mr. Sumrall az Androidtól visszatért hozzánk kérdéseinkkel. Szerintem a közösség rájön, hogy megérte várni.Probléma: az fwrev nincs megfelelően beállítva.Ahogy gyanítottuk, a hibajavítás nincs a mi buildünkben. (A javítás ezt feltétel nélkül alkalmazza.)Kérdés: A revízió nem egyezik a javítással(Kiemelés az enyémre pirossal, mivel a szupertégla kérdését tárgyalja.)Idézet:
Eredetileg közzétette Ken Sumrall
A javítás tartalmaz egy sort az mmc.c-ben, amely beállítja az fwrev-t a cid regiszter jogbitjeihez. A javítás előtt a /sys/class/block/mmcblk0/device/fwrev fájl nem lett inicializálva az emmc 4-es és újabb verziójú eszközök CID-jéből, és így nullát mutatott.(Második megkeresésre)Az fwrev nulla a javítás felhelyezéséig.
Kérdés: Miért a /data partíció?Idézet:
Eredetileg közzétette Ken Sumrall
Valószínűleg nálad van a hiba, de a rev 0x19 a prototípus eszközeinkben található firmware korábbi verziója volt, de azt találtuk, hogy van benne egy másik hiba is, amelyet ha kiadott egy mmc törlési parancsot, felcsavarhatja a chip adatstruktúráit, és az eszköz leblokkolásához vezethet, amíg be nem kapcsolták. kerékpározott. Ezt akkor fedeztük fel, amikor sok fejlesztőnk gyorsindítással törölte a felhasználói adatokat, miközben mi ICS-t fejlesztettünk. Így a Samsung kijavította a problémát, és áttért a 0x25-ös firmware-re.Igen, nagyon bosszantó, hogy a 0x19 a decimális 25, és ez sok zavart okozott az emmc firmware-problémák diagnosztizálása során. Végül megtanultam, hogy _MINDIG_ hexadecimálisan hivatkozzam az emmc verzióra, és a szám elé 0x kerüljön, hogy egyértelmű legyen.Azonban, annak ellenére, hogy a 0x19-ben valószínűleg megvan az a hiba, amely 32 Kbyte nullát tud beszúrni a flashbe, ez a javítás nem használható 0x19-es firmware-verziójú eszközökön. Ez a javítás nagyon specifikusan feltöri két bájt kódot a 0x25-ös verziójú firmware-ben, és a legtöbb javítás valószínűleg nem fog működni 0x19-en, és valószínűleg a chip hibás működését okozza, és adatvesztést okoz legrosszabb. Megvan az oka annak, hogy a kiválasztási kritériumok olyan szigorúak ahhoz, hogy ezt a javítást az emmc firmware-re alkalmazzák.Néhány nappal később továbbítottam az eredményeinket, megemlítve, hogy a fájlrendszer a törlésig nem sérült meg. Ez egy válasz erre a nyomon követésre.Ahogy az előző bejegyzésben említettem, a rev 0x19 firmware-nek van egy olyan hibája, ahol az emmc chip lefagyhat a törlési parancs kiadása után. Nem minden alkalommal, de elég gyakran. Általában ezután az eszköz újraindulhat, de az indítási folyamat során lefagy. Nagyon ritkán még a gyorsindítás betöltése előtt is leblokkolhat. A tesztelőd nem volt szerencsés. Mivel még a fastbootot sem tudod elindítani, valószínűleg be van rakva a készülék. :-( Ha futni tudná a fastbootot, akkor az eszköz valószínűleg helyreállítható a nálam lévő firmware-frissítési kóddal, feltételezve, hogy meg tudom osztani. Meg fogom kérdezni.
Kérdés: Miért nem működik a JTAG?Idézet:
Eredetileg közzétette Ken Sumrall (Android SE)
Mert a /data az a hely, ahol a chip a legtöbb írási tevékenységet tapasztalja. A /system fájlba soha nem ír (kivéve rendszerfrissítéskor), a /cache-t pedig ritkán használják (leginkább OTA fogadására).
Kérdés: Javítható-e a sérült fájlrendszer (az eMMC-n)?Idézet:
Eredetileg közzétette Ken Sumrall
Mint fentebb említettem, a 0x19-es verziójú firmware-nek volt egy olyan hibája, amely egy emmc erase parancs után elhagyhatja a az emmc chip belső adatstruktúrái rossz állapotban, ami miatt a chip leblokkol, amikor egy adott szektor elért. Az egyetlen megoldás a chip törlése és a firmware frissítése volt. Van kódom ehhez, de nem tudom, megoszthatom-e. Meg fogom kérdezni.
Tehát bár a javítás jelenleg nem vonatkozik ránk, nagyszerű betekintést kaptunk a szupertégla problémába, valamint a javításra van már kifejlesztve (remélhetőleg látni fogjuk, hogy kiadják!). A hiba valószínűleg ránk vonatkozik, és feltételezve, hogy a 0x19-es firmware javítása adott, akkor az eszközeinkre is vonatkozna.Könnyebb jegyzetben, szerettem volna belefoglalni a közelségét is:Idézet:
Eredetileg közzétette Ken Sumrall
Az e2fsck képes megjavítani a fájlrendszert, de gyakran a 32 Kbyte-ot egy blokkcsoport elejére helyezték be, ami sok inode-ot törölt, és így az e2fsck futtatása gyakran sok fájl elvesztésével járna.
Idézet:
Eredetileg közzétette Ken Sumrall
Bepillantást nyerhet egy Android kernel fejlesztő izgalmas életébe. :-) Kiderült, hogy a munka leginkább a bugos hardverrel való küzdelem. Legalábbis néha annak tűnik.
Kérjük, ügyeljen arra, hogy ne vigyen fel semmilyen ICS-t az eszközeire, amíg ez meg nem oldódik.
Szeretnél valamit közzétenni a Portálon? Vegye fel a kapcsolatot bármelyik híríróval.
[Kösz Entrópia512 minden kemény munkádért!!!]