Kopš Samsung Galaxy S2 sērijas jaunākās noplūdes mūs ir skārušas pa kreisi un pa labi, cilvēki lēkā starp ROM, galvenokārt starp buggy, pirmsizlaides ICS būvējumiem un ļoti stabilu GB. Galu galā tas ir tas, ko mēs darām XDA kā ieradumu: mēs redzam noplūdi, mēs to nofiksējam, izmantojam un pielāgojam. Ja tas nelido, mēs vienkārši ritinām atpakaļ. Protams, mirgojoša informācija vienmēr ir saistīta ar risku, kam vispirms nevajadzētu būt jūsu ierīcē, taču ierīces pilnīgas bloķēšanas risks mūsdienās ir diezgan mazs. Jo īpaši tāpēc, ka ir pieejami rīki, lai atgrieztu jūsu ierīces no mirušajiem, piemēram, UnBrickable Mod XDA Elite atzītais izstrādātājs AdamOutler.
To sakot, šķiet, ka noplūžu pasaulē ne viss ir kārtībā. Paldies XDA Elite atzītajam izstrādātājam Entropija512, esam uzzinājuši, ka lielākajai daļai ierīču, kurās notiek noplūde, pastāv ļoti liels risks, ka tās nekad nepamostos pēc zibspuldzes. Izrādās, ka noplūdušajā ICS kodolā ir liela kļūda, kas ietekmē /data nodalījums eMMC mikroshēmā, kas acīmredzot tiek bojāts noteiktu darbību laikā, piemēram, noslaukot un mirgojot. Sākotnēji tika uzskatīts, ka tas ietekmē tikai darbības, kas veiktas pielāgotos atkopšanas procesos, piemēram, CWM. Tomēr ir saņemti ziņojumi par cietajiem ķieģeļiem, kas tiek ražoti no zibspuldzes
- Visi Epic 4G Touch (SPH-D710) ICS noplūde
- Visi Galaxy Note (GT-N7000) ICS noplūde
- The AT&T Galaxy S II (SGH-I777) UCLD3 noplūde — un, iespējams, arī visas pārējās
- Korejas SHW-M250S/K/L oficiālie laidieni un jebkurš kodols, kas izveidots no to avota
Entropy un citi izstrādātāji ir ievietojuši vairākus brīdinājumus, kas izkaisīti visā vietnē, kuros viņi detalizēti izskaidro notiekošo. Mūsu ieteikums ir, ka lietotājiem vajadzētu izvairīties no mirgojoša ICS no noplūdēm, līdz kodola kļūda ir pilnībā novērsta, ja vien jūs, protams, nevēlaties bloķēt ierīci. Atcerieties, ka to nevar atjaunot, izmantojot Unbrickable Mod vai pat JTAG, jo tā ir programmaparatūras kļūda eMMC. Tas ir tieši no paša Entropy tiem, kas interesējas par sīkāku informāciju:
APDRAUDĒJUMS: daudzi Samsung ICS kodoli var sabojāt jūsu ierīci!
Tie, kas pievērš uzmanību darbībām ar dažādām Samsung ierīcēm, iespējams, ir pamanījuši, ka dažās ierīcēs tiek izmantots liels daudzums cieto ķieģeļu, kad tiek izmantoti ICS noplūduši kodoli. Šie cietie ķieģeļi ir īpaši nejauki, jo JTAG pakalpojumu pārdevēji nav spējuši atjaunot šīs ierīces, atšķirībā no vienkāršiem sāknēšanas ielādētāja bojājumiem. Tas ir saistīts ar faktu, ka šie kodoli faktiski spēj radīt neatgriezeniskus bojājumus eMMC atmiņas ierīcei.
Ir apstiprināti ietekmētie kodoli:
[*]Visas Epic 4G Touch (SPH-D710) ICS noplūdes[*]Visas Galaxy Note (GT-N7000) ICS noplūdes[*] AT&T Galaxy S II (SGH-I777) UCLD3 noplūde — un, iespējams, arī visi citi[*]Korejas SHW-M250S/K/L oficiālie laidieni un jebkurš kodols, kas izveidots no tiem avots
Kodoliem, kuriem BŪTU jābūt drošiem, ir:
[*]GT-I9100 ICS noplūde[*]GT-I9100 oficiālie laidieni[*]Kodoli, kas veidoti no GT-I9100 Update4 avota bāzes
Darbības, kas var izraisīt bojājumus, palaižot ietekmēto kodolu:
Dzēšana CWM (un, iespējams, jebkura cita pielāgota atkopšana) (apstiprināta)
Nandroid dublējuma atjaunošana CWM (vispirms noslaukiet)
Citas programmaparatūras mirgošana programmā CWM (vispirms lielākā daļa mirgošanas gadījumu)
Tīrīšana noliktavā 3e atkopšana (aizdomas, arī noslauka nodalījumu)
Lielu failu dzēšana, palaižot ietekmēto kodolu (aizdomas, bet nav apstiprināts)
Ja jums ir ietekmēts kodols:
Nekavējoties mirgot labi zināmu kodolu, izmantojot Odin/Heimdall. NELIETOJIET zibspuldzi Mobile Odin, CWM vai jebkuru ierīcē iebūvētu metodi. Zināmi labi kodoli ietver:
[*]Gandrīz jebkurš Gingerbread kodols[*]ICS kodols, kas izveidots no GT-I9100 Update4 avota koda
Šīs problēmas galvenais iemesls vēl nav noskaidrots, tomēr daudzi atzīti XDA izstrādātāji uzskata, ka tas ir saistīts ar to, ka Samsung ir iespējojis kādu funkciju ietekmētie kodoli, MMC_CAP_ERASE — šī ir veiktspējas funkcija, kas var ievērojami palielināt zibatmiņas rakstīšanas veiktspēju, taču šķiet, ka tā atklāj zibatmiņas trūkumu čipsets. GT-I9100 ICS kodoliem šī funkcija nav iespējota, un tie šķiet droši. Tomēr ir zināms par maz, lai visus kodolus bez šīs funkcijas pasludinātu par drošiem — vienīgā vienība, kas var apstiprināt problēmas galveno cēloni. Samsung ir šī problēma un paziņot, ka tā ir novērsta, neuzņemoties lielu risku (iznīcinot vairākas ierīces bez iespējas tās salabot). paši.
Kopumā līdz turpmākam paziņojumam, ja izmantojat Samsung ICS noplūdi jebkurai Exynos ierīcei, kas nav GT-I9100, ir ļoti ieteicams mirgot kaut ko citu.
Un tas šorīt parādījās arī mūsu forumos, pateicoties XDA dalībniekam garwynn. Acīmredzot ar Google ir sazinājies, un viņi ir informēti par problēmu, un viens inženieris cer strādāt, lai to atrisinātu.
Ir pagājis kāds laiks, bet par laimi Sumrall kungs no Android atgriezās pie mums par mūsu jautājumiem. Es domāju, ka sabiedrība atklās, ka bija vērts gaidīt.Problēma: fwrev nav pareizi iestatīts.Kā mums bija aizdomas, ka kļūdu labojums nav mūsu būvējumā. (Plāris to lieto bez nosacījumiem.)Jautājums: pārskatīšana neatbilda labojumam(Uzsvars mans ar sarkanu, jo tas apspriež superķieģeļu jautājumu.)Citāts:
Sākotnēji ievietojis Kens Sumrals
Ielāps ietver rindiņu mmc.c iestatījuma fwrev tiesību bitiem no cid reģistra. Pirms šī ielāpa fails /sys/class/block/mmcblk0/device/fwrev netika inicializēts no CID emmc ierīcēm, kuru versija ir 4 un jaunāka, un tādējādi tika rādīta nulle.(Pēc otrās izmeklēšanas)fwrev ir nulle, līdz tiek uzlikts ielāps.
Jautājums: Kāpēc /data nodalījums?Citāts:
Sākotnēji ievietojis Kens Sumrals
Jums droši vien ir kļūda, bet rev 0x19 bija mūsu prototipa ierīcēs esošās programmaparatūras iepriekšējā versija, taču mēs atklājām, ka tai ir vēl viena kļūda, kas, ja jūs izdeva mmc dzēšanas komandu, tas var sabojāt datu struktūras mikroshēmā un novest pie ierīces bloķēšanas, līdz tā tiek ieslēgta. brauc ar velosipēdu. Mēs to atklājām, kad daudzi mūsu izstrādātāji veica ātrās sāknēšanas lietotāja datu dzēšanu, kamēr mēs izstrādājām ICS. Tāpēc Samsung novērsa problēmu un pārgāja uz programmaparatūras versiju 0x25.Jā, tas ir ļoti kaitinoši, ka 0x19 ir decimālskaitlis 25, un tas radīja daudz neskaidrību, mēģinot diagnosticēt emmc programmaparatūras problēmas. Beidzot es iemācījos _VIENMĒR_ atsaukties uz emmc versiju heksadecimālā veidā un pirms skaitļa ievadīt 0x, lai tas būtu nepārprotams.tomēr lai gan 0x19, iespējams, ir kļūda, kas zibspuldzē var ievietot 32 KB nulles, jūs nevarat izmantot šo ielāpu ierīcēs ar programmaparatūras versiju 0x19. Šis ielāps veic ļoti specifisku divu baitu koda uzlaušanu 0x25 versijas programmaparatūrā, un lielākā daļa visticamāk, nedarbosies ar 0x19 un, iespējams, labākajā gadījumā izraisīs mikroshēmas darbības traucējumus un datu zaudēšanu plkst sliktākais. Ir iemesls, kāpēc atlases kritēriji ir tik stingri, lai lietotu šo ielāpu emmc programmaparatūrai.Dažas dienas vēlāk es nosūtīju mūsu rezultātus, minot, ka failu sistēma nav bojāta līdz dzēšanai. Šī ir atbilde uz šo turpmāko darbību.Kā jau minēju iepriekšējā ziņojumā, programmaparatūras rev 0x19 ir kļūda, kurā emmc mikroshēma var tikt bloķēta pēc dzēšanas komandas došanas. Ne katru reizi, bet pietiekami bieži. Parasti ierīce pēc tam var atsāknēties, bet pēc tam sāknēšanas procesa laikā tiek bloķēta. Ļoti reti tas var bloķēties pat pirms ātrās palaišanas ielādes. Jūsu testētājam nepaveicās. Tā kā jūs pat nevarat palaist ātro sāknēšanu, ierīce, iespējams, ir nobloķēta. :-( Ja viņš varētu palaist fastboot, tad ierīci, iespējams, varētu atgūt ar programmaparatūras atjaunināšanas kodu, kas man ir, pieņemot, ka varu to koplietot. Es pajautāšu.
Jautājums: Kāpēc JTAG nedarbosies?Citāts:
Sākotnēji ievietojis Kens Sumrals (Android SE)
Tā kā /data ir vieta, kur mikroshēmā notiek vislielākā rakstīšanas darbība. /system nekad netiek rakstīts (izņemot sistēmas atjaunināšanas laikā), un /cache tiek izmantots reti (galvenokārt OTA saņemšanai).
Jautājums: vai var salabot bojātu failu sistēmu (eMMC)?Citāts:
Sākotnēji ievietojis Kens Sumrals
Kā jau minēju iepriekš, versijas 0x19 programmaparatūrai bija kļūda, kas pēc emmc erase komandas varēja atstāt emmc mikroshēmas iekšējās datu struktūras sliktā stāvoklī, kas izraisa mikroshēmas bloķēšanu, kad konkrēts sektors piekļūts. Vienīgais risinājums bija noslaucīt mikroshēmu un atjaunināt programmaparatūru. Man ir kods, lai to izdarītu, bet es nezinu, vai varu to kopīgot. Es pajautāšu.
Tātad, lai gan labojums uz mums pašlaik neattiecas, mums ir sniegts lielisks ieskats par izcilu ķieģeļu problēmu, kā arī informācija par labojumu. ir jau izstrādāts (cerams, ka mēs to redzēsim!). Kļūda, visticamāk, attiecas uz mums, un, pieņemot, ka 0x19 programmaparatūras labojums ir sniegts, tas attieksies uz mūsu ierīcēm.Vieglākā piezīmē es gribēju iekļaut viņa tuvumu:Citāts:
Sākotnēji ievietojis Kens Sumrals
e2fsck var labot failu sistēmu, taču bieži vien bloku grupas sākumā tika ievietoti 32 kbaiti, kas izdzēsa daudzas inodes, un tādējādi, palaižot e2fsck, daudzi faili bieži tiek pazaudēti.
Citāts:
Sākotnēji ievietojis Kens Sumrals
Jūs saņemat ieskatu aizraujošajā Android kodola izstrādātāja dzīvē. :-) Izrādās, darbs galvenokārt ir cīņa ar buggy aparatūru. Vismaz reizēm tā šķiet.
Lūdzu, izvairieties no ICS mirgošanas savās ierīcēs, līdz tas ir atrisināts.
Vai vēlaties kaut ko publicēt portālā? Sazinieties ar jebkuru ziņu autoru.
[Paldies Entropija512 par visu jūsu smago darbu!!!]