JFFS2 на AT91SAM9XE-EK (+)

[OHara]

Всем добрый день!
Подскажите, кто, конкретно сталкивался с такой проблемкой! Имеется в
наличии kit AT91SAM9XE-EK. Скачал с сайта linux4sam.org
демонстрационный пакет (бинарники загрузчиков, ядро и файловую систему
jffs2), все установил - все работает. Решил подредактировать образ
корневой ФС на компе, чтобы каждый раз при записи ее в NAND не
выполнять одни и те же операции по настройке. Смонтировал, как описано
здесь http://wiki.openmoko.org/wiki/Jffs2 таким образом:

mknod /dev/mtdblock0 b 31 0
losetup /dev/loop0 $1
modprobe block2mtd
echo "/dev/loop0" > /sys/module/block2mtd/parameters/block2mtd
mount -t jffs2 /dev/mtdblock0 $2

Поправил, что нужно (добавил и подредактировал) и создал заново вот
так:

mkfs.jffs2 --root=rootfs --output=new_rootfs.jffs2 --pad=0xFE0000 --
little-endian --eraseblock=0x20000 -n

согласно тому, как это описано здесь http://wiki.openmoko.org/wiki/Userspace_root_image,
а также на основе анализа скриптов в OpenEmbedded (хотя крутил-вертел
уже как только можно). На выходе получаю файл корневой ФС, который
нормально монтируется на PC со всеми новыми изменениями, но не хочет
грузиться на плате. После загрузки ядра и попытки монтирования ФС
начинается полная "вакханалия":

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00700020:
0xfa81 instead
...
Empty flash at 0x006f5ffc ends at 0x006f6000
...

И так далее...

Параметр --eraseblock менял по-разному, ничего не помогает. Но на
компе в любом случае новый root монтируется без вопросов.

Подскажите, кто знает, в чем проблема!

[Norguhtar]

> mkfs.jffs2 --root=rootfs --output=new_rootfs.jffs2 --pad=0xFE0000 --
> little-endian --eraseblock=0x20000 -n

А у вас точно процессор в little-endian работает?

[OHara]

Без --little-endian тоже пробовал. Тот же результат.

[Anatoly Shipitsin]

2009/12/14 OHara <o_ha...@mail.ru>

Без --little-endian тоже пробовал. Тот же результат.

А смещение верно указано? Монтировать new_rootfs.jffs2 пробовали?

[OHara]

Кстати, если кому интересно, взял свой многострадальный
new_rootfs.jffs2 и залил в пустой доселе раздел NAND (с адреса
0x4000000), который присутствует как устройство mtdblock2. Загрузился
и смонтировал: mount -t jffs2 /dev/mtdblock2 /home/root/tmp.
Рузельтат - все ОК!! Файловая система смонтировалась и все там как
надо.
Чего же ей еще надо?! :(

[Anatoly Shipitsin]

2009/12/14 OHara <o_ha...@mail.ru>

Насколько я помню обычно первый блок содержит ядро и какая там FS может быть использована зависит от лоадера.

[OHara]

В общем, как все нормальные герои проблему решил проще: смонтировал
rootfs.jffs2 на компе, переписал ее в каталог на диске и дальше
работаю с этим каталогом. Отредактировал, что надо, и завернул
командой
mkfs.jffs2 --root=rootfs --output=new_rootfs.jffs2 --pad --
eraseblock=0x20000 -n
Все работает.
А до этого бился с тем, что редактировал смонтированный образ и из
него заворачивал. Посмотрел, что там получается в двоичных файлах и
увидел вот что: при монтировании через loop (1 вариант
http://wiki.openmoko.org/wiki/Userspace_root_image) сразу меняется
исходный файл: выбиваются пустые куски по 64Кб, то есть с периодом
128К повторяется ситуация, когда первые 64К совпадают с исходным, а
вторая чать - пустая (заполнена нулями). Но как ни странно при
монтировании затем этого образа и образа, созданного с него, на компе
визуально все Ок (хотя досконально не проверял).
Второй вариант из той же статьи тоже дает нерабочий вариант, если
исходный файл редактировать- удалять, добавлять файлы (точнее работает
с ошибками ). Такое ощущение, что неверно отрабатывает алгоритм
упаковки jffs2 "на лету", то есть если не вышел за границы
существующего сектора, то с файлом все Ок, в противном случае - ошибки
ФС.
Вообще-то, если посмотреть внимательно, то в этих примерах при
монтировании указывается или ro, или размер ram в точности равен
размеру образа (что не дает изменять данные). Найденные в интернете
варианты монтирования-изменения jffs2 для данного случая являются лишь
вариациями описанных в приведенной ссылке подходов.

[Anatoly Shipitsin]

Вообще все проще. У вас файловая система живет на эмуляторе NAND именно по этому так это выглядит. Но если ВНЕЗАПНО параметры того как эмулятор NAND работает с блоками отличен от того как работает NAND с блоками на реальной системе, то будет наблюдаться такая чехарда.

[OHara]

Я тоже это подозревал, что тут, видимо, дело в параметрах блочного
устройства, которые на target и host (Ubuntu 9.10), хотя, я при
эмуляции его на хосте задавал те же 128к и визуально все поднималось
без ошибок, ну, в общем, черт разберет. В интернете у народа тоже по-
разному: у кого-то работает, у кого-то нет.
Может, еще от linux'а зависит - говорят, что Ubuntu такими вещами
грешит, ну в общем как-то так....
Другое дело, что вопросов в инете по этому делу много, а вот рабочих
ответов, почти нет. Человек в результате сам разбирается и в лучшем
случае, пишет, что разобрался, в худшем - просто пропадает и ветка на
форуме подвисает.. :) Поэтому решил поделиться до конца своими
изысканиями.