В отличие от нашего предыдущего проекта, в Colibri стоит NAND флэш, а не NOR. NAND получает все большее и большее распространение в силу своей дешевизны и при этом большей вмесимости чем NOR (небольшое сравнение NOR  и NAND можно посмотреть тут).

Процессор Marvell PXA320 со своим встроенным NAND контроллером и сама микросхема NAND флэш поддерживаются основной веткой ядра. В общем, ничто не предвещало беды и было решено пойти  по накатанной – развернуть на NAND JFFS2 (Journaling Flash File System version 2) с корневой файловой системой.

Но тут вдруг обнаружилось что старый добрый JFFS2  мало того что полторы минуты сканирует NAND, дак еще и работать отказывается напрочь =(. Попробовав различные версии ядра, различные конфиги ядра и способы разворачивания файловой системы на флэш (монтирование и разворачивание из архива, запись образа напрямую в NAND) работоспособности я так и не добился. Ну да не JFFS-ом единым подумал я и стал смотреть в сторону других файловых систем.

Первым под руку попался проект YAFFS (Yet Another Flash File System) — пропатчил ядро (в основной ветки поддержки YAFFS нет, но это не беда – можно скачать патч с сайта проэкта и запатчить им ядро), собрал, запустил – сканирование всего раздела (чуть меньше гига) заняло минуту с небольшим, при последующих загрузках все происходило быстро, без задержек. Но при первом же аварийном завершении — опять минуту с небольшим. В остальном, вполне работоспособная вещь.

Вторым была выбрана UBIFS (Unsorted Block Image File System) – файловая система от создателей JFFS2. Перелопатив тонны описаний от разработчиков обнаружил интересную вещь – UBIFS состоит из двух частей – UBI (Unsorted Block Image) и UBIFS. UBI очень похож на LVM (Logical Volume Manager) – тоже поддерживает создание логических томов на одном физическом разделе. Причем  в роли файловой системы поверх UBI можно запустить тот же JFFS2, как утверждают разработчкики. А можно загрузить FTL (Flash Translations Layer) и получить обычное блочное устройство, на которое хоть EXT3 можно натянуть. При этом такие вещи, как журналирование и слежение за равномерным износом NAND будет выполнять UBI.

Я поставил поверх UBI файловою систему UBIFS. Разработчики обещали быстро и надежно, да и сравнительные тесты показывали тоже самое. Первый запуск – присоединение тома занимает около 10 секунд, монтирование происходит моментально, без задержек. Особенность UBI — присоединение тома занимает на гиговом разделе (том 900Мб. Почему не весь раздел — об этом далее) всегда занимает 10 секунд. С одной стороны, много. Но с другой, если работа была завершена аварийно, присоединение тома займет те же 10 секунд, но монтироваться система будет чуть дольше. Но с JFFS2/YAFFS все равно не сравнимо. Как и JFFS2, UBIFS  поддерживает сжатие on the fly, что уже не может не радовать.

Почему том не занимает весь раздел? Потому что UBI резервирует часть свободного места: если какой либо блок будет помечен как плохой то вместо него будет использоваться блок из свободного места. По умолчанию UBI резервирует 1% для этого, но это можно изменить в конфигурации ядра.

Cравнение различных файловых систем для raw flash — тут.

Почему в качестве файловой системы не была взята привычная ext2/ext3/raiserfs? А все потому, что эти системы рассчитаны на работу с блочным устройством, т.е. между самой памятью и ядром есть еще некая реализация FTL внутри устройства. NAND/NOR же таких продвинутых штук не имеют, да и не надо им это. По этому для них и используются такие хитрые файловые системы.

Для тех кто хочет помучать UBI и UBIFS , или кто хочет более детально разобраться:

1. http://www.linux-mtd.infradead.org/faq/ubi.html
2. http://www.linux-mtd.infradead.org/doc/ubi.html

Загуглив ранним утром на тему PXA320 NAND-контроллера я случайно наткнулся на проект, в котором разработка ведется ровно в том же направлении – поддержка OpenOCD процессора PXA320 и его NAND контроллера. Покурив исходники проекта и почитав блог разработчика было решено не изобретать еще один велосипед, а использовать уже готовый. Начали с OpenOCD – скачали, пропатчили, подключили нашего Франкенштейна (макет с Colibri на борту), а оно возьми да и заработай – TAP контроллер виден, NAND флэш виден и даже читается/пишется.

Дальше пришла очередь U-Boot. Посмотрев на доступные в данный момент компиляторы решил все-таки попытать счастья с arm-angstrom-linux-uclibceabi-gcc версии  4.3.3. Собрал, прошил, но счастья не вышло – U-Boot нещадно вис после вывода инфы о NAND флэшке.

Собрали тулчейн на базе gcc-4.2.2 и glibc, пересобрали U-Boot, прошили (прошивка – это отдельная песня: 256 Kb прошивается за 23 минуты, но лучше уж так, чем никак) – работает!

Скачали последнее ядро с kernel.org, собрали, загрузили в память по tftp – висит. Потом были многие часы развлекалова с разными версиями компилятора, конфигами, грязным хаком функции printk(), разными Load Point и Entri Point.

Ключевыми моментами оказались:

• компилятор arm-angstrom-linux-gnueabi-gcc версии 4.2.2 (тот же что и для U-Boot)
• выключенная опция Enable stack unwinding support в конфиге ядра
• загружать uImage надо в память по адресу 0×80000000 (не смотря на Load point: 0xa0008000 )

Не хватает только initramfs, но об этом в следующих сериях :)

Фоторепортаж с места событий:

Если не будет лень, а лень нам не будет, попробуем ради интереса перенести на него функционал Беркут-ММТ.

Сам патч через неделю-полторы будет отправлен разработчикам openocd.