|
Надёжность NAND flash |
|
|
|
Aug 29 2005, 12:32
|

Частый гость
 
Группа: Свой
Сообщений: 146
Регистрация: 6-01-05
Из: Украина
Пользователь №: 1 831

|
Только начал использовать и статистики по надежности пока нет. Пишут что 100.000 циклов. Если использовать ECC то должно намного больше, а если еще сделать предварительное кэширование, изоляцию битых страниц и блоков + циклическая запись для равномерного распределения обращений, то вообще должно получиться супер. Все только программно. Коды ECC в spare. После RAW чтения, коррекция одиночных выпаданий битов в основной 2048 области (например 1-н бит на 256 байт, или даже 2 бита). Пользовательские данные в spare защищены своим ECC, меньшей длины. Блоки у которых 1-й байт spare нуль (правильнее число бит <7, т.к. теоретически в нем тоже могут быть выпадания бит) программно не использовать. После стирания блока, при выдаче плохого статуса, самому пометить как плохой. Статус при записи бесполезен, т.к. возможные битовые ошибки могут быть исправлены кодом ECC, а он выдаст что это ошибка. Надо еще раз прочитать с коррекцией и сравнить с оригиналом. После всех этих операций NAND проживет дольше всего устройства. Хотя думаю очень многие просто используют не напрягаясь, и в этом случае все в итоге халявно.
|
|
|
|
|
Aug 29 2005, 14:03
|

Частый гость
 
Группа: Свой
Сообщений: 146
Регистрация: 6-01-05
Из: Украина
Пользователь №: 1 831

|
spare никак не отличается от обычной области. Можно сразу писать все в page (2048+64), а можно и по частям, а можно установить адрес на 2048 и писать только в spare. Также и читать: все, только spare или часть spare.
Для выделения инвалидного блока, предварительно (или уже после всей операции) чтением анализуйте первый байт spare, если плохой - то на следущий блок.
ECC считается (и выбирается тип кода) самим пользователем, NAND только как тупой носитель (2048+64) байт с возможностью битовых ошибок после длительного использования (У себя битовых ошибок пока не заметил, а вот битых блоков несколько штук, но это только начало использования). Наверно, когда последовательно пишите в NAND, то и считайте ECC, и после 2048 байта, пишите байт FF(как статус хорощего блока), затем подсчитанный ECC. А вот как потом при чтении исправить плохой бит - для ПЛИС наверно очень много геморроя.
R/B в нуле максимум 3ms при стирании, и при записи или чтении гораздо меньше. Залипаний не замечал, правда у меня там таймаут на превышение этого предела.
Думаю что для ПЛИС, использование ECC уже слишком, много ресурсов отъест, да и аппарат состояний не простой, может проще, если алгоритм использования в устройстве позволяет, при ошибке записи пометить страницу как стертую(программно, например байт 2 в spare) и перейти к следующей. Потом при чтении предварительно анализировать этот байт, и сделать такой же переход. Будет проще, при тойже надежности, правда емкость "израсходуется" быстрее.
|
|
|
|
|
Sep 7 2005, 10:30
|
Гуру
     
Группа: СуперМодераторы
Сообщений: 2 065
Регистрация: 11-01-05
Из: Москва
Пользователь №: 1 892

|
Цитата(Серокой @ Sep 7 2005, 14:16) А чем отличается yaffs от yaffs2? Там же четко писано http://www.aleph1.co.uk/yaffs/yaffs2.html* zero page rewrites means faster operation. (YAFFS1 uses a single rewrite in the spare area to delete a page). *ability to exploit simultaneous page programming on some chips. * improves performance relative to YAFFS1 speed(write:1.5x to 5x, delete: 4x, garbage collection: 2x) * lower RAM footprint (approx. 25% to 50% of YAFFS1). * Can support Toshiba/Sandisk MLC parts.
|
|
|
|
|
Sep 8 2005, 16:23
|

Участник

Группа: Свой
Сообщений: 55
Регистрация: 9-04-05
Из: г. Минск
Пользователь №: 3 984

