Pitonbl4 0 8 августа, 2018 Опубликовано 8 августа, 2018 · Жалоба Добрый день. Начал переходить с Bare metal на Linux. Пытаюсь разобраться как написать простенький драйвер для моей ip core. Пока это просто 8 лампочек. Борда: zedboard. Сейчас читаю литературу, т.к. до этого не было опыта написания драйверов. 1) Не рекомендуется писать драйвер под файловую систему /dev. Раньше конечно так делали. Сейчас, якобы актуально писать под файловую систему /proc или /sys. Верно ли это? Хочется сразу научиться праивльным вещам. :maniac: Т.е. может при написании драйвера под какую-нибудь фс скрываются ккаие-то подводные камни. И есть резон писать под другую фс. 2) Почитал https://linuxseekernel.blogspot.com/2014/05...-practical.html и, честно говоря, так и не понял какое различие между: Platform Driver Platform Device Т.е. это два независимых варианта? Или есть определенные случаи когда стоит что-то конкретное из этого использовать? 3) Как я понял. Написание дравера состоит из двух больших шагов. а) Создать виртуальный файл в файловой системе. Чтобы в него можно было писать/читать и т.д. б) Связать этот виртуальный файл с физическим устройством. Верно? 4) Пока нашел такой код. Все нормально работает. myled.txt Как можно реализовать чтение и запись в регистры с определенным сдвигом? Действовать через base_addr (он определен в коде)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Viwon 0 14 августа, 2018 Опубликовано 14 августа, 2018 · Жалоба 1) Когда разбирался с драйверами(полтора года назад) не видел рекомендаций об отказе от файлов в /dev, были рекомендации не использовать функцию ioctl для управления настройками устройства/драйвера, в пользу управления настойками через файлы в /sys 2) Device - это устройство, в вашем случае "лампочки", Driver - это программа управляющая этим устройством, которую вы разрабатываете. Platform - значит, что усройство встоенное, т.е. всегда подключено. Т.е. это две разные сущности - встроенное устройство(железо) и драйвер для встроенного устойства(программа). 3) Я бы сказал написание драйвера это написание функций-обработчиков чтения/записи и т.д файлов. Создание файла устойства и связь его с устойством(драйвером) сейсас дело пару сток, в вашем случае это делает функция proc_create(). 4) base_addr - связан с регистрами устойства "лампочки", если у этого устойства несколько подряд идущих регистров(и это описано в конфигурационных файлах), то да, к ним можно обращаться смещаясь относитльно base_addr. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pitonbl4 0 15 августа, 2018 Опубликовано 15 августа, 2018 · Жалоба Спасибо! От себя только добавлю, что тема про Platform device и Platform driver хорошо раскрыта здесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 17 августа, 2018 Опубликовано 17 августа, 2018 · Жалоба Случайно увидел ваш вопрос. Пишите про Линукс в теме Линукс. 1) Не рекомендуется писать драйвер под файловую систему /dev. Раньше конечно так делали. Сейчас, якобы актуально писать под файловую систему /proc или /sys. Верно ли это? Хочется сразу научиться праивльным вещам. maniac.gif Т.е. может при написании драйвера под какую-нибудь фс скрываются ккаие-то подводные камни. И есть резон писать под другую фс. В этом вопросе каша. На самом деле все происходит таким образом: Вы регистрируете драйвер, ядро записывает информацию о нем в соответствующие структуры и драйвер появляется в /sys/. В дереве устройств вы описываете устройство для этого драйвера (в /sys появятся записи об устройстве) и если они (драйвер и устройство) соответствуют друг другу, то вызовется функция драйвера probe. Если probe не вернет ошибку, то устройство встало и подключилось к драйверу. Если у вас написано правило для этого устройства в правилах udev, то в /dev появится псевдофайл для доступа к вашему устройству. Если нет, то его можно создать при помощи команды mknod. platform device: Вы наверняка за обилием информации не заметили важнейшего момента, что драйвер и устройство должны СООТВЕТСТВОВАТЬ друг другу. На самом деле драйверы (о блоковых драйверах мы вообще не говорим) подразделяются на несколько групп. Список этих групп вы найдете в разделе шин: /sys/bus/ Оказалось, что есть такая группа, которую ни к одной шине отнести нельзя. Ее назвали platform. Внутри каждой группы свои правила по которым проверяется соответствие драйвера и устройства. Для PCI и USB это Vendor ID и Product ID, для platform это просто текстовое имя. Это должно совпасть в драйвере и устройстве. На самом деле есть еще нюансы, но в целом картина выглядит таким образом. Спасибо! От себя только добавлю, что тема про Platform device и Platform driver хорошо раскрыта здесь. В этом тексте все описано для ядер до 2.6.Х включительно. С 3.Х.Х вместо структуры устройства в тексте программы начали описывать устройства в дереве устройств. Можно на все положить и сделать нестандартно, но так профессионалы не будут делать. Сделать доступ к программе (не могу назвать это драйвером) через интерфейс /proc. Но так сделать легко. Как это делать подробно изложено здесь: https://www.iitg.ac.in/asahu/cs421/books/LKM2.6.pdf Это навскидку нашел. есть и более свежие версии этого документа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pitonbl4 0 17 августа, 2018 Опубликовано 17 августа, 2018 · Жалоба 1. В этом вопросе каша. Почитал методу на ibm. Давайте напишем модуль под /dev; /sys; /proc. Этот модуль вы можете допилить до драйвера. В таком духе. Поэтому то, что вы написали далее я и не знал. 2. С 3.Х.Х вместо структуры устройства в тексте программы начали описывать устройства в дереве устройств. Да, сейчас сам описыал в device tree устройство и поэтому не доходило про platform device. Зачем описывать структуру устройства в platform device, если еcть device tree. 3. На самом деле драйверы (о блоковых драйверах мы вообще не говорим) подразделяются на несколько групп. Список этих групп вы найдете в разделе шин: /sys/bus/ Оказалось, что есть такая группа, которую ни к одной шине отнести нельзя. Ее назвали platform. Platform devices сами по себе не поддаются обнаружению. Т.е. устройство не может сказать "Эй! Я присутствую!" программному обеспечению. Что делать? Для это была введена виртуальная шина (platform bus). С одной стороны устройства подключаются к такой шине, а с другой - к шине присоединяются драйвера, которые запрашивают устройства с необходимым именем. Т.е. за это как раз и отвечают эти строки: // Из device tree static const struct of_device_id myled_of_match[] = { {.compatible = "xlnx,myled-1.0"}, {}, }; static struct platform_driver myled_driver = { .driver = { .name = DRIVER_NAME, .owner = THIS_MODULE, .of_match_table = myled_of_match}, .probe = myled_probe, // Обязательно .remove = myled_remove, .shutdown = myled_shutdown }; Но для PCI и USB там другая картина. Как вы и написали. 4. Можно на все положить и сделать нестандартно, но так профессионалы не будут делать. Сделать доступ к программе (не могу назвать это драйвером) через интерфейс /proc. Но так сделать легко. Как это делать подробно изложено здесь: https://www.iitg.ac.in/asahu/cs421/books/LKM2.6.pdf Т.е. /proc это не профессионально, но советуете книгу чтобы подробней изучить этот метод. А как тогда делают проффесионалы? Изучать примеры реальных драйверов? На данный момент успел поковыряться с /proc. Действительно, довольно просто. Книгу пока быстро полистал, там есть и про /dev и /proc, а дальше пока не смотрел. (не могу назвать это драйвером) Из-за тогоч то нет переносимости? Ведь драйвер это прослойка между железом и, в конечном счете, пользователем. Т.е. что надо пользователю? Знать какие есть методы, структуры и т.д. в драйвере, чтобы можно легко было взаимодействовать с железом через свою прогу. P.S Про размещение топика учту. Толком не мог определить, куда можно задать свой вопрос. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 18 августа, 2018 Опубликовано 18 августа, 2018 · Жалоба Речь не идет о поддается обнаружению. Если в дереве устойств есть и зарегистрирован драйвер, то драйвер ставится и устройство готово работать. Для pug&play устройств тоже надо в дереве описывать. Там просто еще дополнительный механизм. Почему описывают структуру platform device я уже написал. До версии ядра 3.Х.Х все устройства описывались структурами, а после появилось дерево, которое компилируется отдельно и не надо перестраивать ядро. /dev это не то же самое что /proc и /sys две последние примерно одно и то же. первая пришла из юникса. В них отображаются внутренние структуры ядра, а в /dev расположены pipes для связи с устройствами. Все драйвера, к которым нужно иметь доступ из пространства пользователя отображены в /dev. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться