Откакто последните изтичания на информация за линията на Samsung Galaxy S2 ни удрят наляво и надясно, хората прескачат между ROM главно между бъги, предварителни версии на ICS и много стабилен GB. В крайна сметка това е, което правим на XDA като навик: виждаме изтичане, флашваме го, използваме го и го настройваме. Ако не лети, просто се връщаме назад. Разбира се, винаги има присъщ риск от мигане на неща, които не трябва да са на вашето устройство на първо място, но рискът от пълно блокиране на устройство в днешно време е доста малък. Особено след като има налични инструменти за връщане на вашите устройства от мъртвите, като напр UnBrickable Mod от XDA Elite Recognized Developer АдамОутлър.
Като каза това, не всичко изглежда наред в света на течовете. Благодарение на XDA Elite Recognized Developer Ентропия512, научихме, че повечето устройства, които получават течове, са изложени на много висок риск никога да не се събудят след мигане. Оказва се, че има голяма грешка в изтеклото ядро на ICS, която засяга
/data дял в eMMC чипа, който очевидно се поврежда по време на определени операции като изтриване и мигане. Първоначално се смяташе, че това засяга само операциите, извършвани при персонализирани възстановявания, като CWM. Въпреки това, има съобщения за твърди тухли, произведени от мигащ от възстановяване на запаси както добре. Засегнатите устройства са:- всичко Epic 4G Touch (SPH-D710) Течове на ICS
- всичко Galaxy Note (GT-N7000) ICS течове
- The AT&T Galaxy S II (SGH-I777) Теч на UCLD3 - и вероятно всички останали
- Корейски официални версии на SHW-M250S/K/L и всяко ядро, изградено от техния източник
Entropy и други разработчици са публикували няколко предупреждения, разпръснати из сайта, в които обясняват подробно какво се случва. Нашето предложение е потребителите да стоят далеч от мигане на ICS от течове, докато грешката в ядрото не бъде напълно коригирана, освен ако, разбира се, не искате да блокирате устройството си. Не забравяйте, че това не е нещо, което може да бъде възкресено чрез Unbrickable Mod или дори чрез JTAG, тъй като това е грешка на фърмуера в eMMC. Това е директно от самия Entropy за тези от вас, които се интересуват от малко повече подробности:
ОПАСНОСТ: Много изтичащи ядра на Samsung ICS могат да повредят вашето устройство!
Тези, които обръщат внимание на случващото се с различни устройства на Samsung, може би са забелязали, че някои устройства изпитват голямо количество твърди тухли, когато се използват изтекли ядра от ICS. Тези хардбрикове са особено неприятни, тъй като доставчиците на JTAG услуги не са успели да възкресят тези устройства, за разлика от обикновените хардбрикове, повреждащи буутлоудъра. Това се дължи на факта, че тези ядра всъщност успяват да причинят това, което изглежда е трайна повреда на устройството за съхранение на eMMC.
Ядрата, за които е потвърдено, че са засегнати, са:
[*]Изтичане на ICS за всички Epic 4G Touch (SPH-D710)[*]Изтичане на ICS за всички Galaxy Note (GT-N7000)[*]AT&T Galaxy S II (SGH-I777) Изтичане на UCLD3 - и вероятно всички други[*]корейски официални версии на SHW-M250S/K/L и всяко ядро, изградено от техните източник
Ядрата, които ТРЯБВА да са безопасни, са:
[*]Изтичане на информация за GT-I9100 ICS[*]Официални издания на GT-I9100[*]Ядра, изградени на базата на изходния код на GT-I9100 Update4
Операции, които има вероятност да причинят щети при изпълнение на засегнато ядро:
Изтриване в CWM (и вероятно всяко друго персонализирано възстановяване) (потвърдено)
Възстановяване на резервно копие на Nandroid в CWM (първо изтриване)
Мигане на друг фърмуер в CWM (повечето мигания първо изтриват)
Изтриване на склад 3e възстановяване (предполага се, също изтрива дял)
Изтриване на големи файлове при стартиране на засегнато ядро (предполага се, но не е потвърдено)
Ако имате засегнато ядро:
Флаширайте известно добро ядро с помощта на Odin/Heimdall незабавно. НЕ използвайте Mobile Odin, CWM или друг метод на устройството за флашване. Известните добри ядра включват:
[*]Почти всяко ядро на Gingerbread[*]ICS ядра, изградени от изходния код на GT-I9100 Update4
Основната причина за този проблем все още не е установена, но много признати разработчици в XDA подозират, че това се дължи на това, че Samsung активира функция в засегнати ядра, MMC_CAP_ERASE - Това е функция за производителност, която може значително да увеличи производителността на флаш запис, но изглежда, че извежда наяве недостатък във флаш чипсет. GT-I9100 ICS ядрата нямат активирана тази функция и изглеждат безопасни. Не се знае обаче достатъчно, за да се обявят всички ядра без тази функция за безопасни - единственият обект, който може да потвърди основната причина за Samsung себе си.
Като цяло, до второ нареждане, ако стартирате изтичане на Samsung ICS за всяко устройство, базирано на Exynos, различно от GT-I9100, силно се препоръчва да флашнете нещо друго.
И това току-що се появи тази сутрин и в нашите форуми, с любезното съдействие на член на XDA гаруин. Очевидно Google се е свързал и те са наясно с проблема и един инженер се надява да работи за поправка.
Е, мина известно време, но за щастие г-н Sumrall от Android се свърза с нас по нашите въпроси. Мисля, че общността ще открие, че това си е струвало чакането.Проблем: fwrev не е зададен правилно.Както подозирахме, корекцията на грешки не е в нашата компилация. (Кръпката прилага това безусловно.)Въпрос: Ревизията не съответства на корекцията(Подчертайте моето в червено, тъй като обсъжда проблема със супертухлите.)цитат:
Първоначално публикувано от Кен Съмрал
Пачът включва ред в mmc.c, който задава fwrev на битовете за права от cid регистъра. Преди тази корекция файлът /sys/class/block/mmcblk0/device/fwrev не беше инициализиран от CID за emmc устройства rev 4 и по-нови и по този начин показваше нула.(При второ запитване)fwrev е нула, докато корекцията не бъде приложена.
Въпрос: Защо дялът /data?цитат:
Първоначално публикувано от Кен Съмрал
Вероятно имате грешката, но rev 0x19 беше предишна версия на фърмуера, който имахме в нашите прототипни устройства, но открихме, че има друга грешка, която ако издаде команда за изтриване на mmc, това може да прецака структурите от данни в чипа и да доведе до блокиране на устройството, докато не бъде захранвано цикличен. Открихме това, когато много от нашите разработчици правеха бързо изтриване на потребителски данни, докато разработвахме ICS. Така че Samsung отстрани проблема и премина към версия на фърмуера 0x25.Да, много е досадно, че 0x19 е десетична 25 и това доведе до много объркване, когато се опитвате да диагностицирате проблеми с фърмуера на emmc. Най-накрая се научих _ВИНАГИ_ да се позовавам на версията на emmc в шестнадесетичен формат и да предхождам числото с 0x, само за да бъда недвусмислен.Въпреки това, въпреки че 0x19 вероятно има грешка, която може да вмъкне 32 Kbytes нули във флаш, не можете да използвате тази корекция на устройства с версия на фърмуера 0x19. Тази корекция прави много специфичен хак на два байта код във фърмуера на ревизията 0x25 и корекцията най-много вероятно няма да работи на 0x19 и вероятно ще доведе до неизправност на чипа в най-добрия случай и загуба на данни при най-лошото. Има причина критериите за избор да са толкова строги за прилагане на тази корекция към фърмуера на emmc.Предадох резултатите ни няколко дни по-късно, като споменах, че файловата система не е повредена до изтриването. Това е отговор на това последващо действие.Както споменах в предишната публикация, версия на фърмуера 0x19 има грешка, при която emmc чипът може да блокира след подаване на команда за изтриване. Не всеки път, но достатъчно често. Обикновено устройството може да се рестартира след това, но след това блокира по време на процеса на зареждане. Много рядко може да блокира дори преди да се зареди fastboot. Вашият тестер нямаше късмет. Тъй като дори не можете да стартирате fastboot, устройството вероятно е блокирано. :-( Ако можеше да стартира fastboot, тогава устройството вероятно може да бъде възстановено с кода за актуализация на фърмуера, който имам, ако приемем, че мога да го споделя. Ще питам.
Въпрос: Защо JTAG не работи?цитат:
Първоначално публикувано от Кен Съмрал (Android SE)
Тъй като /data е мястото, където чипът има най-голяма активност при запис. В /system никога не се записва (освен по време на актуализация на системата) и /cache рядко се използва (най-вече за получаване на OTA).
Въпрос: Може ли повредена файлова система да бъде поправена (в eMMC)?цитат:
Първоначално публикувано от Кен Съмрал
Както споменах по-горе, версията на фърмуера 0x19 имаше грешка, която след команда за изтриване на emmc можеше да напусне вътрешни структури от данни на emmc чипа в лошо състояние, което кара чипа да се блокира, когато определен сектор е бил достъпен. Единственото решение беше да изтрия чипа и да актуализирам фърмуера. Имам код за това, но не знам дали мога да го споделя. Ще питам.
Така че, докато корекцията не се отнася за нас в момента, ние получихме страхотна представа за проблема със superbrick, както и информация, че корекция е вече е разработен (да се надяваме, че ще го видим пуснат!). Грешката вероятно се отнася за нас и ако приемем, че корекцията за фърмуера 0x19 е дадена, тогава тя ще се отнася за нашите устройства.По-леко, исках да включа неговото близко:цитат:
Първоначално публикувано от Кен Съмрал
e2fsck може да поправи файловата система, но често 32 Kbytes са били вмъкнати в началото на блокова група, което е изтрило много inode и по този начин изпълнението на e2fsck често би довело до загуба на много файлове.
цитат:
Първоначално публикувано от Кен Съмрал
Надниквате във вълнуващия живот на разработчик на ядрото на Android. :-) Оказва се, че работата е най-вече да се бориш с бъги хардуер. Поне така изглежда понякога.
Моля, пазете се от флашване на каквото и да било ICS на вашите устройства, докато това не бъде разрешено.
Искате нещо публикувано в Портала? Свържете се с всеки автор на новини.
[Благодаря Ентропия512 за целия ви труд!!!]