З тих пір як останні витоки інформації про лінійку Samsung Galaxy S2 вразили нас наліво і направо, люди стрибали між ПЗУ, головним чином між попередніми версіями ICS із помилками та дуже стабільними ГБ. Це, зрештою, те, що ми робимо на XDA як звичку: ми бачимо витік, ми прошиваємо його, ми використовуємо його та ми налаштовуємо його. Якщо не летить, ми просто відкочуємося. Звичайно, завжди існує невід’ємний ризик перепрошивання речей, які не повинні бути на вашому пристрої, але ризик повністю заблокувати пристрій у наш час досить малий. Особливо тому, що існують інструменти, щоб повернути ваші пристрої з мертвих, наприклад UnBrickable Mod від XDA Elite Recognized Developer АдамОутлер.
Зважаючи на це, здається, не все гаразд у світі витоків. Завдяки XDA Elite Recognized Developer Ентропія512, ми дізналися, що більшість пристроїв, які отримують витік, мають дуже високий ризик ніколи не вийти з режиму сну після спалаху. Виявляється, у витоку ядра ICS є серйозна помилка, яка впливає на /data
- все 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 для тих із вас, кого цікавить трохи більше деталей:
НЕБЕЗПЕКА: багато ядер витоку ICS Samsung можуть пошкодити ваш пристрій!
Ті, хто звертає увагу на те, що відбувається з різними пристроями 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 – це функція продуктивності, яка може значно збільшити продуктивність запису на флеш-пам’ять, але, здається, виявляє недолік флеш-пам’яті чіпсет. У ядрах ICS GT-I9100 цю функцію не ввімкнено, і вони здаються безпечними. Однак відомо недостатньо, щоб оголосити всі ядра без цієї функції безпечними - єдина сутність, яка може підтвердити основну причину цю проблему та оголосити її вирішеною без великого ризику (знищення кількох пристроїв без можливості їх відремонтувати) — це Samsung себе.
Загалом, до подальшого повідомлення, якщо ви використовуєте витік Samsung ICS для будь-якого пристрою на базі Exynos, окрім GT-I9100, настійно рекомендуємо перепрошити щось інше.
І це також з’явилося сьогодні вранці на наших форумах, люб’язно надано членом XDA garwynn. Очевидно, Google зв’язався, і вони знають про проблему, і один інженер сподівається працювати над виправленням.
Що ж, минуло деякий час, але, на щастя, пан Самрал з 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 Кбайт нулів у флеш, ви не можете використовувати цей патч на пристроях із версією мікропрограми 0x19. Цей патч дуже специфічно зламує два байти коду в мікропрограмі версії 0x25, а патч найбільш ймовірно, не працюватиме на 0x19 і, ймовірно, спричинить несправність чіпа в кращому випадку та втрату даних у найгірше. Існує причина, по якій критерії вибору настільки суворі для застосування цього патча до мікропрограми emmc.Через кілька днів я передав наші результати, згадавши, що файлова система не була пошкоджена до стирання. Це відповідь на те подальше.Як я вже згадував у попередній публікації, версія мікропрограми 0x19 має помилку, через яку мікросхема emmc може блокуватися після введення команди стирання. Не кожен раз, але досить часто. Зазвичай після цього пристрій може перезавантажитися, але потім заблокується під час процесу завантаження. Дуже рідко він може заблокуватися ще до завантаження швидкого завантаження. Вашому тестеру не пощастило. Оскільки ви навіть не можете запустити швидке завантаження, пристрій, ймовірно, заблокований. :-( Якби він міг запустити швидке завантаження, тоді пристрій, ймовірно, можна було б відновити за допомогою коду оновлення мікропрограми, який у мене є, якщо я можу ним поділитися. Я запитаю.
Питання: Чому JTAG не працює?Цитата:
Спочатку опубліковано Кен Самрал (Android SE)
Тому що /data — це місце на чіпі, де відбувається найбільше запису. /system ніколи не записується (за винятком під час оновлення системи), а /cache рідко використовується (переважно для отримання OTA).
Запитання: чи можна відновити пошкоджену файлову систему (на eMMC)?Цитата:
Спочатку опубліковано Кен Самрал
Як я згадував вище, версія мікропрограми 0x19 мала помилку, через яку після команди emmc erase вона могла залишити внутрішні структури даних чіпа emmc у поганому стані, що спричиняє блокування чіпа, коли певний сектор був доступ. Єдиним виправленням було стерти мікросхему та оновити мікропрограму. У мене є код для цього, але я не знаю, чи можу я ним поділитися. Я запитаю.
Отже, хоча виправлення на даний момент не стосується нас, ми отримали чудове розуміння проблеми з суперцеглою, а також інформацію про те, що виправлення є вже розроблено (сподіваюся, ми побачимо його випуск!). Помилка, ймовірно, стосується нас, і якщо припустити, що виправлення для мікропрограми 0x19 надано, воно застосовуватиметься до наших пристроїв.На більш легкій ноті я хотів включити його близько:Цитата:
Спочатку опубліковано Кен Самрал
e2fsck може відновити файлову систему, але часто 32 Кбайти вставлялися на початку групи блоків, що стирало багато inode, і, таким чином, запуск e2fsck часто призводив до втрати багатьох файлів.
Цитата:
Спочатку опубліковано Кен Самрал
Ви зазирнете у захоплююче життя розробника ядра Android. :-) Виявляється, робота здебільшого полягає в боротьбі з глюковим обладнанням. Принаймні, іноді так здається.
Будь ласка, тримайтеся подалі від перепрошивання будь-яких ICS на ваші пристрої, доки це не буде вирішено.
Хочете опублікувати щось на порталі? Зверніться до будь-якого автора новин.
[Дякую Ентропія512 за всю вашу працю!!!]