Драйверы linux для материнских плат

Добавление драйвера устройства в Linux

Обычно в системах Unix и Linux установка драйверов для новых устройств не вызывает трудностей. Даже для неопытных пользователей этих систем. Но это в том случае, если производители устройства (и/или разработчики драйверов) позаботились об этом. И оснастили пакет драйвера специальными установочными и конфигурационными скриптами. А также протестировали всё это в нескольких системах. Однако бывают случаи, когда «удобной» возможности установить драйвер устройства нет, но есть исходные коды драйвера. В таком случае можно попытаться собрать драйвер самостоятельно. Конечно, это далеко не так просто, нужно поэкспериментировать. Но успешный результат возможен с высокой вероятностью. И главное, что для этого требуется — это знать и понимать общий порядок действий в случае ручной сборки драйвера. С такими задачами часто сталкиваются администраторы систем, обслуживающих технологические процессы на производствах, хостинг-площадки и т. д.

Способы установки драйверов

Для Linux-систем установка драйверов устройств происходит тремя основными способами:

• установка патча для определённых версий ядра;
• использование специальных сценариев для установки и конфигурации драйвера;
• с помощью загружаемого модуля ядра.

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

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

Если в качестве драйвера используются патчи ядра, то установить их (собственно и сам драйвер) можно выполнив следующие команды:

Расположение «каталог_исходных_кодов_ядра» зависит от системы, в CentOS это /usr/lib/modules/ /kernel, Например

В случае с ручной установкой, необходимо для начала интегрировать драйвер некоего устройства (исходные коды) в дерево каталогов исходных кодов ядра.

Ручная установка драйвера

Для примера, пусть требуется добавить в ядро драйвер некоего сетевого устройства netdevice. Драйвер этого устройства нужно (как уже известно) поместить в один из каталогов с исходными кодами ядра. А именно — в каталог drivers, внутри которого может быть следующее содержимое:

Драйверы чаще всего помещаются в подкаталоги scsi, char, block, net, а также sound и usb. Эти подкаталоги отражают схему размещения драйверов в зависимости от их типа: блочные — для дисков IDE, символьные — для последовательных портов например, для сетевых устройств, звуковых плат и USB-устройств — USB-адаптеры, USB-модемы и т. д. Другие подкаталоги служат для размещения драйверов других категорий, в частности для системных и разного рода шин (pci, pcie, nubus, zorro), а также для платформенно-зависимых драйверов — acorn, macintosh.

Таким образом, драйверы для сетевого устройства netdevice следует поместить в следующий каталог:

Исходные коды драйвера представляют собой набор файлов *.c, *.cpp и *.h, которые могут быть объединены в дерево каталогов, в зависимости от того, как составлен проект «исходников» драйвера.

Теперь необходимо включить исходные коды драйвера netdevice в процесс компиляции ядра. Для этого нужно отредактировать следующие файлы:

• /drivers/net/Makefile – для сборки самого драйвера;
• /drivers/net/Kconfig – для того, чтобы имя нового устройства было доступно для конфигурирования.

Файлы Makefile и Kconfig содержатся в каждом каталоге дерева каталогов с исходными кодами ядра Linux. Это необходимо для организации универсальной разработки и расширения функционала и возможностей ядра при его сборке из исходных кодов путём независимого дополнения новым кодом. В данном случае кодом драйвера для устройства netdevice.

В файл Makefile следует добавить следующий код:

Таким образом, при сборке ядра в его составе будет собран и сам драйвер netdevice. После дополнения файла Kconfig следующим кодом:

устройство netdevice будет доступно для использования конфигурационным макросом (необходимо на этапе конфигурирования сборки ядра). Здесь команда config использует ключевое слово NETDEVICE_DEV, которое обязательно должно совпадать с фразой, следующей после CONFIG, которое ранее было указано в файле Makefile.

Команда tristate указывает, что драйвер может быть собран как загружаемый модуль, если это поддерживается. Если нет, то вместо tristate следует указать bool – драйвер будет частью ядра. Фраза ‘Netdevice support’ будет отображаться в выводе конфигурационного скрипта на этапе конфигурирования сборки ядра. Это может быть любой текст, идентифицирующий устройство, для которого добавляется драйвер.

Использование нового драйвера

В современных версиях ядра Linux задействование новых драйверов существенно упрощено. В отличие версий, выпущенных раньше 2.6. Тогда это было настоящей головоломкой и требовало знаний в программировании. Но архитектурные изменения в модели драйверов и устройств, пришедшие в версии 2.6 позволяют теперь связывать драйверы с ядром на более высоком «общепользовательском» уровне. Для этого используется специальный конфигурационный макрос MODULE_DEVICE_TABLE. Он создаёт соответствия, которые позволяют утилите modprobe (и ей подобным) задействовать новые драйверы ядра.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Разработка драйвера 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.

А тут лежит простая тестовая утилита, работающая с этим драйвером.

Тестирование драйвера на настоящем железе 🙂

Спасибо за внимание!
Надеюсь этот материал будет полезен тем, кто решить написать свой драйвер для чего-нибудь.

Источник