embedded linux что это
Операционная система Embedded Linux
Вы здесь
Сообщение об ошибке
Мы с гордостью сообщаем, что устройство Magic Box функционирует под управлением операционной системы Linux, а точнее её Embedded редакции. Вы спросите, почему мы выбрали именно эту ОС, а не использовали привычную для всех ОС линейки Windows? С удовольствием отвечаем.
Ни для кого не секрет, что ОС Windows установлена на 70% ПК во всём мире. И это делает её максимально распространённой операционной системой на персональных, пользовательских компьютерах. Однако не все знают, что в серверном сегменте уже порядка 50 лет бал правят Unix – подобные системы. Стоит ли рассказывать, что Unix – подобные системы хорошо зарекомендовали себя как системы для построения интранет и интернет – серверов, что большинство ОС, применяемых в военной сфере основаны на Unix – подобных системах и даже крупнейшая сетевая энциклопедия Wikipedia работает под управлением Linux. Как вы видите, для решения задач, требующих повышенной надёжности и отказоустойчивости ОС, максимальной её гибкости и способности работать на любых аппаратных платформах все выбирают не ОС Windows. Мы тоже выбрали Embedded Linux.
Ведь Embedded Linux – это специализированная версия ОС GNU/Linux, адаптированная для использования в промышленных устройствах, беспилотных летательных аппаратах, DVR и других специализированных устройствах. Особенностью этой модификации ОС является малый размер образа самой системы, а так же невысокие требования к ресурсам аппаратной платформы и высокая степень оптимизации кода под конкретную аппаратную платформу. Windows (кроме редакции CE) до сих пор не может работает на процессорах архитектуры ARM, что уж говорить о специализированных процессорах, таких как TI DaVinchi. Windows CE имеет ограниченный функционал и требует специализированного ПО. Кроме всех этих недостатков, ОС стоит денег, которые производители устройств закладывают в стоимость готовых решений.
Embedded Linux же представляет собой полноценную ОС, современную и функциональную, способную работать на любой архитектуре и адаптированную под особенности этой архитектуры, безопасную и не подверженную разрушительному влиянию вирусов. А главное – полностью бесплатную и поддерживаемую миллионами свободных разработчиков во всём мире.
Embedded Linux в двух словах. Первое
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.
Топовые чаты, пульты и светодиоды будут позже, а сейчас на плату подается питание и плата отвечает CCCCCCCCCCC
В переводе с бутлоадерского это означает, что первичному загрузчику, зашитому в ROM процессора, нечего загружать. Ситуацию проясняет Reference Manual, где на странице 5025 в разделе 26.1.5 описана процедура начальной загрузки. Процедура такая: первичный загрузчик проводит некоторую инициализацию: тактирование процессора, необходимой периферии, того же UART, и, в зависимости от логических уровней на выводах SYSBOOT, строит приоритетный список источников где можно взять следующий загрузчик, т.е. посмотреть сначала на MMC карте, SPI-EEPROM или сразу ждать данных по Ethernet.
Я использую способ загрузки с помощью SD карты, вот что говорит об этом раздел RM 26.1.8.5.5 на странице 5057: первичный загрузчик сначала проверяет несколько адресов 0x0/ 0x20000/ 0x40000/ 0x60000 на наличие так называемой TOC структуры, по которой он может определить загрузочный код, если так код не найти, то первичный загрузчик, предполагая на SD карте наличие файловой системы FAT, будет искать там файл с названием MLO, как это расшифровывается в RM не сказано, но многие склоняются что Master LOader. Возникает резонный вопрос, где же взять этот MLO?
Das U-Boot
Перед скачиванием U-Boot, стоит сходить в репозиторий и найти тег последней версии, далее
U-Boot содержит больше тысячи конфигураций, в том числе нужную:
Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.
Установка нужного конфига:
Можно, к примеру, убрать, установленную по умолчанию, 2-х секундную задержку при загрузке платы с U-Boot
В вышеуказанных командах, используется компилятор по умолчанию, если таковой в системе установлен, и, скорее всего, он не подходит для ARM процессоров, и здесь пора упомянуть о кросскомпиляции.
ARM Toolchain
Один из видов кросскомпиляции это сборка на одной архитектуре, как правило x86-64, именуемой HOST, исходного кода для другой, именуемой TARGET. Например, для TARGET архитектуры ARMv7-A, ядра ARM CortexA-8 процессора AM3358, платы BeagleBone Black. К слову, чтобы не запутаться в ARM’ах, даже есть свой справочник, так их много и разных.
Теперь для успешной сборки U-Boot, нужно указать в переменных ARCH и CROSS_COMPILE требуемые архитектуру и путь к кросскомпилятору соответственно, например так
После сборки U-Boot, в папке появятся необходимые файлы, а именно
Для успешной загрузки с SD карты, нужно ее некоторым образом разметить. Карта должна содержать минимум два раздела, первый, отмеченный как BOOT, с файловой системой FAT, второй раздел с ext4. Разметить карту можно, к примеру, программой fdisk.
Теперь нужно просто скопировать результаты сборки U-Boot в FAT раздел, вставить карту в BeagleBone Black и в терминале наблюдать уже более осознанный ответ платы
В ответе платы есть такие строки
Failed to load ‘boot.scr’
Failed to load ‘uEnv.txt’
U-Boot, во время загрузки, смотрит наличие дополнительных команд, сначала в файле boot.scr, при его наличии, затем, если boot.scr не нашлось, в uEnv.txt. Эти файлы, помимо очередности при поиске, отличаются тем, что в файле uEnv.txt, дополнительные команды представлены в текстовом виде, т.е. он проще для восприятия и редактирования. U-Boot не создает файлы с дополнительными командами, делать это нужно самостоятельно.
Ядро Linux
Прежде чем приступать к любым действиям с ядром, стоит заглянуть сюда и убедится в наличии необходимых пакетов. Следующим шагом нужно определиться с тем, какую версию ядра использовать. Здесь я использую версию 5.4.92 и вот по каким соображениям. Одной из основных причин того, что не стоит брать просто последнюю версию ядра, доступную на данный момент, наряду с наличием драйверов, является невозможность быстро протестировать это ядро на всем разнообразии платформ поддерживаемых Linux, а значит можно потратить кучу сил и времени на исправление неполадок, если что-то пойдет не так, и не факт что это вообще получится сделать. BeagleBone Black имеет официальный репозиторий, где можно найти версию ядра, протестированную на данной платформе, и long term версия 5.4.92 была последней на тот момент.
Сам конфиг пока остается без изменений, поэтому можно просто его установить и запустить компиляцию ядра(zImage), модулей(modules) и дерева устройств(dtbs)
Проходит некоторое время.
Результат сборки, в виде zImage, находится в /arch/arm/boot, там же в папке /dts находится скомпилированное дерево устройств am335x-boneblack.dtb, оба отправляются на SD карту к файлам загрузчика. На этом FAT раздел SD карты можно считать скомплектованным. Итого, там присутствуют:
Еще при сборке ядра заказывались модули ядра, но они уже относятся к корневой файловой системе.
Корневая файловая система. BusyBox
Ядро получает корневую файловую систему путем монтирования блочного устройства, заданного в, переданном при запуске ядра, аргументе root=, и далее, первым делом, исполняет оттуда программу под названием init.
Если запустить BeagleBone Black, имея только вышеуказанные файлы для FAT раздела, то ядро будет паниковать по причине отсутствия init и, в целом, по причине пустой rootfs, т.е. корневой файловой системы.
Можно шаг за шагом создать все минимально необходимые компоненты корневой файловой системы, такие как оболочка, различные демоны запускаемые init, сам init, конфигурационные файлы, узлы устройств, псевдофайловые системы /proc и /sys и просто системные приложения. Для желающих совершать подобные подвиги, существует проект Linux From Scratch, здесь же я воспользуюсь швейцарским ножом встроенных систем с Linux, утилитой BusyBox.
Скачивание последней, на тот момент, версии:
Настройка конфигурации по умолчанию:
Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:
Установка в папку по умолчанию _install:
Теперь в папке _install можно видеть будущую корневую файловую систему, в которую нужно добавить некоторые вещи.
Папки, помимо созданных BusyBox:
Стартовый скрипт. Дело в том, что, запускаемая в первую очередь, программа init, делает много полезного, например, выводит в консоль приглашение, но до выдачи приглашения, init проверяет наличие стартового скрипта /etc/init.d/rcS, и, при наличии, запускает его.
Этот скрипт монтирует псевдофайловые системы proc и sysfs, и ничего не мешает ему запускать, к примеру, пользовательскую программу, отвечающую за функционал устройства, но лучше будет делать это в отдельных скриптах, скомпонованных по функциональному назначению.
Стоит сказать, что работа init, на самом деле, начинается с чтения конфигурационного файла /etc/inittab, но BusyBox’овская init включает таблицу inittab по умолчанию, если таковой не окажется в корневой файловой системе.
Теперь пора вспомнить про модули ядра. Их также нужно разместить в корневой файловой системе в /lib/modules/5.4.92/, но сейчас они разбросаны по всей папке в которой собиралось ядро. Чтобы собрать модули в кучу, нужно в папке с ядром выполнить
Где в INSTALL_MOD_PATH указать путь к папке с корневой файловой системой, кросскомпилятор указывать не нужно, т.к. здесь модули ядра просто копируются по месту назначения. В результате папка /lib корневой файловой системы пополнится разделом /lib/mudules/5.4.92/ содержащим модули ядра, полученные при компиляции ядра.
Осталось скопировать все содержимое папки _install во второй раздел SD карты, тот который с ext4, и поменять владельца всего содержимого на root.
После запуска BeagleBone Black с корневой файловой системой, через 1.910315 секунды после старта ядра, система предложит активировать консоль и начать работу.
Но начать работу в такой системе, скорее всего не получится, т.к. в ней нет ничего кроме системных утилит BusyBox и моей небольшой программы, нарисовавшей приветствие, зато, эта система поможет получить общее представление о том, какая магия происходит внутри подобных устройств. Именно общее, т.к. в реальных устройствах, из-за необходимости минимизации времени загрузки, ограниченности ресурсов, заточенности под конкретную задачу, различий между ARM процессорами, построение системы может сильно отличаться. Например, на малинке, вообще сначала стартует графический процессор, который затем запускает все остальное.
По поводу же заявленных в начале драйверов, взаимодействия с внешними устройствами, автоматизации сборки и некоторого полезного функционала, пойдет рассказ в следующей статье.
Embedded Linux в двух словах. Второе
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
В предыдущей части рассматривалось создание базовой системы, не выполняющей каких-либо полезных действий, но демонстрирующей, на своем примере, один из способов сборки подобных систем.
В этой части речь пойдет о таком инструменте автоматизации как Buildroot, о создании драйверов согласно современным веяниям драйверостроения, и реализации функционала, анонсированного в первой части, в виде отправки смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта.
По результатам прошлой части имеется плата с базовой системой и намерение добавить туда некоторый функционал, причем, чтобы при редактировании какой-либо составляющей, будь то пользовательская программа, драйвер ядра или просто настройки конфигурации, не пришлось делать множество телодвижений для сборки новой системы, в идеале же, ограничиться одной командой. Такую задачу может решить система сборки, наиболее известными являются Yocto Project, OpenWrt, Buildroot, все со своими преимуществами и недостатками, и, из перечисленных, здесь будет использоваться последняя.
Buildroot
Как говорят на официальном сайте, Buildroot это простой, эффективный, легкий в использовании инструмент для создания встраиваемых систем посредством кросскомпиляции, Buildroot для Всех говорят они, и, да, во многом всё так и есть.
Проверив зависимости (раздел 2), можно скачивать
И, например, чтобы создать минимальную систему для BeagleBone Black, а там есть готовый, и не один, конфиг для этой платы, нужно этот конфиг установить и запустить сборку
В результате, Buildroot сам скачает нужные исходники, соберет набор инструментов для кросскомпиляции, загрузчик, ядро Linux, системные утилиты, библиотеки, вобщем все то, что упоминалось в предыдущей статье и еще сверху. Установленные beaglebone_defconfig‘ом настройки можно посмотреть командой:
Для вывода списка всех предустановленных конфигураций:
Для вывода справки по всем командам:
Здесь я не буду использовать предустановленные, а создам с нуля свою конфигурацию, куда, по ходу дела, будут добавлены все необходимые настройки платы.
Для начала нужно создать папку, где будут сконцентрированы все дополнительные материалы, используемые в сборке конкретной платы, Buildroot рекомендует использовать для этого папку /board. Пусть рабочим названием платы будет «smilebrd» и теперь все что касается проекта будет находится в /board/smilebrd/
Время установить базовые настройки Buildroot для платы, все, о чем известно на данный момент.
Далее показаны только измененные настройки, остальное остается по умолчанию, плюс Buildroot сам отметит зависимости добавленных компонентов.
Архитектура целевой платформы, тут достаточно очевидно, ARM, Cortex-A8
Сборка, нужно указать название конфига, который будет добавлен к уже имеющимся, после выполнения savedefconfig
В конфигурацию системы можно добавить название системы вместе с выдаваемым приветствием, и изменить подсистему инициализации на systemd, а командную оболочку на bash. Также в этом разделе можно задать скрипт, который будет запущен перед компоновкой файловой системы. Здесь он используется для копирования в директорию сборки файла uEnv.txt, о нем речь шла в предыдущей статье, а также копирования настроек для автоматического запуска пользовательского приложения, о самом приложении речь пойдет позже
Далее идут настройки ядра Linux. Как и с набором инструментов, будет использоваться готовое ядро, т.е. Buildroot не будет ничего качать самостоятельно, а распакует и соберет всё из исходников в указанном тарболе. Немного кастомизированна конфигурация ядра, т.к. в нее нужно добавить пункты по сборке свежеразработанных драйверов для свежеразработанного смайл пульта, еще отмечено, что нужно собрать дерево устройств и из чего собственно собирать, а также поддержка OpenSSL
Пакеты, устанавливаемые в систему. Здесь понадобится firmware для wifi адаптера TP-LINK TL-WN725N, он мал, доступен в продаже, недорог, с обязанностями справляется, внутри содержит чип Realtek 8188EU о чем и нужно указать в конфиге, а заодно добавить connman для управления подключением к wifi. Также, для взаимодействия с чатом посредством websocket я использовал утилиту wscat, она работает на nodejs, значит нужна поддержка nodejs и пакетного менеджера с нужным модулем
Файловой системой будет ext4, с максимальным размером в 500 мегабайт, размер указывается просто в качестве планки, т.к. во встроенных системах, обычно, заранее известны все характеристики оборудования, и имеет смысл заранее узнать о превышении размера памяти, отведенного под корневую файловую систему
Загрузчик U-Boot, подробнее про него, где брать и как настраивать, есть в предыдущей статье. Здесь же нужно указать, что используется именно U-Boot, где он находится, путь к настройкам U-Boot. Подойдет дефолтный конфиг для AM3358, но я, в образовательных целях, внес минимальные изменения, убрав 2-х секундную задержку при загрузке, это все отличия uboot_smilebrd_defconfig от am335x_evm_defconfig. Также нужно указать формат и наименование вторичного загрузчика
Теперь осталось сохранить полученную конфигурацию
Linux Device Drivers
Чтобы определиться, что должен делать драйвер, нужно несколько слов сказать о том, с чем ему придется работать, о смайл пульте.
Изделие представляет собой плату с микроконтроллером STM32L475. Камень избыточен для своих задач, но выбор пал на него только из-за наличия множества пылящихся отладок NUCLEO, имеющих похожий на борту. Смайлы являются полигонами TSC-контроллера, т.е. сенсорными кнопками, в прорезях платы светодиоды, куда ж без них, коммуникация с BeagleBone Black происходит посредством I2C, где STM выступает в роли ведомого. Еще есть UART на случай, вдруг пригодится, и, собственно, всё. Отсутствие башенки кварцевого резонатора говорит о тактировании от внутреннего RC генератора, а отсутствие стабилизатора, о питании от платы BeagleBone Black. Под капотом микроконтроллера безHAL’ьное ядро на Scm-RTOS, для интересующихся, исходники можно посмотреть здесь.
Возвращаясь к драйверу, общий функционал у него такой: при касании сенсорной кнопки, пульт генерирует импульс на сигнальном выводе, давая понять, что ему есть что передать, это провоцирует прерывание на входном GPIO в BeagleBone Black, по сигналу прерывания запускается опрос пульта по I2C, данные о сработавшей кнопке подаются в приложение, которое сопоставляет кнопку с нужным смайлом и отправляет команду в чат. В обратную сторону предусмотрен только сигнал о подключении к серверу чата, для этого сигнала отведен отдельный светодиод на пульте. Итого в драйвере должен быть задействован интерфейс I2C, один GPIO, настроенный как вход, с подключенным прерыванием и один GPIO, настроенный как выход, для управления светодиодом.
Весь драйвер выглядит так
Упрощенно, модель устройств Linux можно представить в таком виде
Bootlin Linux Kernel and Driver Development Training
«Сверху» драйвер взаимодействует с фремворком, фреймворк формирует в папке /dev специальный файл называемый узел устройства, который, в свою очередь, используется из пространства пользователя посредством open/read/write/close, может еще ioctl. Есть несколько специфичных характеристик, говорящих о сущности устройства представленного этим узлом, это тип, и два числа называемые major и minor.
Теперь, зная общую картину, можно заняться разбором драйвера смайл пульта, причем начать разбор стоит с конца
Драйвера, по сути, являются модулями ядра, и последние три строки это макросы для установки общей информации, её можно будет увидеть, если загрузить модуль и набрать modinfo.
module_init(smilebrd_init) и module_exit(smilebrd_exit) это также макросы, вообще в документации на ядро макросы настоятельно рекомендуют к использованию, т.к. обратная совместимость не является сильной стороной кода ядра, и от версии к версии, в неизменном виде, макросы живут дольше. Эти макросы задают функции, которые будут вызваны при загрузке и выгрузке модуля. Когда же происходит загрузка модуля? Сейчас просто скажу, что конкретно этот модуль будет загружаться при старте системы во время описи подключенных устройств, т.к. он указан в Device Tree или дереве устройств, более подробный ответ будет, когда придет время это дерево редактировать.
Вот что происходит во время загрузки модуля
Выделяется память под структуру, где хранится некоторая полезная информация, на усмотрение разработчика, и далее инициализируется «верхняя» часть, согласно приведенной модели устройств. Если устройство не принадлежит явно к какому-либо типу, под который выделен отдельный major номер, если драйвер достаточно прост и нетребователен, то можно немного облегчить себе жизнь и воспользоваться фреймворком Miscenallaneous device, при регистрации такого типа устройства, ядро автоматически присвоит ему major номер 10, с помощью MISC_DYNAMIC_MINOR определит свободный minor и создаст узел устройств для него, останется только в miscdevice.fops определить реализацию действий с файлом.
miscdevice.fops, т.е. file operations, представляет собой структуру со ссылками на обработчики операций open, read, write, poll, mmap и.т.д. Нужны будут только read и ioctl, также нужно добавить поле .owner, как правило, это всегда THIS_MODULE
При чтении файла узла устройства, процесс будет уходить в сон и находиться там до возникновения прерывания, сигнализирующего о касании сенсорной кнопки пульта. Данные о кнопке считываются по интерфейсу I2C во время обработки прерывания, во время чтения они просто передаются в пространство пользователя, чтобы процесс мог их обработать.
ioctl используется для управления светодиодом, сигнализирующем о подключении к серверу чата, больше декоративная функция
Теперь о взаимодействии «снизу», согласно модели устройств Linux
ВСЕ НА ДНО
«Снизу» драйвер взаимодействует с шинами Platform Device и I2C, последняя, очевидно, руководит I2C, а первая выводом для приема сигнала о касании сенсоров и выводом для управления светодиодом. Вообще, в ядре есть отдельные инcтрументы для работы с выводами, к которым подключены светодиоды или выводами общего назначения, можно воспользоваться ими. Также, начиная с версии ядра 4.8, поменялось взаимодействие с GPIO, если раньше обращение к выводам происходило через их номер, то сейчас для этого нужен дескриптор. Регистрация происходит всё в том же init’е
Подробнее, на примере I2C
Следующая структура используется при регистрации устройства в ядре, она содержит id, который будет отличаться в устройствах схожего типа, но имеющих некоторые отличия, например, если сделать плату пульта с другим набором смайлов, эта таблица выглядела бы так
Ещё одна структура, которая содержит две предыдущие, а также функции .probe/.remove вызываемые при подключении устройства
Механизм примерно такой, в Device Tree есть запись о некоем смайл пульте такого вида «heavyc1oud,smilebrd_i2c», при старте, система видит эту запись и пытается найти драйвер с такой же записью, находит его и вызывает соответствующий .probe; соответствующий .remove будет вызван, если выгрузить модуль ядра
Аналогично создается раздел драйвера по управлению выводами, в .probe, с помощью gpiod_get запрашивается дескриптор, по дескриптору настраивается режим работы, выход для светодиода, вход для сигнализации касания, также у вывода сигнализации настраивается защита от дребезга, хоть это и не механическая кнопка, но из-за длины провода могут проскакивать несанкционированные импульсы, и к нему же подключается прерывание по спадающему фронту
В обработчике прерывания, по интерфейсу I2C, у пульта запрашиваются данные о кнопках, затем в узел устройства отправляется сигнал о наличии новой информации от пульта, прерывание обработано
Следующим шагом нужно добавить драйвер к исходникам ядра, чтобы он отображался при вызове menuconfig и корректно собирался.
Для начала нужно выбрать раздел для драйвера, т.к. устройство не принадлежит явно к какому-либо типу, то драйвер, имеет смысл, расположить в папке /drivers/staging/
Помимо файла с кодом, в папке необходимо создать еще два файла. Первый, Kconfig, нужен для добавления нового пункта в меню конфигурации ядра, там указывается тип лицензии, в каком виде предполагается включение в ядро, т.е. предполагается / не предполагается / предполагается в виде модуля и справочная информация
Второй файл, Makefile, нужен для сборки драйвера
Затем нужно добавить в вышестоящие Kconfig и Makefile информацию о новом модуле
В файл drivers/staging/Kconfig
В файл drivers/staging/Makefile
Device Tree
Упоминания о дереве устройств неоднократно встречались, еще начиная с настройки загрузчика, теперь пришло время поговорить об этом подробнее и немного подредактировать для своих нужд.
Давным давно, необходимые для ядра, сведения об оборудовании хранились в папках /arch/arm/plat-xxx и /arch/arm/mach-xxx, а информация ядру передавалась через, так называемые А-тэги, ATAGS, при этом, каждый, уважающий себя, производитель создавал свою версию платформы, которую нужно было поддерживать, пока, однажды, небезызвестный Линус Торвальдс не выразил некоторую озабоченность трудоемкостью поддержки этого зоопарка
Тогда было решено взять модель Device Tree, используемую на платформах архитектур SPARK и PowerPC.
Дерево устройств представляет собой иерархию узлов, описывающих физически присутствующее в системе оборудование, от процессора, до отдельных устройств, подключенных к шинам, которые не поддерживают автоматическое определение оборудования
Device Tree for Dummies
В дерево устройств нужно внести те изменения, которые касаются непосредственно железа.
Изменения начинаются с добавления новых данных в узел &am33xx_pinmux, здесь, амперсанд указывает, что используется ссылка на существующий узел am33xx_pinmux, существует он во включенном файле am335x-bone-common.dtsi, этот узел содержит данные о мультиплексировании выводов процессора, обычно, для всего многообразия периферии, выводов процессора не хватает, поэтому на каждый вывод назначается по несколько функций, это и есть мультиплексирование, т.е. в этом узле решается какую из функций задействовать.
В узел настроек мультиплексирования добавляются данные о том, что выводы R13 и V14 микросхемы будут использованы как выводы общего назначения и настроены, R13 как вход с подтяжкой к питанию, V14 как выход, по умолчанию используется выход push-pull
По такому же принципу, добавляются данные к узлу &i2c2, процессор имеет на борту несколько интерфесов I2C, здесь используется второй по порядку. Сам узел является контроллером I2C, а добавляемые данные идентифицируют устройство, подключенное к этому контроллеру, так, по значению свойства compatible устройству сопоставляется драйвер, а значение свойства reg это номер устройства на шине I2C, т.е. значение которое фигурирует в первом байте при общении по протоколу I2C
Узел smilebrd_gpio является самостоятельным, поэтому у него нет ссылки в виде амперсанда, здесь также есть свойство compatible для подключения нужного драйвера, дальше идут свойства устанавлювающие связь с узлом мультиплексирования, свойства, определяющие номера используемых выводов и активный уровень, т.е. низкий уровень напряжения означает приход сигнала, а ACTIVE_HIGH для вывода светодиода означает, что к нему подключен анод светодиода и чтобы этот светодиод зажечь, нужно подать высокий уровень напряжения. Свойство interrupts определяет вывод, к которому подключено прерывание и спад сигнала в качестве его тригера. Свойство status со значением okay говорит, что оборудование в наличии и используется.
После внесения всех изменений в исходники ядра, нужно вернуть его в состояние тарбола и убедиться, что в Buildroot используется путь к обновленному ядру.
Осталось добавить какой-то полезный функционал, создать программу, получающую информацию от пульта и отправляющую нужный смайл в чат.
Топовый чат
Основной упор портала, куда будут отправляться смайлы, сделан на взаимодействие через браузер, но также существует API с помощью которого можно взаимодействовать напрямую. Взаимодействие происходит посредством websocket-соединения и JSON-кодирования. Я не буду подробно останавливаться на самой программе, принцип работы у нее такой, вначале создается отдельный процесс для запуска программы wscat работающей с вебсокетами, этот процесс соединяется с сервером чата и ждет команд, которые должны поступать через предварительно созданные каналы, pipes. Затем, запрашиватся список текущих стримеров, список сортирован по количеству зрителей, т.е. первый в списке с самым большим их количеством, к этому каналу и происходит подключение. После успешного подключения зажигается светодиод на смайл пульте, это делается посредством ioctl, предварительно открытого, узла dev/smilebrd. С помощью read процесс входит в режим ожидания сигнала о касании сенсора от смайл пульта, сигналом служит наличие данных о том, какого сенсора коснулись, определяется текст нужного смайла, и этот смайл отправляется в чат. Интересующиеся могут найти код здесь.
Для достижения поставленной цели, т.е. чтобы сборка создавалась одной командой, нужно в Buildroot добавить пакет с вышеописанной программой, причем исходники нужно брать там же, где и всем интересующимся.
Процесс добавления пакета в Buildroot, немного напоминает добавление своего драйвера в исходники ядра, нужно создать папку для своей программы в разделе package/
Далее в этой папке создать два файла, Config.in и smilebrd_serv.mk, первый отвечает за добавление нового пункта меню в Buildroot, второй говорит как собирать программу
Чтобы файл конфига заработал, нужно добавить ссылку на него в конфиг верхнего уровня, а именно в package/Config.in, добавить нужно в соответствующий раздел, где планируется отображать свою программу, я добавил в раздел menu «Miscellaneous»
Теперь в меню Buildroot должен появиться новый пакет
Всё, настройка завершена, можно сохранить конфиг командой
И выполнять сборку всего вышеперечисленного по команде
Результаты сборки помещаются в папку /output/images/, здесь будут файлы, необходимые для загрузки:
И корневая файловая система:
Осталось разместить всё на SD карте, подробнее об этом есть в первой статье, и подключить интернет, это можно сделать при помощи connman
Если, командой top, заглянуть в список работающих процессов, можно увидеть программу smilebrd_serv, она запускается автоматически, после появления соединения с интернетом, напомню, что это было сделано в скрипте post-build.sh, также командой lsmod можно посмотреть список загруженных модулей в нем должен присутствовать smilebrd_dev. При перезагрузке, BeagleBone Black будет автоматически подключаться к указанной точке доступа, т.е. нужно лишь подождать когда загорится светодиод на пульте и можно слать смайлы, главное не злоупотребить
Итого, просто, легко в использовании, эффективно, одной командой, как и было обещано. Тем, кто не встречался раньше со встроенными системами на Linux, и, все-таки смог прорваться до этого обзаца, может показаться, что Buildroot’овский лозунг звучит неправдоподобно или даже цинично, но, нет, системы сборки действительно максимально упрощают процесс и довольно просты в использовании, прошедшие Linux From Scratch не дадут соврать.
В статье сложно описать нюансы построения встроенной системы на Linux, к тому же, все что касается ядра, стремительно устаревает, отчасти поэтому Грег Кроа-Хартман не очень любит вопросы про Linux Device Drivers четвертой редакции. Если же говорить про русскоязычные материалы, то их, впринципе, исчезающе мало.
Вот мой вариант списка материалов, которые помогли с ответами на многие вопросы, ну и, конечно, не стоит забывать про форумы, с вопросом, корректно сформулированным, вам скорее всего помогут.
И, конечно же, актуальный Datasheet по ядру Linux