Испытываю Линукс 2.6.27 на плате Стартеркит с AT91sam9260.
К ядру применил патчи от Атмел (именно для этого ядра), а так же перенес в него файл board-... от Стартеркит.
Так же, назначил разделы в NAND-флеш определеного размера.
В Buildroot создал jffs2 образ точно такого же размера (для чистоты эксперимента).
Гружу ядро с заранее прошитого раздела /dev/mtdblock1.
ПРОБЛЕМА:
Не зависимо от спооба контроля ECC в ядре(hardware или software), вываливается много ошибок при монтировании (и чтении) файловой системы jffs2. Большинство ошибок типа "....ECC error". Хотя, в итоге все вцелом работает, инициализация системы проходит.
Об этих же ошибках многие пишут в Интернет на ино-сайтах. Слышал про какую-ю то ошибку в драйверах.
Кто с этим сталкивался?
Как решить проблему?
Если что то забыл написать - допишу...отвечу...
Странно, в свое всремя, с ядром 2.6.24 ставил JFFS2 на всю флешку, проблем не видел, ну а я бы на Вашем месте поставит YAFFS2 на это раздел.
Для чистоты эксперимента, отформатируйте этот раздел под JFFS2 (flash_eraseall -j) в самой системе, а потом подмонтируйте.
Спасибо за советы. С YAFFS2 попробую, но волнует то, что ведь и с JFFS2 обязано работать. Кроме того, файловую систему я постоянно создаю с помощью BuildRoot, и было бы очень неудобно каждый раз проделывать лишние манипулации "изнутри" Линукса (Как я понял, для этого нужно поместить образ ФС в другой раздел, а затем выполнять форматирование раздела mtdblock1 и делать в него дамп образа командой dd, либо путем обычного копирования ???)
Правда, я настроил U-BOOT на два варианта загрузки (с ramdisk в отдельной области флеш и с раздела во флеш), может это поможет придумать удобный способ "приведения в порядок" ФС во флеш....
Ну а кроме того, насколько я понимаю, ошибки ECC не зависят от конкретной ФС, а являются результатом:
1) Чтения бита подтверждения в физическом интерфейсе с NAND микросхемой (при контроле hardware)
2) Чтения регистра ECC, расположенного в каждой странице NAND-флеш (при контроле software).
Разовью свой вопрос, основываясь на своих скромных изысканиях...
Итак. Принцип механизма контроля/восстановления данных в NAND-флеш заключается в том, что при ЗАПИСИ кто-то должен поместить байты с кодом ECC в служебные байты каждой страницы флеш (этот ECC подсчитывается на основе самих записываемых данных, разумеется).
Далее, при ЧТЕНИИ можно повторно рассчитать ECC на основе реально(!) считанных данных, и сравнить с тем ECC, который был прописан в данную страницу флеш.
Если рассчитанный ЕСС при чтении и ранее записанный ЕСС во влеш отличаются, значит - считанные данные испорчены. В этом случае имеется возможность восстановить 1 (или 2) бита испорченных данных на странице флеш (это в частности зависит от конкретной микросхемы, размера одной страницы в ней и разрядности кода ECC)
Думаю, я тут не наделал ошибок..?
Сам код ЕСС можно рассчитывать двумя способами:
1) Hardware - используется аппаратный расчет ECC контроллером SAM9
2) Software - используется чисто программный расчет ECC (именно этот способ по умолчанию используется в настройках ядра Линукс, и в u-boot тоже).
Проблема в том, что записываемые во влеш коды ЕСС загрузчиком u-boot каким-то загадочным образом отличаются от тех кодов ЕСС, которые рассчитывает Линукс. Вот и получается, что реально мои данные в образе JFFS2 НЕ ПОВРЕЖДЕННЫЕ, а ядро сообщает постоянно об ошибке ЕCC.... Причем, u-boot позаимствовал исходные коды прямо из ядра Линукс! Значит, такого на самом деле происходить не должно...
Пути решения проблемы:
1) Найти причину в отличии ЕСС, рассчитываемого загрузчиком и ядром
2) Автоматически "лечить" файловую ситему при первом её использовании, запуская внутри Линукс некую программу, которая прописывала бы верные коды ЕСС во влеш.
_____________
Может кто-то подскажет секрет работы с u-boot, который позволил бы верно прописывать коды ECC при записи образов в НАНД-флеш ???
Или может кто-то знает как "подправить" ЕСС коды, не изменяя данные??? (то есть "вылечить" память)
Что скажут разработчики платы???
(замечу, что ошибка не исчезает если я пробую использовать загрузчик и ядро с диска Стартеркит)
Не понял, а зачем в этой "цепочке" u-boot?
Ядро стартует, в аргументах загрузки указываем раздел JFFS2, ну а поместить его туда наверное проще самбой, ну или скрипты создать которые раздел форматируют и по tftp нужные файлы инсталлируют ...
Да, согласен, хорошая мысль.
(Но я делаю систему, которую будут потом использовать другие люди, да и мне самому хотелось бы не совершать лишних манипуляций, так как и без этого уж очень много ручной работы по настройке программ в образе ФС)
То есть, я просто в первый раз (когда раздел во флеш еще пуст) гружу образ через u-boot, с неверными ЕСС. А уже потом, прямо внутри Линукс, в любой момент запускаю скрипт для "лечения" или "обновления" по TFTP раздела с rootfs ???
Хорошая мысль...
Но, можно ли загружать и обновлять из Линукса свой же раздел с rootfs ?
Может кто-то даст канву или идею - как создать такой скрипт?
То есть, создаем файл x.jffs2 как новый образ файловой системы jffs2, и одновременно копируем туда все содержимое из нашей текущей rootfs (путь /)
Или попроще, сначала просто создаем "пустой" образ:
mkfs.jffs2 --pad=0xF00000 -o x.jffs2 -e 0x4000 -n
Далее, можно дампировать полученный файл командой dd в отдельный (неиспольземый) раздел mtd:
dd if=x.jffs2 of=/dev/mtdbclok2
Ну а дальше...может просто перенести rootfs на новый созданный раздел mtdbclok2
Но!! тут возникает ряд проблем..
Самая неприятная из них заключается в том, что я не могу создать достаточно большой файл x.jffs2, так как просто напросто в ткущем разделе rootfs нет столько свободного места )))
Я пробовал..вываливается ошибка "нет места..."
Тогда, можно ли отформатировать раздел под jffs2 сразу прямо в разделе NAND-flash (без использования промежуточного файл образа) ???????????
Есть более простая по смыслу идея....но сложная в реализации...
Просто напросто, после каждого сообщения ядра "ECC error...." насильно перезаписывать ECC прямо в ядре (для этого добавить туда свой код). И при следующей загрузке такой проблемы с NAND уже не будет....
12.09.2009 08:31
12.09.2009 16:22
