Доброго времени суток!
Пишу драйвер для вот этой NAND и озадачился вопросом о битых секторах. В даташите написано, что на каждой флешке уже с завода может быть определенное количество битых секторов, и прежде чем ей пользоваться нужно при первом включении пробежаться алгоритмом, который указан все в том же даташите и запомнить адреса битых секторов. Я правильно понимаю, что мне нужна другая энергонезависимая память (например флеш на процессоре), чтобы хранить таблицу битых адресов? И нет других способов борьбы с ними?
Полная версия этой страницы: NANDFlash + микроконтроллер - как бороться с битыми секторами?
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
1. Битыми считаются блоки, а не сектора. Разница существенная.
2. Таблицу можно хранить в той же памяти в двух экземплярах.
2. Таблицу можно хранить в той же памяти в двух экземплярах.
Цитата(yanvasiij @ May 17 2016, 15:02) 
В даташите написано, что на каждой флешке уже с завода может быть определенное количество битых секторов, и прежде чем ей пользоваться нужно при первом включении пробежаться алгоритмом, который указан все в том же даташите и запомнить адреса битых секторов.
Зачем их запоминать? Они никуда не денуться, так что можно просто их не использовать при записи информации.Цитата
Я правильно понимаю, что мне нужна другая энергонезависимая память (например флеш на процессоре), чтобы хранить таблицу битых адресов? И нет других способов борьбы с ними?
Неправильно понимаете. Нужен такой алгоритм работы с FLASH, что бы он мог не использовать (как то обходить) сектора, которые являются битыми (более того, новые битые сектора могут появиться и в процессе работы)Цитата(aaarrr @ May 17 2016, 17:10)
1. Битыми считаются блоки, а не сектора. Разница существенная.
2. Таблицу можно хранить в той же памяти в двух экземплярах.
2. Таблицу можно хранить в той же памяти в двух экземплярах.
Да, верно блоки.
Цитата(XVR @ May 17 2016, 17:10)
Зачем их запоминать? Они никуда не денуться, так что можно просто их не использовать при записи информации.
Неправильно понимаете. Нужен такой алгоритм работы с FLASH, что бы он мог не использовать (как то обходить) сектора, которые являются битыми (более того, новые битые сектора могут появиться и в процессе работы)
Неправильно понимаете. Нужен такой алгоритм работы с FLASH, что бы он мог не использовать (как то обходить) сектора, которые являются битыми (более того, новые битые сектора могут появиться и в процессе работы)
А по какому признаку отличать битый блок от небитого? В даташите ясно сказано, что при первом запуске все небитые блоки во отлчии от битых равны 0xFF, и показано, как отличить битый блок от небитого. Но как только я начал писать во флешку это признак теряется. Следовательно таблицу битых блоков можно хранить в самой же флешке, но по какому адресу ее разместить, ведь от флешки к флешке один и тот же адрес может оказаться битым.
А по поводу алгоритма неиспользования битых секторов можно по-подробнее - этот как?
Цитата
Но как только я начал писать во флешку это признак теряется.
Пишите так, что бы этот признак не терялся (там всего 1 байт в расширенной области за это отвечает). Можно расширить признак - например хранить в этой области ECC (она для этого и сделана), и если ECC не совпал и коррекция невозможна, то проверять этот байт, если он не FF - то блок изначально битыйЦитата
А по поводу алгоритма неиспользования битых секторов можно по-подробнее - этот как?
Очень просто. Ваш алгоритм эаполнения FLASH должен быть готов к тому, что не все сектора можно будет использовать.Например - используем файловую систему, которая при записи файла использует цепочку секторов. При этом в последнее слово в секторе пишется номер следующего сектора. Если при выделении нового сектора в него не получится записать, то используется другой сектор, и именно его номер пишется в хвост предыдущего.
В принципе обычный FAT подойдет (если сделать ему возможность перемещать сам FAT). Хотя FAT не самый лучший вариант для FLASH по другим причинам
Цитата(yanvasiij @ May 17 2016, 15:26)
Следовательно таблицу битых блоков можно хранить в самой же флешке, но по какому адресу ее разместить, ведь от флешки к флешке один и тот же адрес может оказаться битым.
Нулевой блок гарантированно не битый. Я бы хранил таблицу битых блоков в нескольких фиксированных местах. Вероятность того, что они все одновременно будут/станут битыми очень мала.
Для исправления и детектирования ошибок используют код Хэмминга. Загуглите для начала tn2908_NAND_hamming_ECC_code.pdf При превышении определенного количества ошибок в блоке, нужно помечать блок как битый и обходить его при работе с флешкой.
способ 1:
Хранить таблицу битых блоков в первом исправном блоке. Таблица содержит CRC. Если CRC неверная - значит таблицы в этом блоке нет (вероятно блок битый), значит таблица в след. блоке.
И так далее, даже если с начала флешки цепочка битых блоков, всё равно таблица найдётся в первом исправном.
способ 2:
Что значит битые блоки? Блоки которые нельзя стереть (перевести в сост. "все FF")? А дописать в них можно?
Если да - алгоритм простой: резервируем в каждом блоке 1 байт для маркера блока. Если маркер==0xFF - блок исправный, иначе - неисправный. При первом старте на заводе все битые блоки метим, записывая в маркер !=0xFF (ну или там уже !=0xFF). При старте ПО в ОЗУ создаём таблицу битых блоков по маркерам.
Хранить таблицу битых блоков в первом исправном блоке. Таблица содержит CRC. Если CRC неверная - значит таблицы в этом блоке нет (вероятно блок битый), значит таблица в след. блоке.
И так далее, даже если с начала флешки цепочка битых блоков, всё равно таблица найдётся в первом исправном.
способ 2:
Что значит битые блоки? Блоки которые нельзя стереть (перевести в сост. "все FF")? А дописать в них можно?
Если да - алгоритм простой: резервируем в каждом блоке 1 байт для маркера блока. Если маркер==0xFF - блок исправный, иначе - неисправный. При первом старте на заводе все битые блоки метим, записывая в маркер !=0xFF (ну или там уже !=0xFF). При старте ПО в ОЗУ создаём таблицу битых блоков по маркерам.
Резюмируя вышесказанное XVR, dm.pogrebnoy , jcxz:
- Хранить таблицу битых блоков можно в самой флешке. Способ 1, который предложит jcxz мне понравился. Второй способ не подойдет, насколько я понял в битых блоках может быть, всё что угодно;
- Для выявления новых битых блоков и исправления ошибок, использовать алгоритм Хемминга, с занесением в таблицу битых блоков новые испорченные блоки;
Вопрос вероятно глупый, но если поднять файловую систему, она не будет делать все это за меня?
- Хранить таблицу битых блоков можно в самой флешке. Способ 1, который предложит jcxz мне понравился. Второй способ не подойдет, насколько я понял в битых блоках может быть, всё что угодно;
- Для выявления новых битых блоков и исправления ошибок, использовать алгоритм Хемминга, с занесением в таблицу битых блоков новые испорченные блоки;
Вопрос вероятно глупый, но если поднять файловую систему, она не будет делать все это за меня?
Цитата(jcxz @ May 18 2016, 07:42)
Что значит битые блоки? Блоки которые нельзя стереть (перевести в сост. "все FF")? А дописать в них можно?
битый блок содержит одну или более сбойную ячейку, т.е. может искажать информацию. Эти блоки могут беспроблемно стираться, но при последующей записи возможны ошибки, причем за счет кода с исправлением ошибок (Хэмминга и т.п.) возможно исправление этой единичной ошибки.
Лучше в помеченные сбойными блоки ничего не записывать, а при штатной записи оставлять байт с признаком небитого блока равным FF.
По поводу того, где хранить таблицу битых блоков - я делал считывание заголовков всех блоков при включении питания и хранение таблицы в ОЗУ.
Второй способ более правильный. Табличка битых блоков в ОЗУ, при старте пробегать по первым страницам каждого блока и смотреть:
- данных нет (всё 0xFF) - нормальный чистый блок
- данные есть, ECC сходится - нормальный занятый блок
- данные есть, ECC не сходится - битый блок
Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно...
Разве что NXFFS из NuttX должна довольно легко выдираться. Или yaffs смотреть. Я не пробовал, мы свой велосипед строили (зря, наверное, куча времени уходит...).
Всевозможные реализации Fat16/32 в чистом виде на NAND не ложатся никак.
Ещё есть всевозможные платные решения, но, мать их, всё закрыто - исходников нет, тестов нет, одни рекламные обещания "дайте нам денег, у нас всё самое-самое лучшее".
- данных нет (всё 0xFF) - нормальный чистый блок
- данные есть, ECC сходится - нормальный занятый блок
- данные есть, ECC не сходится - битый блок
Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно...
Разве что NXFFS из NuttX должна довольно легко выдираться. Или yaffs смотреть. Я не пробовал, мы свой велосипед строили (зря, наверное, куча времени уходит...).
Всевозможные реализации Fat16/32 в чистом виде на NAND не ложатся никак.
Ещё есть всевозможные платные решения, но, мать их, всё закрыто - исходников нет, тестов нет, одни рекламные обещания "дайте нам денег, у нас всё самое-самое лучшее".
Цитата(yanvasiij @ May 18 2016, 12:51)
Второй способ не подойдет, насколько я понял в битых блоках может быть, всё что угодно;
Вы не поняли. Скажем для флага выбрали 0-й байт блока.
Если в 0-м байте изначально не 0xFF - блок сбойный, даже не надо ничего делать. Если там не 0xFF - проверяем блок, если в любом байте !=0xFF, пишем в 0-й байт любое значение !=0xFF (не стирая страницы!).
Я не знаю как в данной флешке, но те SPI-FLASH с которыми я работал - всё позволяли модифицировать 1 байт внутри страницы не меняя остальные.
Если здесь не так и есть какой-то встроенный контроль блочными кодами исправления ошибок, то очевидно такой способ не подходит.
Цитата(novikovfb @ May 18 2016, 13:29)
битый блок содержит одну или более сбойную ячейку, т.е. может искажать информацию. Эти блоки могут беспроблемно стираться, но при последующей записи возможны ошибки, причем за счет кода с исправлением ошибок (Хэмминга и т.п.) возможно исправление этой единичной ошибки.
Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.
Цитата(esaulenka @ May 18 2016, 13:40)
Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно...
А что мешает использовать FatFS? LowLevel-IO там свой можно написать.
Цитата(jcxz @ May 18 2016, 11:28)
Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.
Я уверен, что разговор не о том.
Во-первых, слова 'SPI' в теме не было. Зато была ссылка на даташит и слово 'NAND'.
А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт.
Цитата(jcxz @ May 18 2016, 11:28)
А что мешает использовать FatFS? LowLevel-IO там свой можно написать.
Мешает отсутствие готового нижнего уровня. Этот нижний уровень, собственно, и должен решать вопросы:
- не каждый блок можно использовать (битые блоки)
- минимальный размер стирания - блок (16 килобайт в данной конкретной микросхеме)
- полезная штука - wear leveling, чтоб не "протереть дырку" в каком-то часто используемом месте.
А вот поверх этого всего можно и "обычную" ФС надстраивать...
Что-то посидел, подумал, порисовал алгоритмы всего этого. Многовато работы выходит, великоват велосипед. Наверно все-таки лучше попытаться yaffs. Если верить описанию он умеет и бэды и wear leveling. Его натягивание будет не быстрее чем писать самому, но думаю надежнее.
Цитата(jcxz @ May 18 2016, 11:28)
Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.
IMHO, использовать NAND Flash без программной (ручками в процессоре, сам чип памяти это не умеет) коррекции ошибок - неоправданный оптимизм, они даже в офисных условиях умудряются терять отдельные биты.
Цитата(esaulenka @ May 18 2016, 14:59)
Во-первых, слова 'SPI' в теме не было. Зато была ссылка на даташит и слово 'NAND'.
А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт.
А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт.
Если встроенных блочных кодов с исправлением ошибок в чипе нет, то тогда ничего не мешает использовать предложенный мной алгоритм маркирования сбойных блоков - дозаписью одного флагового байта (логическое AND с существующим содержимым байта).
И стирать их не надо, я и не предлагал этого.
Про SPI-FLASH упомянул так как только с ними я практически имел дело. Но вроде на уровне базовых операций между этими разными чипами не должно быть разницы... по идее.
Цитата(esaulenka @ May 18 2016, 14:59)
Мешает отсутствие готового нижнего уровня. Этот нижний уровень, собственно, и должен решать вопросы:
- не каждый блок можно использовать (битые блоки)
- не каждый блок можно использовать (битые блоки)
Это решается самой ФС.
Цитата(esaulenka @ May 18 2016, 14:59)
- минимальный размер стирания - блок (16 килобайт в данной конкретной микросхеме)
В обычных SD размер стирания тоже как правило гораздо больше размера блока записи. И ничего - работает FatFS.
Хотя не разбирался как там это реализовано.
Цитата(esaulenka @ May 18 2016, 14:59)
- полезная штука - wear leveling, чтоб не "протереть дырку" в каком-то часто используемом месте.
Несложно реализовать самостоятельно. Недавно я как раз реализовывал что-то подобное для SPI-FLASH-ки.
Тут будет конечно немного сложнее, так как в одном блоке стирания может быть несколько кластеров, но возможно.
Цитата(novikovfb @ May 18 2016, 18:13)
IMHO, использовать NAND Flash без программной (ручками в процессоре, сам чип памяти это не умеет) коррекции ошибок - неоправданный оптимизм, они даже в офисных условиях умудряются терять отдельные биты.
Что-то странное Вы говорите....
Я конечно на практике с параллельными FLASH не работал, но с SPI-FLASH (разными) у меня куча проектов. И готовых давно работающих, и в процессе разработки несколько.
И работают эти девайсы в далеко не тепличных условиях - на почти неотапливаемых подстанциях в тайге в мороз и жару.
И куча важной информации там хранится на этой флешь - и конфигурация и журналы событий и срезы мощности, а сейчас и осциллографирование туда осуществляется. И пишутся непрерывно и контроль непрерывно идёт. И почему-то нет сбоев как ни странно.
Неужто такое именно с параллельными FLASH происходит???
Цитата(jcxz @ May 18 2016, 21:26)
Неужто такое именно с параллельными FLASH происходит???
Именно. И чем тоньше технологические нормы и больше объем, тем большие требования предъявляются к механизму коррекции - до 100 бит/кБайт для MLC.
Цитата(jcxz @ May 18 2016, 23:26)
...
Это решается самой ФС.
...
Это решается самой ФС.
...
Что-то не совсем пойму, как ФС без нижнего уровня может решать где битый блок, а где нет, когда она понятия не имеет о том, с какой памятью она работает? В yaffs этот механизм реализован и специально заточен под NANDFlash, эта ФС по-сути и не умеет другие флешки, поэтому она наперед знает про битые блоки и умеет их.
Цитата(jcxz @ May 18 2016, 22:26)
В обычных SD размер стирания тоже как правило гораздо больше размера блока записи. И ничего - работает FatFS.
Хотя не разбирался как там это реализовано.
Хотя не разбирался как там это реализовано.
Правильно, потому что стиранием, бэдами и wear-leveling в SD карте занимается встроенный контроллер.
А FatFS делает только Read() и Write().
Цитата(jcxz @ May 18 2016, 22:26)
Неужто такое именно с параллельными FLASH происходит???
А в SPI Flash разве вообще бэды бывают?
Имхо - nand flash и spi flash это разные вещи...
Цитата(sonycman @ May 23 2016, 15:22)
А в SPI Flash разве вообще бэды бывают?
Имхо - nand flash и spi flash это разные вещи...
Имхо - nand flash и spi flash это разные вещи...
А в чём отличие (на физ. уровне ячеек хранения)?
Раз указано максимальное кол-во циклов стирания - значит могут быть и бэды.
Цитата(jcxz @ May 23 2016, 13:35)
А в чём отличие (на физ. уровне ячеек хранения)?
Раз указано максимальное кол-во циклов стирания - значит могут быть и бэды.
Раз указано максимальное кол-во циклов стирания - значит могут быть и бэды.
Отличие в разных технологиях.
Битые ячейки в nand - норма и неизбежность, а в spi flash - признак износа и исчерпания ресурса?
Смотря какая флеш, наверное.
У меня похожая задача, только нужно реализовать на ПЛИС.
Вопросец такой: а то, что первый блок NAND флешки всегда не битый - это стандарт или фича отдельного производителя? Например, микрон это в даташите не указывает.
Вопросец такой: а то, что первый блок NAND флешки всегда не битый - это стандарт или фича отдельного производителя? Например, микрон это в даташите не указывает.
Цитата(_Ivan_33 @ May 23 2016, 20:10)
Вопросец такой: а то, что первый блок NAND флешки всегда не битый - это стандарт или фича отдельного производителя? Например, микрон это в даташите не указывает.
Первый блок никак не стандартизирован. Гарантия исправности первого блока - инициатива части производителей в некоторых моделях чипов.
А вот по поводу ECC (Error Correction Code).
Как правило - NAND и ECC идут всегда рядом.
Интересуют исходники энкодера и декодера для ECC по Хафману (1 бит) и Риду-Соломону (4 бита).
Особенно совместимые с энкодером контроллера NAND процессора OMAP-L137.
Если вдруг кто занимался...
Для четырехбитного варианта хочу попробовать использовать библиотеку Schifra.
Как правило - NAND и ECC идут всегда рядом.
Интересуют исходники энкодера и декодера для ECC по Хафману (1 бит) и Риду-Соломону (4 бита).
Особенно совместимые с энкодером контроллера NAND процессора OMAP-L137.
Если вдруг кто занимался...
Для четырехбитного варианта хочу попробовать использовать библиотеку Schifra.
Удалось мне поднять yaffs на моем STM32F429. Единственное эта файловая система требует много памяти и выделяет себе эту память с помощью malloc. Поэтому пришлось выделить большую кучу и разместить ее во внешней SDRAM. Но в целом работает, бэды отлавливает.
А как решили хранить таблицу бэдов?
Какой используете код коррекции ошибок?
И сколько, к примеру, оперативной памяти требуется файловой системе для работы с разделом в 16 мегабайт (как я понял вы используете NAND128?).
Какой используете код коррекции ошибок?
И сколько, к примеру, оперативной памяти требуется файловой системе для работы с разделом в 16 мегабайт (как я понял вы используете NAND128?).
Цитата(sonycman @ Jun 28 2016, 00:26)
А как решили хранить таблицу бэдов?
Если поднять YAFFS, то мне нужно этим заниматься - это делает за меня файловая система. Бэды она учитывает размещая в spare area флешки данные отличные от FF. Определяет бэдовый ли блок по результатам записи.
Цитата
Какой используете код коррекции ошибок?
Коррекция ошибок ECC по Хаффману. Опять же это реализовано в самой файловой системе.
Цитата
И сколько, к примеру, оперативной памяти требуется файловой системе для работы с разделом в 16 мегабайт (как я понял вы используете NAND128?).
Да я работаю NAND128. Мне понадобилось порядка 30 kB в общей сложности.
Цитата(yanvasiij @ Jun 28 2016, 10:33)
Коррекция ошибок ECC по Хаффману. Опять же это реализовано в самой файловой системе.
Хм.. А какой-же тогда размер секторов в этой NAND-флешь? Получается - не равный степени двойки?
Я хотел сказать размер блока 16 k без учета spare. 1024 блока по 32 страницы, в каждой странице 512 байт данных и еще 16 байт дополнительная область (spare area).
Цитата(yanvasiij @ Jun 28 2016, 11:15)
Я хотел сказать размер блока 16 k без учета spare. 1024 блока по 32 страницы, в каждой странице 512 байт данных и еще 16 байт дополнительная область (spare area).
Ясно. Значит в этой spare-area и хранится избыточная контрольная информация.
Цитата(jcxz @ Jun 28 2016, 08:00)
Хм.. А какой-же тогда размер секторов в этой NAND-флешь? Получается - не равный степени двойки?
Полистайте на досуге любой (!) даташит на параллельную NAND.
Там размер страницы 528, 2112 и прочие "некратные".
Цитата(yanvasiij @ Jun 28 2016, 08:33)
Если поднять YAFFS, то мне нужно этим заниматься - это делает за меня файловая система. Бэды она учитывает размещая в spare area флешки данные отличные от FF. Определяет бэдовый ли блок по результатам записи.
А если на нанд есть бэды до разворачивания файловой системы? То есть ещё до записи присутствуют битые блоки?
Цитата(yanvasiij @ Jun 28 2016, 08:33)
Коррекция ошибок ECC по Хаффману. Опять же это реализовано в самой файловой системе.
То есть, насколько я понял из доков, это возможность коррекции ошибки в один бит на каждые 256 байт?
Цитата
Да я работаю NAND128. Мне понадобилось порядка 30 kB в общей сложности.
Не так уж и много
Вы используете первую версию Yaffs, насколько я понял?
Можно вас попросить - приведите, пожалуйста, полный дамп нескольких блоков nand с записанными данными и spare областями, интересно посмотреть расположение тэгов\ECC кодов.
Но тут, наверное, этим занимается ваш драйвер?
Цитата(sonycman @ Jun 28 2016, 10:45)
А если на нанд есть бэды до разворачивания файловой системы? То есть ещё до записи присутствуют битые блоки?
... то производитель флешки обычно обещает "в первой странице битого блока не будет FF". Этого достаточно, чтобы при форматировании разобраться, что происходит.
Цитата(sonycman @ Jun 28 2016, 10:45)
То есть, насколько я понял из доков, это возможность коррекции ошибки в один бит на каждые 256 байт?
Только мужика этого Хэмминг зовут :-)
Да, возможность коррекции одного бита (и обнаружения более сложных ошибок) на один блок. Длина блока может быть произвольной (обычно считают ECC по всей странице сразу).
Цитата(sonycman @ Jun 28 2016, 10:45)
Можно вас попросить - приведите, пожалуйста, полный дамп нескольких блоков nand с записанными данными и spare областями, интересно посмотреть расположение тэгов\ECC кодов.
Но тут, наверное, этим занимается ваш драйвер?
Но тут, наверное, этим занимается ваш драйвер?
По опыту изучения дампов NAND'а WinCE - занятие малоперспективное. Лучше уж эмулятор написать (исходники-то доступны!) и крутить там эту ФС, как душе угодно.
Цитата(esaulenka @ Jun 28 2016, 19:03)
Да, возможность коррекции одного бита (и обнаружения более сложных ошибок) на один блок. Длина блока может быть произвольной (обычно считают ECC по всей странице сразу).
Меня интересует конкретная реализация топикстартера.
И длина блока не может быть произвольной, так как от неё зависит количество избыточного кода.
А область spare данных всегда имеет конечную длину.
Цитата(esaulenka @ Jun 28 2016, 19:03)
По опыту изучения дампов NAND'а WinCE - занятие малоперспективное. Лучше уж эмулятор написать (исходники-то доступны!) и крутить там эту ФС, как душе угодно.
Расположение тегов ФС и кодов ECC зависит, вероятнее всего, от драйвера NAND.
Это снова реализация автора темы.
Цитата(yanvasiij @ Jun 28 2016, 08:33)
Если поднять YAFFS, то мне нужно этим заниматься - это делает за меня файловая система. Бэды она учитывает размещая в spare area флешки данные отличные от FF. Определяет бэдовый ли блок по результатам записи.
То есть таблица бэдов на флеш не создаётся?
Или все же создаётся, и сохраняется, но прозрачно от пользователя?
Цитата
А если на нанд есть бэды до разворачивания файловой системы? То есть ещё до записи присутствуют битые блоки?
На бэды проверка там делается следующим образом. C самого начала (с завода) флешка стерта, везде, в том числе и в области spare записаны 0xFF. В даташите написано, что если блок битый, то spare области c самого начала в первых двух байтах будет число отличное от FF. Файловая система так и работает - определяет битый блок, если первые два байта не FF и помечает битые блоки записывая в первые два байта spare 'Y' 'Y'. Если блок "ломается" в процессе, то файловая система обнаружит это в результате записи - запишет, считает и сравнит записанное и то что должно быть. Если запись не удалась, то пометить блок как битый и будет работать с другим.
Цитата
То есть, насколько я понял из доков, это возможность коррекции ошибки в один бит на каждые 256 байт?
Коррекция ошибок на один chunk - так они называют минимальную единицу записи. Как правило chunk совпадает по размеру со страницей, но можно это изменить. У меня ecc считается на 512 байт и в числе прочих дополнительных служебных данных располагается в области spare.
Цитата
Вы используете первую версию Yaffs, насколько я понял?
Можно вас попросить - приведите, пожалуйста, полный дамп нескольких блоков nand с записанными данными и spare областями, интересно посмотреть расположение тэгов\ECC кодов.
Но тут, наверное, этим занимается ваш драйвер?
Можно вас попросить - приведите, пожалуйста, полный дамп нескольких блоков nand с записанными данными и spare областями, интересно посмотреть расположение тэгов\ECC кодов.
Но тут, наверное, этим занимается ваш драйвер?
Да я использую первую yaffs, хотя при желании можно поднять и вторую.
По поводу дампа. Привожу пример работы программы для флешки, которая по-умолчанию была полностью стерта. Вот что я делаю:
Код
char str[] = "This string is placed id NAND!\r\n\0\0\0";
int f = yaffs_open("nand/file0.txt", O_CREAT | O_RDWR, (S_IREAD | S_IWRITE)); //открываю файл для записи
if ( f != -1)
{
yaffs_write(f, str, 35); //Если он успешно открылся записываю в него тестовую строку
yaffs_flush(f);
yaffs_close(f);//Закрываю файл
}
f = yaffs_open("nand/file0.txt", O_RDONLY, S_IREAD); //Открываю для чтения
if (f != -1)
{
memset (str, 0x00, 35);
yaffs_read(f, str, 35);//Считываю, то что записал
yaffs_close(f);
printf("----> %s \r\n", str); // Вывожу записанное
}
int f = yaffs_open("nand/file0.txt", O_CREAT | O_RDWR, (S_IREAD | S_IWRITE)); //открываю файл для записи
if ( f != -1)
{
yaffs_write(f, str, 35); //Если он успешно открылся записываю в него тестовую строку
yaffs_flush(f);
yaffs_close(f);//Закрываю файл
}
f = yaffs_open("nand/file0.txt", O_RDONLY, S_IREAD); //Открываю для чтения
if (f != -1)
{
memset (str, 0x00, 35);
yaffs_read(f, str, 35);//Считываю, то что записал
yaffs_close(f);
printf("----> %s \r\n", str); // Вывожу записанное
}
Файловая система общается с флешкой через 4 функции: записать странцу, считать страницу, записать spare, считать spare. Т.е. для работы нужно реализовать только эти 4 функции (это для yaffs1).
Что происходит с флешкой в момент работы вышеприведенного кода. В момент вызова yaffs_open() происходит следующее:
1) Считывается первый блок и его первая странци на предмет битости
CODE
yaffs_nareadPage ----------------------------------
page 0
len 512
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
readSpare -------------------------------
page 0
len 16
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
2) Блок небитый. Далее производится запись:
CODE
progPage ----------------------------------
page 0
len 512
0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0x66 0x69 0x6C 0x65 0x30 0x2E
0x74 0x78 0x74 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0x80 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF
0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
progSpare -------------------------------
page 0
len 16
0x00 0x00 0x10 0x00 0xFF 0xFF 0x01 0x03 0xCF 0xFF 0xC3 0x20 0xC1 0xFC 0xFF 0x03
После этого сразу проверяется запись:
CODE
readPage ----------------------------------
page 0
len 512
0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0x66 0x69 0x6C 0x65 0x30 0x2E
0x74 0x78 0x74 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0x80 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF
0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
readSpare -------------------------------
page 0
len 16
0x00 0x00 0x10 0x00 0xFF 0xFF 0x01 0x03 0xCF 0xFF 0xC3 0x20 0xC1 0xFC 0xFF 0x03
3) Далее yaffs_write() yaffs_flush() - запись строки во флеш:
CODE
progPage ----------------------------------
page 1
len 512
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xB6 0x41 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
progSpare -------------------------------
page 1
len 16
0x00 0x00 0x10 0x00 0xFF 0xFF 0x01 0x00 0xFF 0xFF 0xF3 0x2C 0xC1 0x5A 0xAA 0x97
progPage ----------------------------------
page 2
len 512
0x54 0x68 0x69 0x73 0x20 0x73 0x74 0x72 0x69 0x6E 0x67 0x20 0x69 0x73 0x20 0x70
0x6C 0x61 0x63 0x65 0x64 0x20 0x69 0x64 0x20 0x4E 0x41 0x4E 0x44 0x21 0x0D 0x0A
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
progSpare -------------------------------
page 2
len 16
0x01 0x00 0xD0 0x08 0xFF 0xFF 0x01 0x03 0x96 0xAA 0x9B 0x68 0xC1 0xFF 0xFF 0xFF
readPage ----------------------------------
page 0
len 512
0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0x66 0x69 0x6C 0x65 0x30 0x2E
0x74 0x78 0x74 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0x80 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF
0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
readSpare -------------------------------
page 0
len 16
0x00 0x00 0x10 0x00 0xFF 0xFF 0x01 0x03 0xCF 0xFF 0xC3 0x20 0xC1 0xFC 0xFF 0x03
progPage ----------------------------------
page 3
len 512
0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0xFF 0xFF 0x66 0x69 0x6C 0x65 0x30 0x2E
0x74 0x78 0x74 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0x80 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x23 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF
0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
progSpare -------------------------------
page 3
len 16
0x00 0x00 0x20 0x00 0xFF 0xFF 0x01 0x03 0xCF 0xFF 0xC3 0x2C 0xC1 0x99 0xA6 0x97
progSpare -------------------------------
page 0
len 16
0xFF 0xFF 0xFF 0xFF 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Остальные сектора файловая система не трогает.
Цитата(yanvasiij @ Jun 29 2016, 10:52)
На бэды проверка там делается следующим образом. C самого начала (с завода) флешка стерта, везде, в том числе и в области spare записаны 0xFF. В даташите написано, что если блок битый, то spare области c самого начала в первых двух байтах будет число отличное от FF. Файловая система так и работает - определяет битый блок, если первые два байта не FF и помечает битые блоки записывая в первые два байта spare 'Y' 'Y'. Если блок "ломается" в процессе, то файловая система обнаружит это в результате записи - запишет, считает и сравнит записанное и то что должно быть. Если запись не удалась, то пометить блок как битый и будет работать с другим.
Благодарю!
Весьма исчерпывающий ответ
Пару коммертариев.
Маркер битого блока находится не в первых двух байтах spare области, а, вероятнее всего - в шестом.
Так как в вашем примере первые 4 байта содержат, видимо, ECC коды, а последние 10 - тэги/прочая служебная информация.
Для 512 байт избыточный код по Хэммингу должен быть длиной 24 бита.
У вас - 32 бита. Возможно - неупакованные данные?
Цитата
Маркер битого блока находится не в первых двух байтах spare области, а, вероятнее всего - в шестом.
Да действительно в шестом.
Цитата
У вас - 32 бита. Возможно - неупакованные данные?
Тут, признаюсь, я сбит с толку. Я не думаю что это неупакованные данные, возможно это ошибка в моем драйвере - нужно внимательно проверить.
Цитата(yanvasiij @ Jun 29 2016, 13:15)
Тут, признаюсь, я сбит с толку. Я не думаю что это неупакованные данные, возможно это ошибка в моем драйвере - нужно внимательно проверить.
К примеру, spare область 512-ти байтовой страницы Yaffs может выглядеть так:
Код
30 30 99 FF FF FF FF FF 00 00 10 00 05 01 04 00
Первые три байта - упакованный код ECC (два слова по 12 бит - 24 бита в сумме), последние 8 байт - тэги файловой системы.
Я решил описать процесс портирования yaffs, если кому интересно вот ссылка.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.