|
Цитата(bmf @ Sep 8 2005, 10:07) c YAFFS работал скажу про недостатки: она не доделана (по тексту много замечаний) и больше не развивается (замещена пользу YAFFS2) сразу расчитайте сколько надо RAM - для 128M NAND при кластере в 8KB - 128K, а в оригинале кажется для 2K нужно - 512K это минимум Время запуска (ускоренная вычитка всех областей) для 128M - около 4sec Непредсказуемые задержки в процессе выполнения (при накоплении данных в gabrage collection происходит их длительная очистка и перемещение) для YAFFS2 структуры в памяти и требовательность к ресурсам еще больше соответствнно для 512M NAND - все в 4 раза больше и дольше единственное преимущество это нечувствительность к пропаданию питания как по мне - она (что YAFFS, что YAFFS2) только для ресурсоемких систем, а по времени старта вообще сомнительна для embedded Принцип работы - просто загрузить всю информацию о всех секторах и блоках в RAM и работать с ней, поэтому и такая ресурсоемкость и монстровитость. С YAFFS2 (direct-mode, ARM CPU 90 Mhz) работаю и сейчас (раньше использовал портированную jffs - это небо и земля) и не совсем с Вами согласен. 1. Расход памяти (RAM) - зависит от конфигурирования (исходных параметров). 2. Gabrage collection - медленноват для NOR-flash, для NAND - очистка сектора (страницы) достаточно быстра (~ 2 ms) и тормозов практически нет 3. перемещение - в этом же суть ФС для флеш-памяти! Благодаря этому, сохраняется ресурс секторов на запись - нет их быстрого "убивания" (идет равномерное использование)! 4. Для обеспечения быстродействия - разумный компромис между RAM и Flash диском (используя все ту же YAFFS2). 5. Приблизительно - у меня в embedde-system - 3 раздела/диска (1 RAM, и 2 - на разных чипах - flash) темп поступления инфо - не менее 500-800 байт в 20-100 мс, все прекрасно (размер конечного файла - не менее 6-8 МБ + 30-40 статичных БД/ИФ файлов, из к-рых читается инфа) 6. Небольшую чистку исх. файлов YAFFS2 можно сделать - с точки зрения оптимизации. Нормальный расход флеш (мой опыт): максим. использование объема - не более 60-70% (т.е., если, например, файлы совокупно будут использовать до 1 МБ, желательна флеш объемом не менее 1.6 МБ) P.S. 1. Для NAND - приведено время очистки блока, а не страницы. Например, если размер страницы 2К, то размер блока м.б. 128К - т.е. 64 страницы, и время очистки блока - порядка 2 миллисекунд 2. YAFFS работает с NAND со страницами в 512 байт (+ 16), YAFFS2 - с NAND со страницами в 2К
|
|
|
|
|
Sep 8 2005, 19:56
|

Участник

Группа: Свой
Сообщений: 55
Регистрация: 9-04-05
Из: г. Минск
Пользователь №: 3 984

|
Цитата(Evgeny_CD @ Sep 8 2005, 19:13) А что это за проц такой? На 90 Мгц... Cir Logic - EP7312-90 - 74/90 Мгц
|
|
|
|
|
Sep 9 2005, 08:08
|

Частый гость
 
Группа: Свой
Сообщений: 146
Регистрация: 6-01-05
Из: Украина
Пользователь №: 1 831

|
Цитата(si21 @ Sep 8 2005, 19:23) Расход памяти (RAM) - зависит от конфигурирования (исходных параметров). Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню) RAM для хранения служебной информации. Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас. Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными в spare. При таком допущении требования к дополнительной памяти, сложности и объема кода, быстродействие всей системы получается более чем на порядок! Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком).
|
|
|
|
|
Sep 9 2005, 11:16
|

Участник

Группа: Свой
Сообщений: 55
Регистрация: 9-04-05
Из: г. Минск
Пользователь №: 3 984

|
Цитата(bmf @ Sep 9 2005, 10:08) Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню) RAM для хранения служебной информации. Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас. Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными в spare. При таком допущении требования к дополнительной памяти, сложности и объема кода, быстродействие всей системы получается более чем на порядок! Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком). Да нет, как раз Linux и не пользую - слишком много гробится времени в переключателе задач/обработке пр-ий и относительно много RAM жрет. Здесь меня пока выручает uCOS (минимальные накладные расходы и время отклика). В YAFFS1/2 как раз и нет "наворотов полноценной файловой системы" - т.к. собственно сам интерфейс файловой системы (для direct-mode) реализован буквально в одном примитивном файле с набором вызовов к ядру ФС, но тем не менее, реализовано все, что требуется - например, я работаю с полнофункциональной СУБД собственной разработки ("минималистская" реализация) и не испытываю никаких ограничений. Но, естественно, это мой опыт и мое мнение
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|