Наша команда системного программирования YADRO продолжает работать с open-source эмулятором QEMU.  В этой статье я расскажу, как и зачем мы создали виртуального двойника Intel NTB Gen3.

Документации по этому устройству нет в открытом доступе, поэтому итог работы — это результат наблюдения и экспериментов с реальной установкой, а также изучения существующих применений и драйверов Linux с другой. Прошу под кат, где я подробно описываю результаты и все шаги. Уверен, что информация пригодится вам для создания своих классных проектов.

QEMU позволяет эмулировать работу не только одной отдельной машины, но и связывать несколько независимых машин между собой. Для организации такой связи их обычно объединяют в одну сеть, например с использованием virio-net-pci. Но виртуальный ethernet — не единственный способ, связь может быть и более близкой и плотной: общая память и mailbox, линии gpio и даже NTB.

Быстрая работа связанных QEMU машин приятна при разработке/отладке и очень важна при массовом прогоне автотестов в CI: нужна как высокая пропускная способность, так и низкая задержка передачи сообщения. Для одной из задач с коллегами из отдела системного программирования YADRO я оптимизировал часть такой связки, а именно — обмен прерываниями. В статье расскажу о дизайне нескольких подходов организации IQI, разберу внутреннее устройство QEMU и поделюсь, как оправдались наши ожидания. 

Получив свой экземпляр (заказал еще до того как вышел LicheeRV Dock), я конечно же полез за официальной инструкцией к производителю...

В принципе, я никогда не интересовался продуктами вроде Banana Pi или Orange Pi от Allwinner, взглянув на официальное чудо, я понял почему от этих продуктов все так воротят нос:

— Прошивки для не китайцев "заботливо" лежат на MEGA (хочешь качать - плати деньги...)

— Для прошивки карт используется "замечательный" инструмент под названием PhoenixCard (судя по китайским форумам он не слушается даже китайцев), который работает под Windows (что всегда хорошо!)

— Официальный "SDK" обернут вместе c rootfs и разбит на архивы общей суммой >10 Gb (да-да и лежит на MEGA - то есть все равно заплатишь)

— И изюминка - все образы в комплекте расчитаны на карты ёмкостью больше 16 Gib (у наших друзей написано 16 GB - card_needs_≥16GB.txt)

Квест про реверс (он в конечном счете не понадобился) и печальное ковыряние палкой данного продукта жизнедеятельности (то что я собрал с помощью SDK, так и не заработало...) мы опустим, так как, я наконец наткнулся на гайд для Sipeed Nezha от дяди Samuel'a Holland'a спасибо ему за это огромное...

При bleeding edge разработке или просто в рамках экспериментов, приходиться добавлять патчи прямиком из maillists.

Скачивать серию вручную и сохранять в mbox можно действительно озвереть, даже не смотря на то, что можно спокойно выделить патчи (например в mutt) по одному и сохранить всю пачку (ключевое слово здесь спокойно).

Тем у кого горит, предлагаю воспользоваться git-pw.

IIO (промышленный ввод / вывод) — это подсистема ядра Linux для аналого-цифровых преобразователей (АЦП), цифро-аналоговых преобразователей (ЦАП) и различных типов датчиков. Может использоваться на высокоскоростных промышленных устройствах. Она, также, включает встроенный API для других драйверов.

Когда разработка только начинается часто еще непонятно какие именно пакеты пойдут в целевую rootfs.

Иными словами хвататься за LFS, buildroot или yocto (или еще что-то) еще рано, а начинать уже нужно. Для богатых (у меня на пилотных образцах 4GB eMMC) есть выход раздать разработчикам дистрибутив, который позволит оперативно доставить что-то чего не хватает в данный момент, а затем мы всегда можем собрать списки пакетов и сформировать список для целевой rootfs.

Забавное использование Ragel State Machine Compiler для создания функции разбора строки на int argc, char *argv[].

Все началось с того, что понадобилась функция buildargv, чтобы разбирать строку для последующей передачи в

int main (int argc, char *argv[]) { body }

Ну ладно подумал я, не может быть, чтобы нигде нельзя было позаимствовать, сейчас найдем… И не нашёл...

Данная заметка имеет собой цель продемонстрировать автоматический git bisect на примере ядра Linux. С последующим поиском официальной версии начиная с которой всё поломалось и последней хорошей версии.

Ну или почти вся...

Я считаю, что проблема в современном интернете — это переизбыток информации разного качества. Найти материал по интересующей теме не проблема, проблема отличить хороший материал от плохого, если у вас мало опыта в данной области. Я наблюдаю картину, когда очень много обзорной информации "по верхам" (практически на уровне простого перечисления), очень мало углубленных статей и совсем нет переходных статей от простого к сложному. Тем не менее именно знание особенностей того или иного механизма и позволяет нам сделать осознанный выбор при разработке.

В статье я постараюсь раскрыть то, что является фундаментальным отличием epoll от других механизмов, то что делает его уникальным, а так же привести статьи, которые просто необходимо прочитать для более глубокого осмысления возможностей и проблем epoll.

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Начиная с версии ядра 4.6-r1 нам стал доступен новый интерфейс для взаимодействия с подсистемой ядра gpio. Теперь существует три официальных способа работы с gpio и получения от них прерываний. Нет смысла углубляться в потребности для данной подсистемы, для малой части это суровые будни, для другой части веселое хобби, и для всех вместе в ядре была предоставлена новая возможность взаимодействия.

Заметка носит популярный характер, так как основных преимуществ, которые шли в комплекте с нововведением, а именно упрощение работы с gpio в контексте ядра касаться не будем.

Данная статья является логичным продолжением предыдущей и её прочтение рекомендуется после ознакомления с предшествующим материалом. Текущая заметка необходима для понимания последующего материала, дополнительного понимания подсистемы gpio в целом и способствует разработке собственных gpio драйверов. Положения данной статьи уже применимы не только к нашему виртуальному драйверу gpio, но и к любому mmio gpio драйверу в целом. Речь пойдет об упомянутой в предыдущей части "оптимизации".