Samsung galaxy s3 синдром внезапной смерти

Расскажу, что узнал про Синдром Внезапной Смерти / Sudden Death Syndrome / SDS на Samsung GT-I9300 Galaxy S3.
Прежде всего отмечу, что Samsung не делал никаких официальных заявлений про SDS. Как-то промелькнувший вопрос-ответ сотрудника Самсунга в СМИ, в расчёт не беру. Однако, на нашем форуме появляются сообщения с проблемами чтения и записи на внутреннюю флеш-память 16Gb при прошивке (например, Odin PC не может получить информацию о размещении разделов — зависает на Get PIT for mapping). Крайний случай — аппарат не загружается.

Известно, что Samsung периодически публикует исходный код прошивки, как того требует лицензионная политика Google для Android. Так вот, в публикации кодаUpdate7 был найден некий странный фикс (патч/заплатка/программный код, исправляющий проблему).

Что делает этот фикс? При каждой инициализации внутренней флешки обнуляет часть кода контроллера флеш-памяти (VTU00M — контроллер, eMMC или embedded MultiMediaCard — флеш-память, а всё вместе, образно говоря — диск). Очень похоже на решение проблемы нашего SDS в виде превентивной меры, хотя Самсунг официально о фиксе SDS не заявлял, как и не заявлял о факте наличия самого SDS.

Судя по коду фикса, существует накопительная ошибка при работе с контроллером флеш-памяти, которую фикс постоянно сбрасывает при инициализации флеш-памяти. Фикс не пишет микропрограмму в контроллер флеш-памяти, фикс не ставит фильтр на обращения к флеш-памяти — фикс постоянно обнуляет данные контроллера. Таким образом, эту процедуру не очень правильно называть фиксом как таковым, но решением проблемы (надеюсь, удачным). Однако, все привыкли к «фиксу SDS», так пусть фиксом и остаётся.

Забегая вперёд, озвучу мнение с форума XDA: во время работы может произойти порча блоков флеш-памяти, а фикс SDS предотвращает эту порчу.

Фикс находится в kernel (ядре), следовательно должен присутствовать как в boot основной прошивки, так и в boot рекавери. Список, где указаны содержащие данный фикс прошивки и части прошивок, постоянно пополняется здесь: [Important] Sudden Death Fix — Are you covered?.

1. При инициализации внутренней карты сверяется имя VTU00M и ревизия чипа f1.
2. Подаются 4 управляющих команды с целью проверки на наличие возвращаемой ошибки или ещё с какой целью.
3. Из памяти считывается дата.
4. Сверяется дата с 2012.04.13 (при чём сравнение такое: if (date != 0x20120413))
5. Если чип, ревизия и дата совпадают, то выполняется mmc_start_movi_operation (эта подпрограмма обозначена как экспортируемая)
6. В mmc_start_movi_operation я смог понять только то, что при каждом обращении забивается нулями часть памяти чипа.
Это всё.

Относительно наличия фикса SDS из Samsung Update7 в официальной прошивке 4.1.2 для России I9300XXELL4 Changelist : 566833, Date : 10.12.2012.

1. Напомню, фикс появился в открытом коде Update7. Привожу diff представленный AndreiLux (mmc: Soft-patch MoviNAND VTU00M (16GB) eMMC failure).
2. В фиксе есть специфические текстовые строки «CMD13(VC) failed» и «VTU00M», которые мы самостоятельно можем найти в бинарных файлах без сложных пассов с реинжинирингом.

