Коррекция ошибок в NAND-FLash

[trt]

В декабрьской версии тритоновской программы (V5.8.56), добавлена возможность проверки и коррекции ошибок при работе с микросхемами NAND-FLash. Учитывая, что данная тема очень сложная, и не многие программаторы поддерживают эту функцию в полном объеме, вопросов может быть немало. Чтобы понять тематику вопросов и не объяснять каждому одно и то же, на основные вопросы я отвечу здесь.

Что сделано (версия V5.8.56).
- На данный момент программа поддерживает основные алгоритмы коррекции ошибок: Хемминга, Рида-Соломона, БЧХ.
- В режиме Автокоррекции программа распознает 50 различных конфигураций этих алгоритмов.
- Программа позволяет исправлять считываемые из микросхемы данные и очищать чужой файл от ошибок при записи микросхемы.
- Проверено около 80 разных микросхем и более 200 дампов от LCD телевизоров, спутниковых ресиверов, принтеров, DVD, DVR, GPS, WIFI...
- Из имеющегося архива программа определяет около 80% алгоритмов ECC.

Как это работает в программе.
После выбора микросхемы NAND, в меню "Коррекция ошибок" (это меню доступно при подключении программаторов V5.7T или V5.8T) можно выбрать нужный алгоритм ECC и настроить его параметры, либо выбрать режим Автокоррекции. В режиме Автокоррекции при ЧТЕНИИ микросхемы, программа вычисляет ECC для каждой страницы, сверяет его с ECC считанным из микросхемы, при необходимости корректирует ошибки, и сохраняет данные в буфере. При ЗАПИСИ микросхемы программа проверяет и исправляет ошибки в исходном файле (не меняя ECC), после чего пишет данные в микросхему. В отличии от других программаторов, Тритон только исправляет ошибки и НЕ МЕНЯЕТ ECC.
Те, кто разбираются в данном вопросе, могут настроить параметры для каждого алгоритма (организацию страниц, количество ошибок, адрес размещения ECC...), а также задать порядок обработки файла при записи (записать файл "как есть", проверить и исправить в нем ошибки, или перерассчитать ECC заново).

Вот пример записи микросхемы в режиме Автокоррекции. В исходном файле обнаружена и исправлена 831 ошибка. Записанная микросхема ошибок не имеет.


Или другой пример, запись многострадальной K9GAG08U0E. В большинстве случаев, без проверки ECC, программатор покажет, что все нормально. Но с учетом того, что в файле есть 21 страница с некорректируемыми ошибками, работа телевизора будет под вопросом.


Буду признателен за любые идеи или подсказки по этой теме. В случае, если эта информация конфиденциальна, это можно обсудить в личке или в техподдержке на сайте Тритона.

 

[sszer]

Или другой пример, запись многострадальной K9GAG08U0E. В большинстве случаев, без проверки ECC, программатор покажет, что все нормально. Но с учетом того, что в файле есть 21 страница с некорректируемыми ошибками, работа телевизора будет под вопросом.3 раза перечитал "Так и не понял кто на ком стоял" (c).
Что предлагается обсуждать?
Обход bad-блоков как правило осуществляется в устройстве процессором программно. Простые железки в работе после загрузки никакие ecc/crc не используют, и в бут процедурах проверяют целостность некоторых частей или всего флеша. И если все гут то все работает а если нет, то фиксируется наличие проблемы с вытекающими последствиями - незапуском или косяками в работе, как разработчик наразрабатывал. Ecc/crc и признак bad-блока пишется только при записи во флешь. И каким алгоритмом считаются контрольные суммы зависит опять же от разработчика. Если при записи на программаторе изменить алгоритм расчета сумм то в устройство не заработает. И все богатство выбора алгоритмов нужно для максимального покрытия существующих решений.
Если после записи флеша фиксируются ошибки в страницах которые не входят в bad-блок то следует пометить соответствующий блок признаком bad и переписать флешь заново с последующим контролем. Но если вся прошивка не войдет во флешь из-за уменьшения его размера флешь придется менять.
Сам писал софт для работы с нанд, разбора прошивки, сборки дампа, расчета контрольных сумм, обхода bad-блоков. Ничего сложного в этом нет.

Или другой пример, запись многострадальной K9GAG08U0E. В большинстве случаев, без проверки ECC, программатор покажет, что все нормально. Но с учетом того, что в файле есть 21 страница с некорректируемыми ошибками, работа телевизора будет под вопросом.

Это как? Содержимое страницы совпадает с дампом а ECC не сходится? Вывод простой - если данные верны а ECC кривое, то проблема не в странице с данными а в ECC.

 

