Такой подход позволяет использовать стандартные средства ping и traceroute.

Для реализации сетевого интерфейса (как собственно и консоли карты) использовался любимый нами USB-шный класс CDC (Communication Device Class). В этот класс входят подклассы позволяющие реализовать интерфейсы к телефонным линиям, модемы и сетевые карты (проводные и беспроводные). Большим плюсом использования стандартного класса USB-устройства, является отсутствие необходимости писать драйвера (в Linux/*nix, Windows всё равно требует хотя бы .inf файл).

Так вот сетевых устройств в классе CDC может быть несколько видов. Это подклассы ECM,EEM, NCM и вариации на тему ACM (вместе с rndis), которые так любит windows. Устройства отличаются степенью поддержки операционной системы, степенью документированности и некоторыми другими особенностями.

Итак:

• Rndis — нестандартная вариация на тему ACM. Вообще-то подкласс ACM — это последовательный порт или модем, но microsoft, традиционно наплевав на все имеющиеся стандарты создала собственный. Rndis, по своей сути, представляет собой реализацию ndis API поверх usb. Используется microsoft-ом и в КПК под windows mobile для синхронизации и связи с компьютером. Так как этот класс не полностью документирован, да и не стандартен — это не наш путь.
• ECM — Ethernet Control Model — это реализация сетевой карты (в стандарте есть поддержка проверка состояния линка, мак-адрес карты хранится в дескрипторе и тд). Данный стандарт требует двух интерфейсов: для передачи данных и управляющего. За терминологией обращаться на usb.org или сюда: http://www.beyondlogic.org/usbnutshell/usb1.shtml. Вторая ссылка намного короче и более просто расписана :).
• EEM — это Ethernet Emulation Model — в этом случае USB используется исключительно как транспорт ethernet пакетов. Состояние линка не передаётся, скорость не настраивается и так далее. Зато интерфейс просто и для него нужно только 2 endpoint-а.

Отсюда мы и подходим к выбору варианта сетевого интерфейса. Тут всё оказалось совсем просто — для реализации ECM нам просто не хватило доступных endpoint-ов в контроллере. Так что выбор остановился на EEM. Даже с ним, доступные 6 endpoint-ов, разделились полностью, и пришлось слегка обмануть реализацию консоли, указав в дескрипторе несуществующий endpoint.

Так вот, в stm32f105 есть 6 доступных endpoint-ов, не считая нулевого (по 3 IN и OUT). В итоге хватает впритык и резерва не остаётся. Для ECM уже endpoint-ов не хватает, так как под эту модель требуется по 3 endpoint-а на интерфейс.

Передача данных в модели EEM, или как же это заставить работать….

Для того, чтобы сетевое устройство с классом EEM зарегистрировалось в системе, достаточно правильно написать USB дескриптор. Создаётся интерфейс состоящий из двух bulk endpoint-ов, одного IN и одного OUT, ему приписывается класс CDC (0×02), подкласс EEM (0x0c), и протокол EEM (0×07). На этом все тонкости и заканчиваются. Пакеты в EEM передаются как есть, в виде ethernet фреймов, с дописанным в начале двухбайтным заголовком.

Выглядит он так:

Пятнадцатый бит определяет — является ли этот кадр данными идущими в интерфейс или служебной командой EEM. Всего есть 6 команд, из которых обязательными являются только Echo и Echo response. (Хотя как выяснилось, линуксовый драйвер, даже без реализации разбора этих команд вполне нормально работает).

Четырнадцатый бит определяет, используется ли реальный подсчёт CRC, или на месте CRC передаётся последовательносьт 0xdeadbeef.

Оставшиеся биты кодируют длину фрейма следующего за этими двумя байтами заголовка.

После реализации разбора заголовков, приём и передача заработали без проблем, за исключением того, что USB-шная библиотека от ST не позволяет реализовать USB-transfer длинее чем размер FIFO в stm32, а ethernet пакеты в EEM нельзя разбивать между transfer-ами.
Таким образом, сейчас реализован приём и передача пакетов до 254 байт длиной. Пропускная способность не измерялась.

Скачать можно отсюда.

поясню. assistant можно запустить с ключом -enableRemoteControl и управлять им «без мышки» посредством команд, отправляемых на stdin.
для тестов я выполнил следующее:

$ mkfifo /tmp/qt4a
$ tail -f /tmp/qt4a | assistant-qt4 -enableRemoteControl &


далее активируем окно поиска по индексу:

$ echo "show index" > /tmp/qt4a


и выполняем

$ echo "activateKeyword QColor" > /tmp/qt4a


последняя строчка открывает описание класса QColor, и (что особенно приятно)
окно assistant’a становится topmost.

всё это натолкнуло меня на мысль, что, написав макрос для любимого редактора,
можно обрести счастье.
открываю .vimrc и добавляю туда:

function! Qt4AssistantDoc()
let s:wordUnderCursor = expand("<cword>")
let s:cmd = "!echo activateKeyword " . s:wordUnderCursor . " > /tmp/qt4a"
execute s:cmd
endfunction
" Online doc search.
map :call Qt4AssistantDoc()


теперь, нажатие Alt+d в vim’e на той функции или классе, где стоит курсор
практически мгновенно открывается документация ;)

будет время, надо будет сгенерировать man’ы по qt4 class’ам.
тогда можно будет не стартовать даже qt4 assistant. правда и навигация по ссылкам работать не будет ;(

• BERT, PJ, CTRAF: добавлена возможность проведения теста более 24 часов.(до 99:59:59)
• RFC2544, BERT, CTRAF, PJ: добавлена возможность настройки поля DSCP в заголовке IP.
• Добавлен значок молнии при питании от внешнего источника.

Скачать новую прошивку можно вот здесь.

В отличие от нашего предыдущего проекта, в 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

Ну, и первой задачей была разработка нового интерфейса — чтобы, значит, приспособленного под работу просто пальцами и всяко симпатичнее айфона. Антон предложил начать с оценки «чистого» Framebuffer’а, то есть:

• своя библиотека под FB;
• Direct FB;
• Cairo.

Схема:

Разбираясь с Direct FB вышли на GTK+ поверх DFB — получалось, что не было смысла городить свою библиотеку, когда есть все готовое.

Но, с подачи Юры, с учетом наличия Openembedded, решено было сделать хитрее. Мы собрали образ для B4 — c X-ами на базе Ангстрома, с GTK+/KDrive

Вот KDrive, как известно, работает поверх FB. Это было уже не чистое GTK+DFB, но так было интереснее

ДА!, кстати, в процессе был собран и запущен под QEMU дистрибутив POKY , созданный компанией O-Hand, которую купил интел, который вот, как раз, выпустил таки Moblin beta

Интерфейс платформы Moblin

Moblin Core

Ну а мы зато сделали прототип на GTK+.

Внешний вид прототипа OTDR на B4 на GTK+, GtkPlot

и нарвались на «странность» с отрисовкой GtkEntry — см.блог

смущало также, немного, что в то время как мы уходим c QT на GTK, такие парни как NOKIA и OPENMOKO наоборот, идут в сторону QT от GTK.

А NOKIA так вообще, купила троллтек и, похоже, собирается выпустить новый релиз Маемо на QT4.

Запустили QT Embedded Widgets на B4!

Таки мы решили проверить работу QT4 на B4!

Количество QT вариантов — отдельная тема, но и в этом разобрались.

Сейчас есть:

QT4X11.

QT4Embedded — в молодости QTopia core, QT4 поверх QWS

QT4Extended — ранее QTopia, пакет приложений под QTE.

OE рулит — мы собрали QT Embedded widgets  и запустили его на том самом образе.

В процессе разобравшись с «как же собрать qt4 приложение битбэйком» и глюком TSLib, с патчем от 2007 года.

Всем понравилось и мы сделали прототип на QT4.

Прототип OTDR на B4 под QT Embedded 4.4.3, QWT Plot

А вот видео:

Что в итоге

QT

• «out of the box» приятней GTK
• C++
• легко меняется стиль внешнего вида
• есть QT Creator способствующий разработке (нокиа крепко взялась за кьют)
• QT под X-ами, увы, угнетающе по скорости на B4

GTK

• проще внутри (Владимир со мной не согласен :)
• С
• быстрее процентов на 30 чем QT
• для стилистики нужно применять engines и темы (кстати вот Sato из Poky оказался просто енжином)

Выбираем QT

ps. А Юра знал с самого начала :)

Вот краткий список изменений и исправлений.

Беркут-ET (MCU v.0.2.38):

• в параметрах интерфейсов появилась настройка «Автосогласование». Теперь есть возможность установить линк с любым оборудованием
• исправлена ошибка — в режиме «Шлейф» оборудование Cisco определяло Bercut-ET как «Loopback device» и отключало порт.
• исправлена ошибка — в режиме «Шлейф» первого уровня корректно функционирует диодная индикация и статистика по передаче
• пакетный джиттер теперь можно использовать с генератором трафика на одном порту
• исправлена ошибка — теперь при использовании удалённого доступа все порты могут находиться в одной подсети
• повышена стабильность работы теста rfc2544. раньше были сообщения от пользователей, что тест зависал
• исправлена ошибка — в режиме «Шлейф» второго и третьего уровней на 1000 Mbps потери составляют 0%
• аппаратные тесты теперь запускаются только при удержании кнопки включения с одновременным нажатием кнопки аппаратного сброса
• исправлена критическая ошибка — в версии 0.2.37 прибор не включался без внешнего питания
• исправлена ошибка — корректно работает кнопка «Журнал» в тесте Back-to-back

Новые версии firmware для Беркут-ET лежат здесь.

Беркут-ETL (MCU v.0.2.2):

• исправлена ошибка — в режиме «Шлейф» второго и третьего уровней на 1000 Mbps потери составляют 0%
• исправлена ошибка — в режиме «Шлейф» оборудование Cisco определяло Bercut-ETL как «Loopback device» и отключало порт.
• при включении прибора проводятся аппаратные тесты
• при выключении прибора сохраняются настройки шлейфа
• добавлена поддержка VLAN

Обновления для Беркут-ETL можно скачать тут.