Pitonbl4 0 August 8, 2018 Posted August 8, 2018 · Report post Добрый день. Начал переходить с 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 (он определен в коде)? Quote Share this post Link to post Share on other sites More sharing options...
Viwon 0 August 14, 2018 Posted August 14, 2018 · Report post 1) Когда разбирался с драйверами(полтора года назад) не видел рекомендаций об отказе от файлов в /dev, были рекомендации не использовать функцию ioctl для управления настройками устройства/драйвера, в пользу управления настойками через файлы в /sys 2) Device - это устройство, в вашем случае "лампочки", Driver - это программа управляющая этим устройством, которую вы разрабатываете. Platform - значит, что усройство встоенное, т.е. всегда подключено. Т.е. это две разные сущности - встроенное устройство(железо) и драйвер для встроенного устойства(программа). 3) Я бы сказал написание драйвера это написание функций-обработчиков чтения/записи и т.д файлов. Создание файла устойства и связь его с устойством(драйвером) сейсас дело пару сток, в вашем случае это делает функция proc_create(). 4) base_addr - связан с регистрами устойства "лампочки", если у этого устойства несколько подряд идущих регистров(и это описано в конфигурационных файлах), то да, к ним можно обращаться смещаясь относитльно base_addr. Quote Share this post Link to post Share on other sites More sharing options...
Pitonbl4 0 August 15, 2018 Posted August 15, 2018 · Report post Спасибо! От себя только добавлю, что тема про Platform device и Platform driver хорошо раскрыта здесь. Quote Share this post Link to post Share on other sites More sharing options...
Tarbal 4 August 17, 2018 Posted August 17, 2018 · Report post Случайно увидел ваш вопрос. Пишите про Линукс в теме Линукс. 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 Это навскидку нашел. есть и более свежие версии этого документа. Quote Share this post Link to post Share on other sites More sharing options...
Pitonbl4 0 August 17, 2018 Posted August 17, 2018 · Report post 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 Про размещение топика учту. Толком не мог определить, куда можно задать свой вопрос. Quote Share this post Link to post Share on other sites More sharing options...
Tarbal 4 August 18, 2018 Posted August 18, 2018 · Report post Речь не идет о поддается обнаружению. Если в дереве устойств есть и зарегистрирован драйвер, то драйвер ставится и устройство готово работать. Для pug&play устройств тоже надо в дереве описывать. Там просто еще дополнительный механизм. Почему описывают структуру platform device я уже написал. До версии ядра 3.Х.Х все устройства описывались структурами, а после появилось дерево, которое компилируется отдельно и не надо перестраивать ядро. /dev это не то же самое что /proc и /sys две последние примерно одно и то же. первая пришла из юникса. В них отображаются внутренние структуры ядра, а в /dev расположены pipes для связи с устройствами. Все драйвера, к которым нужно иметь доступ из пространства пользователя отображены в /dev. Quote Share this post Link to post Share on other sites More sharing options...