Сначала один умелец взял текстовые строки из mmc_ops.c и mmc.c от Update7 «printk(KERN_ERR «CMD13(VC) failedn»)» и «if (!strncmp(host->card->cid.prod_name, «VTU00M», 6)», и нашёл их в LLA. Затем исследования на XDA показали, что следы кода Update7 есть во всех прошивках 4.1.2

3. Для самостоятельного нахождения потребуется файл boot.img. Я проверял на файле, взятом из CODE_I9300XXELL4_566833_REV00_user_low_ship.tar.md5 скорой помощи. Для поиска в кастомах, метод ниже может не сработать (случайные совпадения искомых кодов). Этот метод для стоков точно работает.
4. Нужен будет hex-редактор. Я взял Notepad++ и Hex Editor Plugin к нему.
5. Откройте boot.img в hex-редакторе.
6. Найдите первое совпадение по 1f 8b (начало gzip)
7. Удалите всё с адреса 0 до 1f8b (1f8b будет началом нашего нового файла)
8. Найдите строку 00 1f 8b (в некоторых кастомах это не первое, а второе совпадение)
9. Удалите всё после 00 от 1f8b до конца файла (наш 00 будет концом нового файла)
10. Сохраните файл с расширением gz. Я сохранил как boot.img.gz
11. Либо из 7zip, либо с помощью Total Commander (я проверял на v7.56a) извлеките файл (мой WinRAR с архивом не справился)

Откройте извлечённый файл и поищите там строку «VTU00M» и «CMD13(VC) failed». Если нашли, то у вас фикс есть.
Я нашел следы фикса в I9300XXELL4 SER:VTU00M <4>%s: movi operation is failed
<3>CMD13(VC) failed
А раз так, то в российской официальной прошивке I9300XXELL4 SER фикс есть! Таким образом, я подтверждаю исследования XDA! На всякий случай я проверил I9300XXEMB5, который относится уже к Update9 — фикс SDS никуда не делся.

Кстати, точно также можно проверить образ рекавери — recovery.img

Уже не подлежит сомнению, что фикс SDS имеется во всех без исключения прошивках 4.1.2. Это означает, что I9300 с прошивкой 4.1.2 и выше не должны быть подвержены SDS. Фикса SDS нет в 4.0.4 и в 4.1.1 прошивках.

Нам доступны для анализа две версии кода фикса — из Update7 и Update9. Написано, что Update9 соответствует прошивке XXEMB5. Так же там написано, что Update7 соответствует XXELLA, но если фикс SDS был найден в XXELL4, то не стоит безоговорочно верить администраторам opensource.samsung.com.

В сообщении Ultimate Galaxy S3 Unusual Freezing Thread предположено, что без фикса SDS портятся блоки флеш-памяти, а с фиксом SDS — не портятся, но телефон может замирать во время записи на уже испорченный блок. Так же указано, что начиная с версии XXEMB5 проблема замирания решена с новой версией фикса SDS… Ну, может и так, не знаю. По коду Update9 я этого не понял, но и на звание программиста не претендую. Не мне делать выводы.

В этом же сообщении предложен метод фиксации плохих блоков. Нужно установить прошивку имеющую фикс SDS, и несколько раз полностью забить флеш-память любыми данными для того, что бы система пометила плохие блоки во время этой операции, а не в тот момент, когда вам срочно нужен будет смартфон, ибо эта операция может нанять 5-20 минут на блок. ПО там прилагается.

I9300XXELKC, I9300XXELL1, I9300XXELL4, I9300XXELL5, I9300XXELL6, I9300XXELLA, I9300XXELLB, I9300XXELLC, I9300ZSEMA1, I9300XXEMA2, I9300XXEMB2, I9300XXEMB2, I9300XXEMB5, I9300XXEMR2, I9300ZSEMC1, I9300ZSEMC2, I9300ZSEMC3. Список не претендует на звание полного, но упоминающиеся в этой теме прошивки в списке есть.

На данный момент мне известно:
1. Mobile ODIN v3.65 при прошивке использует свой временный рекавери — FlashKernels, имеющий фикс SDS.
2. TWRP 2.4.x.x touch recovery имеет фикс SDS.
Если вас пугает SDS, то прошейте себе любую официальную прошивку версии 4.1.2, а лучше прошивку не ниже XXEMB5. Хуже точно не будет! Как понять, какая из прошивок новее, подробно расписано в этом сообщении.

Можете рутовать аппарат — факт рутования на SDS не влияет. Повлиять может разгон CPU, изменение разделов, да много чего под рутом можно сделать, но это уже другая тема.

Bootloader… Если исходить из логики, то в новых бутлоадерах защита от SDS быть должна. При этом, никто пока ещё не смог доказать, что в бутлоадере есть фикс SDS, в отличии от очевидных доказательств наличия фикса SDS в ядре. Решать вам, ставить новый бутлоадер или оставлять старый. Я себе оставил старый.

Статистика на этом форуме показывает, что подавляющее число ушедших в Сервисный Центр имели на борту смартфона прошивки 4.0.4 и 4.1.1. В СЦ фиксировали проблемы с флеш-памятью и меняли материнскую плату. Ремонт стоил от 8 до 12 тысяч рублей. Так стоит ли ставить 4.0.4 и 4.1.1 при наличии 4.1.2?..