Как написать свой первый Linux device driver
Здравствуйте, дорогие хабрачитатели.
Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.
Для меня же, главной целью является подвести итог и сформировать базовые знания для написания будущих модулей ядра, а также получить опыт изложения технической литературы для публики, т.к. через полгода я буду выступать со своим дипломным проектом (да я студент).
Это моя первая статья, пожалуйста не судите строго!
Получилось слишком много букв, поэтому я принял решение разделить статью на три части:
Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.
Перед вступлением, хочу сказать, что здесь будут изложены базовые вещи, более подробная информация будет изложена во второй и последней части данной статьи.
Подготовительные работы
Спасибо Kolyuchkin за уточнения.
Символьный драйвер (Char driver) — это, драйвер, который работает с символьными устройствами.
Символьные устройства — это устройства, к которым можно обращаться как к потоку байтов.
Пример символьного устройства — /dev/ttyS0, /dev/tty1.
К вопросу про проверсию ядра:
Драйвер представляет каждое символьное устройство структурой scull_dev, а также предостовляет интерфейс cdev к ядру.
Устройство будет представлять связный список указателей, каждый из которых указывает на структуру scull_qset.
Для наглядности посмотрите на картинку.
Для регистрации устройства, нужно задать специальные номера, а именно:
MAJOR — старший номер (является уникальным в системе).
MINOR — младший номер (не является уникальным в системе).
В ядре есть механизм, который позволяет регистрировать специализированные номера вручную, но такой подход нежелателен и лучше вежливо попросить ядро динамически выделить их для нас. Пример кода будет ниже.
После того как мы определили номера для нашего устройства, мы должны установить связь между этими номерами и операциями драйвера. Это можно сделать используя структуру file_operations.
В ядре есть специальные макросы module_init/module_exit, которые указывают путь к функциям инициализации/удаления модуля. Без этих определений функции инициализации/удаления никогда не будут вызваны.
Здесь будем хранить базовую информацию об устройстве.
Последним этапом подготовительной работы будет подключение заголовочных файлов.
Краткое описание приведено ниже, но если вы хотите копнуть поглубже, то добро пожаловать на прекрасный сайт: lxr
Инициализация
Теперь давайте посмотрим на функцию инициализации устройства.
Первым делом, вызывая alloc_chrdev_region мы регистрируем диапазон символьных номеров устройств и указываем имя устройства. После вызовом MAJOR(dev) мы получаем старший номер.
Далее проверяется вернувшееся значение, если оно является кодом ошибки, то выходим из функции. Стоит отметить, что при разработке реального драйвера устройства следует всегда проверять возвращаемые значения, а также указатели на любые элементы (NULL?).
Если вернувшееся значение не является кодом ошибки, продолжаем выполнять инициализацию.
Выделяем память, делая вызов функции kmalloc и обязательно проверяем указатель на NULL.
Стоит упомянуть, что вместо вызова двух функций kmalloc и memset, можно использовать один вызов kzalloc, который выделят область памяти и инициализирует ее нулями.
Продолжаем инициализацию. Главная здесь функция — это scull_setup_cdev, о ней мы поговорим чуть ниже. MKDEV служит для хранения старший и младших номеров устройств.
Возвращаем значение или обрабатываем ошибку и удаляем устройство.
Выше были представлены структуры scull_dev и cdev, которые реализуют интерфейс между нашим устройством и ядром. Функция scull_setup_cdev выполняет инициализацию и добавление структуры в систему.
Удаление
Функция scull_cleanup_module вызывается при удалении модуля устройства из ядра.
Обратный процесс инициализации, удаляем структуры устройств, освобождаем память и удаляем выделенные ядром младшие и старшие номера.
С удовольствием выслушаю конструктивную критику и буду ждать feedback’a.
Если вы нашли ошибки или я не правильно изложил материал, пожалуйста, укажите мне на это.
Для более быстрой реакции пишите в ЛС.
Источник
Разработка драйвера PCI устройства под Linux
В данной статье я рассматриваю процесс написания простого драйвера PCI устройства под OC Linux. Будет кратко изучено устройство программной модели PCI, написание собственно драйвера, тестовой пользовательской программы и запуск всей этой системы.
В качестве подопытного выступит интерфейс датчиков перемещения ЛИР940/941. Это устройство, отечественного производства, обеспечивает подключение до 4 энкодеров с помощью последовательного протокола SSI поверх физического интерфейса RS-422.
На сегодняшний день шина PCI (и её более новый вариант — PCI Express) является стандартным интерфейсом для подключения широкого спектра дополнительного оборудования к современным компьютерам и в особом представлении эта шина не нуждается.
Не редко именно в виде PCI адаптера реализуются различные специализированные интерфейсы ввода-вывода для подключения не менее специализированного внешнего оборудования.
Так же до сих пор не редки ситуации когда производитель оборудования предоставляет драйвер лишь под OC Windows.
Плата ЛИР941 была приобретена организацией, в которой я работаю, для получения данных с высокоточных абсолютных датчиков перемещения. Когда встал вопрос о работе под Linux оказалось, что производитель не предоставляет ничего под эту ОС. В сети так же ничего не нашлось, что впрочем нормально для такого редкого и специализированного устройства.
На самой плате находится FPGA фирмы Altera, в которой реализуется вся логика взаимодействия, а также несколько (от 2 до 4) интерфейсов RS-422 с гальванической развязкой.
Обычно в такой ситуации разработчики идут по пути обратного инженеринга, пытаясь разобраться как работает Windows драйвер.
Морально готовясь к этому развлечению я решил для начала попробовать самый простой и прямой способ — написал запрос непосредственно производителю оборудования.
Я спросил не могут ли они предоставить какую-нибудь документацию или спецификацию на их устройство, дабы я мог разработать открытый драйвер под Linux. К моему удивлению производитель пошел на встречу, мне ответили очень быстро и прислали всю необходимую документацию!
Шина PCI
Небольшая заметка по поводу PCI и PCI Express.
Несмотря на то, что аппаратно это два разных интерфейса — оба они используют одну программную модель, так что с точки зрения разработчика особой разницы нет и драйвер будет работать одинаково.
Шина PCI позволяет подключать одновременно большое количество устройств и нередко состоит из нескольких физических шин, соединяющихся между собой посредством специальных «мостов» — PCI Bridge. Каждая шина имеет свой номер, устройствам на шине так же присваивается свой уникальный номер. Так же каждое устройство может быть многофункциональным, как бы разделенным на отдельные устройства, реализующие какие-то отдельные функции, каждой такой функции аналогично присваивается свой номер.
Таким образом системный «путь» к конкретному функционалу устройства выглядит так:
.
Что бы посмотреть какие устройства подключены к шине PCI в Linux достаточно выполнить команду lspci.
Вывод может оказаться неожиданно длинным, т. к. кроме устройств непосредственно физически подключенных через pci/pci express слоты (например видеоадаптера) есть множество системных устройств, распаянных (или же входящих в устройство микросхем чипсета) на материнской плате.
Первая колонка этого вывода, состоящая из чисел, как раз и представляет собой набор рассмотренных выше идентификаторов.
Этот вывод означает, что видеоадаптер NVIDIA GT 240 находится на PCI шине 01, номер устройства — 00 и номер его единственной функции так же 0.
Следует еще добавить, что каждое PCI устройство имеет набор из двух уникальных идентификаторов — Vendor ID и Product ID, это позволяет драйверам однозначно идентифицировать устройства и правильно работать с ними.
Выдачей уникальных Vendor ID для производителей аппаратного обеспечения занимается специальный консорциум – PCI-SIG.
Что бы увидеть эти идентификаторы достаточно запустить lspci с ключами -nn:
Где 10de — идентификатор производителя, NVIDIA Corporation, а 0ca3 — идентификатор конкретного оборудования.
Узнать кто есть кто можно с помощью специальных сайтов, например The PCI ID Repository
Чтение служебной информации и конфигурация PCI устройства осуществляется посредством набора конфигурационных регистров. Каждое устройство обязано предоставлять стандартный набор таких регистров, которые будут рассмотрены далее.
Регистры отображаются в оперативную память компьютера во время загрузки и ядро операционной системы связывает с устройством особую структуру данных — pci_dev, а так же предоставляет набор функций для чтения и записи.
Помимо конфигурационных регистров PCI устройства могут иметь до 6 каналов ввода-вывода данных. Каждый канал так же отображается в оперативную память по некоему адресу, назначаемому ядром ОС.
Операции чтения-записи этой области памяти, с определенными параметрами размера блока и смещения, приводят непосредственно к записи-чтению в устройство.
Получается, что для написания драйвера PCI необходимо знать какие конфигурационные регистры использует устройство, а так же по каким смещениям (и что именно) нужно записывать/читать. В моем случае производитель предоставил всю необходимую информацию.
Конфигурационное пространство PCI
Первые 64 байта являются стандартизированными и должны предоставляться всеми устройствами, независимо от того требуются они или нет.
На картинке отмечены регистры являющиеся обязательными, они всегда должны содержать какие-либо осмысленные значения, остальные же могут содержать нули, если это не требуется в данном случае.
Порядок байт во всех регистрах PCI — little-endian, это следует учитывать, если разработка драйвера ведется для архитектуры с иным порядком.
Давайте посмотрим что из себя представляют некоторые регистры.
VendorID и ProductID — уже известные нам регистры, в которых хранятся идентификаторы производителя и оборудования. Каждый из регистров занимает 2 байта.
Command — этот регистр определяет некоторые возможности PCI устройства, например разрешает или запрещает доступ к памяти.
Инициализацией этих битов занимается операционная система.
Status — биты этого регистра хранят информацию о различных событиях PCI шины.
Эти значения выставляются оборудованием, в моём случае были сконфигурированы только биты 9, 10, определяющие время реакции платы.
Revision ID — число, ревизия конкретной платы. Полезно в тех случаях, когда есть несколько ревизий устройства и различия необходимо учитывать в коде драйвера.
Class Code — «волшебное» число, отображающее класс устройства, например: Network Controller, Display Controller и т. п. Список существующих кодов можно посмотреть тут.
Base Address Registers — эти регистры, в количестве 6 штук, служат для определения того как и сколько памяти выделется устройству для процедур ввода/вывода. Этот регистр используется pci подсистемой ядра и обычно не интересен разработчикам драйверов.
Теперь можно перейти к программирование и попробовать прочесть эти регистры и получить доступ к памяти ввода/вывода.
Разработка модуля ядра
Как наверное многие знают — точками входа и выхода в модуль ядра Linux являются специальные __init и __exit функции.
Определим эти функции и выполним процедуру регистрации нашего драйвера с помощью вызова специальной функции — pci_register_driver(struct pci_driver *drv), а так же процедуру выгрузки с помощью pci_unregister_driver(struct pci_driver *drv).
Аргументом функций register и unregister является структура pci_driver, которую необходимо предварительно инициализировать, сделаем это в самом начале, объявив структуру статической.
Поля структуры, которые мы инициализируем:
name — уникальное имя драйвера, которое будет использовано ядром в /sys/bus/pci/drivers
id_table — таблица пар Vendor ID и Product ID, с которым может работать драйвер.
probe — функция вызываемая ядром после загрузки драйвера, служит для инициализации оборудования
remove — функция вызываемая ядром при выгрузке драйвера, служит для освобождения каких-либо ранее занятых ресурсов
Так же в структуре pci_driver предусмотрены дополнительные функции, которые мы не будем использовать в данном примере:
suspend — эта функция вызывается при засыпании устройства
resume — эта функция вызывается при пробуждении устройства
Рассмотрим как определяется таблица пар Vendor ID и Product ID.
Это простая структура со списком идентификаторов.
Где 0x0F0F — Vendor ID, а 0x0F0E и 0x0F0D — пара Product ID этого вендора.
Пар идентификаторов может быть как одна, так и несколько.
Обязательно завершать список с помощью пустого идентификатора
После объявления заполненной структуры необходимо передать её макросу
В функции my_driver_probe() мы можем делать, собственно, все что нам хочется.
Например можно попробовать прочитать конфигурационные регистры, описанные выше, с целью проверки корректности идентификаторов или выяснения ревизии платы.
В случае каких-либо проблем или несоответствий можно вернуть отрицательное значение кода ошибки и ядро прервет загрузку модуля. О чтении регистров конфигурации будет рассказано ниже.
Также обычно в этом месте выполняют инициализацию памяти ввода/вывода устройства для последующей работы с ней.
Полезным будет в этом месте определить некоторую «приватную» структуру драйвера в которой будут храниться данные, полезные во всех функциях драйвера. Например это может быть указатель на ту же память ввода/вывода устройства.
После инициализации приватной структуры необходимо выполнить её регистрацию
В функции my_driver_remove() удобно выполнять освобождение занятых ресурсов, например можно освободить память ввода/вывода.
Так же тут необходимо освобождать саму структуру struct pci_dev
Работа с регистрами конфигурации
Чтение 8, 16 и 32 бит регистров соответственно:
Запись 8, 16 и 32 бит регистров соответственно:
Первый аргумент всех этих функций — структура pci_dev, которая непосредственно связана с конкретным устройством PCI. Инициализация этой структуры будет рассмотрена далее.
Например мы хотим прочитать значения регистров Vendor ID, Product ID и Revision ID:
Как видно — все предельно просто, подставляя необходимое значение аргумента whrere мы можем получить доступ к любому конфигурационному регистру конкретного pci_dev.
С чтением/записью памяти устройства все несколько сложнее.
Мы должны указать какой тип ресурса хотим получить, определиться с размером и смещением, выделить необходимый кусок памяти и отобразить этот кусок памяти на устройство.
После этого мы можем писать и читать данную память как нам угодно, взаимодействуя непосредственно с устройством.
Дальше мы можем свободно работать с памятью, на которую указывает hwmem.
Правильнее всего использовать для этой цели специальные функции ядра.
Запись 8, 16 и 32 бит в память устройства:
Чтение 8, 16 и 32 бит из памяти устройства:
Убедитесь, что у вас установлены заголовочные файлы ядра. Для Debian/Ubuntu установка необходимого пакета выполняется так:
Компиляция модуля выполняется простой командой make, попробовать загрузить модуль можно командой
Скорее всего просто тихо ничего не произойдет, разве что у вас действительно окажется устройство с Vendor и Product ID из нашего примера.
Теперь я хотел бы вернуться к конкретному устройству, для которого разрабатывался драйвер.
Вот какую информацию про IO мне прислали разработчики платы ЛИР-941:
RgStatus:
b7 — Флаг паузы между транзакциями SSI (1 — пауза) (см. протокол SSI)
b6 — Флаг текущей трансакции (1- происходит передача данных) (см. протокол SSI)
b5 — Ext4 (Произошла защелка данных по сигналу Ext4)
b4 — Ext3 (Произошла защелка данных по сигналу Ext3)
b3 — Ext2 (Произошла защелка данных по сигналу Ext2)
b2 — Ext1 (Произошла защелка данных по сигналу Ext1)
b1 — Режим непрерывного опроса (По окончании передачи кода, аппаратно вырабатывается новый запрос)
b0 — По запросу от компьютера (Однократный запрос текущего положения)
Это значит, что если я хочу, например, прочитать данные от энкодера, подключенного к каналу 3 мне необходимо проверить седьмой бит блока RgStatus3, дождаться там еденички (пауза между транзакциями — значит уже ранее получили информацию от датчика и записали её в память платы, идет подготовка к следующему запросу) и прочитать число, хранящееся в третьем куске памяти длиной 32 бита.
Всё сводится к вычислению необходимо сдвига от начала куска памяти и чтения необходимого количества байт.
Из таблицы ясно, что данные каналов хранятся в виде 32 битных значений, а данные RgStatus — в виде значений длиной 8 бит.
Значит для чтения RgStatus3 необходимо сдвинуться 4 раза 32 бита и два раза по 8 бит и затем прочесть 8 бит из этой позиции.
А для чтения данных третьего канала необходимо сдвинуться 2 раза по 32 бита и прочесть значение длиной 32 бита.
Для выполнения всех этих операций можно написать удобные макросы:
Где chnum — номер требуемого канала, начиная с нуля.
Также не лишним в данном деле будет и такой простой макрос, определяющий «включен» ли бит на определенной позиции.
Получается такой код для чтения третьего канала данных:
Все, мы получили от платы данные датчика, подключенного к третьему каналу и записали их в переменную enc_data.
Касательно записи в устройство производитель прислал уже другую табличку.
Видно, что на запись структура немного другая и придется писать новые макросы, с новыми смещениями.
DATA WIDTH — Определяет максимальное количество бит в одной трансакции SSI. (разрядность приемного регистра). Допустимые значения – от 1 до 32
CLOCK RATE – Порт, определяющий коэффициент деления системного Clk (33 МГц) для формирования Сlock SSI.
Kдел = (CLOCK RATE)*2+2
PAUSE RATE Порт, определяющий величину паузы после транзакции, в периодах Clk (30 нс)
CONTROL 1:
b7 — Режим SSI (0 – обычный режим, 1 – режим 16 разрядного абс. Датчика, с ожиданием стартового бита (устаревший вариант выдачи данных, нужен только для совместимости)).
b6 — Зарезервировано
b5 — Разрешение внешнего сигнала Ext4
b4 — Разрешение внешнего сигнала Ext3
b3 — Разрешение внешнего сигнала Ext2
b2 — Разрешение внешнего сигнала Ext1
b1 — Разрешение непрерывного опроса датчика
b0 — Выработать однократный опрос
Тут все аналогично — считаем сдвиг для необходимой области и записываем значение соответствующей функцией iowriteX
Взаимодействие пользовательского окружения с PCI драйвером
Существует несколько путей общения вышестоящего ПО с нашим драйвером. Одним из самых старых, простых и популярных способов является символьное устройство, character device.
Character device — это виртуальное устройство, которое может быть добавлено в каталог /dev, его можно будет открывать, что-то записывать, читать, выполнять вызовы ioctl для задания каких-либо параметров.
Хороший пример подобного устройства — драйвер последовательного порта с его /dev/ttySX
Регистрацию character device удобно вынести в отдельную функцию
Указатель на нашу приватную структуру необходим для последующей инициализации файлового объекта, так что при каждом пользовательском вызове open/read/write/ioctl/close мы будем иметь доступ к нашей приватной структуре и сможем выполнять операции чтения/записи в PCI устройство.
Вызывать create_char_devs() удобно в функции my_driver_probe(), после всех инициализаций и проверок.
В моём случае эта функция называется именно create_char_devs(), во множественном числе. Дело в том, что драйвер создает несколько одноименных (но с разными цифровыми индексами в конце имени) character device, по одному на канал платы ЛИР941, это позволяет удобно, независимо и одноврменно работать сразу с несколькими подключенными датчиками.
Создать символьное устройство довольно просто.
Определяемся с количеством устройств, выделяем память и инициализируем каждое устройство настроенной структурой file_operations. Эта структура содержит ссылки на наши функции файловых операций, которые будут вызываться ядром при работе с файлом устройства в пространстве пользователя.
Внутри ядра все /dev устройства идентифицируются с помощью пары идентификаторов
Некоторые идентификаторы major являются зарезервированными и всегда назначаются определенным устройствам, остальные идентификаторы являются динамическими.
Значение major разделяют все устройства конкретного драйвера, отличаются они лишь идентификаторами minor.
При инициализации своего устройства можно задать значение major руками, ну лучше этого не делать, т. к. можно устроить конфликт. Самый лучший вариант — использовать макрос MAJOR().
Его применение будет показано в коде ниже.
В случае с minor значение обычно совпадает с порядковым номером устройства, при создании, начиная с нуля. Это позволяет узнать к какому именно устройству /dev/device-X обращаются из пространстрва ядра — достаточно посмотреть на minor доступный в обработчике файловых операций.
Идентификтаоры : отображаются утилитой ls с ключем -l
например если выполнить:
Число 89 — это major идентификатор драйвера контроллера i2c шины, оно общее для всех каналов i2c, а 0,1,2,3,4 — minor идентификаторы.
Пример создания набора устройств.
Функция mydev_open() будет вызываться, если кто-то попробует открыть наше устройство в пространстве пользователя.
Очень удобно в этой функции инициализировать приватную структуру для открытого файла устройства. В ней можно сохранить значение minor для текущего открытого устройства
Также туда можно поместить указатель на какие-то более глобальные структуры, помогающие взаимодействовать с остальным драйвером, например, мы можем в этом месте сохранить указатель на my_driver_priv, с которым мы работали ранее. Указатель на эту структуру можно использовать в операциях ioctl/read/write для выполнения запросов к аппаратуре.
Мы можем определить такую структуру:
Операции чтения и записи являются довольно простыми, единственный «нюанс» — небезопаность (а то и невозможность) прямого доступа пользовательского приложения к памяти ядра и наоборот.
В связи с этим для получения данных, записиваемых с помощью функции write() необходимо использовать функцию ядра copy_from_user().
А при выполнении read() необходимо пользоваться copy_to_user().
Обе функции оснащены различными проверками и обеспечивают безопасное копирование данных между ядром и пользовательским пространством
Обработчик вызова ioctl() принимает в качестве аргументов собственно номер ioctl операции и какие-то переданные данные в качестве аргументов (если они необходимы).
Номера операций ioctl() определяются разработчиком драйвера. Это просто некие «волшебные» числа, скрывающиеся за читабельными define.
Об этих номерах должна знать пользовательская программа, поэтому удобно выносить их куда-то в виде отдельного заголовочного файла.
Пример обработчика ioctl
Функция mydev_release() вызывается при закрыти файла-устройства.
В нашем случае достаточно лишь освободить память нашей приватной файловой структуры
В функции уничтожения символьного устройства необходимо удалить все созданные устройства, уничтожить sysfs class и освободить память.
Эту функцию следует вызывать в __exit методе модуля ядра, так что бы символьное устройство уничтожалось при выгрузке.
Вся остальная работа сводится к налаживанию взаимодействия между символьным устройством и фактической аппаратурой, а так же написанию различного вспомогательного кода.
Полный исходный код драйвера платы ЛИР941 можно посмотреть на Github.
А тут лежит простая тестовая утилита, работающая с этим драйвером.
Тестирование драйвера на настоящем железе 🙂
Спасибо за внимание!
Надеюсь этот материал будет полезен тем, кто решить написать свой драйвер для чего-нибудь.
Источник