[буржуй]

В исходном файле обнаружена и исправлена 831 ошибка. Записанная микросхема ошибок не имеет.

Это понятно, а устройство грузится будет?

 

[trt]

sszer, вообще-то, речь идет не о бэд блоках, а об исправлении ошибок при чтении микросхемы. Практически все устройства с NAND, поддерживают ECC. Без него нельзя гарантировать корректное чтение микросхемы. Даже 10 раз одинаково считанный на программаторе дамп МОЖЕТ содержать ошибки. А контроль ECC позволяет исправить такие ошибки и не плодить их от микросхемы к микросхеме.

Если при записи страницы данные не попадают в бэд блок, то большинстве случаев, микросхема НЕ выдает сообщение об ошибке и, чтобы выявить ее, надо прочитать страницу и проверить ECC. Если из-за каждой битовой ошибки, например в GAG08, маркировать блок как дефектный, то в микросхеме рабочим будет только первый блок.

Если Вы писали что-то кроме Хэмминга, то должны знать, что другие алгоритмы исправляют ошибки не только в данных, но в самой ECC тоже.

 

[sszer]

Еще раз объясняю - никакой коррекции по ECC дешевые процессоры применяемые в телевизорах, бытовых железках и прочем консумерском барахле при чтении из нанд не производят. Только программный контроль CRC страницы. Вы вообще понимаете что такое ECC? Какой объем spare области нужен чтобы хранить коды ECC каждой страницы и какой объем вычислений нужен для расчета ECC на страницу в 2048 байт?
Для примера - на 64 бита данных код Хэмминга длинной 8 бит сможет исправить ошибку в 1 бит и указать на наличие 2х и более неверных битов данных.
Если при верификации данных после записи в странице обнаружены недостоверные данные то нормальный подход такую страницу не использовать, пометит блок неисправным и переписать флешь заново с последующей верификацией.
Если после записи тут же "не отходя от кассы" данные недостоверны в массовом количестве то такой носитель следует выбросить в мусорку а не маскировать массовые дефектные страницы ECC. А для нормальных носителей количество bad-блоков как правило незначительно.

 

[trt]

Вы вообще понимаете что такое ECC? Какой объем spare области нужен чтобы хранить коды ECC каждой страницы и какой объем вычислений нужен для расчета ECC на страницу в 2048 байт?

Для исправления 1 битовой ошибки в блоке 256 или 512 байт используется 3 байта в алгоритме Хеминга.
Для исправления 4 байтовых ошибок в блоке 512 байт надо 10 байт для алгоритма Рида-Соломона.
Для исправления 4 битовых ошибок в блоке 512 байт надо 6,5 байт для алгоритма БЧХ.
Для исправления 8 битовых ошибок в блоке 512 байт надо 13 байт для алгоритма БЧХ.
Для исправления 8 битовых ошибок в блоке 2048 байт надо 15 байт для алгоритма БЧХ.

sszer, оставьте свои познания из школьного курса информатики для песочницы, и не надо спорить и рассказывать разработчику, как работает его устройство...

 

[sszer]

trt, в каких устройствах потребительского сегмента применяется защите данных с использованием ECC при чтении-записи "на лету"? CD в пример на приводите т.к. плейер в вычислительной его части представляет устройство для восстановления кодированных данных с носителя и не более того.
Фактически наличие поддержки ECC есть вынужденное усложнение архитектуры вычислительной структуры необходимое для отказоустойчивых вычислений и хранения данных. В идеале оно не должно никак влиять на работу и замедлять ее. И чтобы так и было это удовольствие будет иметь немалую цену решения. В потребительском секторе это дорого и не нужно никому. Особенно в условиях постоянной борьбы за снижения себестоимости. В корпоративном секторе действуют иные механизмы - поддержка ECC реализована но в ответственных местах носители превентивно заменяются по регламенту или по иным признакам не дожидаясь потери данных.
Странно что никому в голову не пришло реализовать в телевизорах отказоустойчивые вычисления.
А еще более странно что разработчик задает эти вопросы на форуме по ремонту телевизоров а не вычислительных систем.

 

[Brandmajor]

Моё ИМХО - тенденция такая, что производители уже отказываются от NAND. Больше встречаю в теликах сочетание процессора+SPI (25XX). Нет?

 

[trt]

А еще более странно что разработчик задает эти вопросы на форуме по ремонту телевизоров а не вычислительных систем.

Потому что этот вопрос напрямую касается ремонта телевизоров и вообще всех ремонтников, которые работают с микросхемами NAND.