nik.laus 0 13 октября, 2008 Опубликовано 13 октября, 2008 · Жалоба Добрый день. Нужен ваш совет. У меня проблема. Пишу драйвер под linux (2.6.18) для платы, которуй сами и разработали (на чипе intel 82530 scc). Есть драйвер под дос на паскале, и под дос плата работает. Я делаю теже шажи, пишу в теже регистры теже значения в линукс, собираю модуль и у меня она не работает... проявляется это так: читать и писать в порты ввода/вывода я могу и это работает, но плата прерываний не генерирует абсолютно : (((. Это мой первый драйвер (драйвер для паралельного порта, та который напаяны светодиоды, и который генерирует прерывания я не беру в расчет), поэтому здесь у меня даже життейской мудрости нету, которую хотелось бы тоже обрести. Есть вопрос, каким образом можно (нужно) это отлаживать, что-бы хотя-бы быть уверенным в том, где и что не работает... Средства диагностики какие-нибуть... Забыл сказать, плата на isa шине, драйвер в ядре (не user space application) и естественно под дос это все работает :(((. Модуль загружается работает, карточку инициализирует (или якобы инициализирует...), устанавливается обработчик прерываний, делается soft interrupt ( __asm__("int $37") )... а фреймы данных карта не получает... Вот, прошу помощи специалистов. Кто в таких ситуациях как поступает и что порекомендуете... Вообщем, куда и что мне надо копать, учить??? Заранее очень благодарен за ЛЮБЫЕ ответы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 13 октября, 2008 Опубликовано 13 октября, 2008 · Жалоба :bb-offtopic: Форум на русском языке, приятно читать текст грамотно написанный. На жаргон могут и не ответить :) По существу: Регистрируется ли модуль ядром linux? Отладочные средства ядра есть, например, kprintf для вывода сообщений ядра на консоль. Есть книги, в том числе и на русском, по написанию драйверов под linux. Посмотрите драйверы устройств шины ISA в исходных текстах ядра. Сильно помогает изучение исходных кодов драйверов. На форуме есть ветка про плату на AT91SAM92xx с linux на борту (микроконтроллеры-> ARM), в которой обсуждаются разные аспекты. Может быть эта информация даст пищу для Ваших размышлений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amw 0 13 октября, 2008 Опубликовано 13 октября, 2008 · Жалоба У меня проблема. Пишу драйвер под linux (2.6.18) для платы, которуй сами и разработали (на чипе intel 82530 scc). Есть хорошая книга Linux Device Drivers http://oreilly.com/catalog/9780596005900/book/index.csp http://lwn.net/Articles/125908/ Там есть немного про ISA. Где-то там же есть к этой книге и исходники примеров. Диагностика - printk() - то же что и printf. Вывод заносится в log файлы и печатается на консоль. С отладчиками посложнее - ядро все таки. Но можно прикрутить gdb и запускать на соседнем компьютере, а отлаживать по сети или последовательному порту. В смысле с использованием gdb отладчика. По поводу ( __asm__("int $37") ) не уверен что все так просто. Хотя тот-же X11 такое делает. Сам не применял ни разу. Возможно такой драйвер уже есть в ядре? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nik.laus 0 15 октября, 2008 Опубликовано 15 октября, 2008 · Жалоба Приятно, что ответили. Спасибо mdmitry и amw. По поводу "Linux Device Drivers third edition" - это я знаю. Дя и про isa у них там достаточно мало, так, для программистов и все... но это не "это самое". За посыл в ядро посмотреть на isa драйвера спасибо. Касательно printk() знаю, только оно выводит в буфер а не на консоль, на консоль еще и приоритет должен быть достаточный и еще что-то...( в LDD 3ed это написано, главу непомню ). Регистрируется ли модуль ядром. insmod выполняется, драйвер в ядре висит, успешно выгружается. Обработчик прерываний тоже успешно устанавливается ( $cat /proc/interrupts ). Сообщения тоже успешно выводит в буфер и я с помощью dmesg их читаю. Касательно отладчиков я имел ввиду не gdb и к ядру модули отладочные. Я имел ввиду что-то, что можно в шину воткнуть (осцилограф...) и посмотреть, идут ли сигналы, не сбиваются ли фронты. Или это бред??? В досе вызывается int 0x0D (irq5 в real mode), мне в линуксе надо делать int 37 (irq5 protected mode) правильно? И что эта команда делает?, прото передает управление обработчику прерывания и все? Железо никак не трогает? Стоит ли читать по железу (PC)? если стоит, то подскажите стоящую книгу, пожалуйста. :bb-offtopic: Если в моем русском есть ошибки, исправляйте!!! А жаргона вроде нет... :bb-offtopic: Оч большое спасибо за внимание! Решил открыть ящик, посмотреть на схемы, оказалось там не i82530, а Z85C30[08PSC]... В ядре есть драйвер от Alan'a Cox'a, для этой симейки чипов... Будем ковырять и надеятся на успех :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 15 октября, 2008 Опубликовано 15 октября, 2008 · Жалоба Я имел ввиду что-то, что можно в шину воткнуть (осцилограф...) и посмотреть, идут ли сигналы, не сбиваются ли фронты. Или это бред??? НЕ бред. Смотрел шину SPI (всего 4 провода) в свое время. Для аппаратного просмотра состояния шины нужен как минимум осциллограф, лучше цифровой минимум на 2 канала. Если есть возможность, то лучшее решение - цифровой анализатор сигналов (Logic Analyzers). Анализатор представляет собой своеобразный цифровой осциллограф для наблюдения большого числа цифровых каналов одновременно на экране прибора. Имеется возможность наблюдать и обычную осциллограмму. Agilent выпускает такую аппаратуру, но она очень дорогая. Аппаратная часть работает правильно и Вы имеете возможность наблюдать правильную работу в ДОС. Подобный протокол на шине должен быть и для Вашего случая. В досе вызывается int 0x0D (irq5 в real mode), мне в линуксе надо делать int 37 (irq5 protected mode) правильно? И что эта команда делает?, прото передает управление обработчику прерывания и все? Железо никак не трогает? Возможно, имеет смысл посмотреть драйвер ядра для COM-порта, в плане того, что происходит при запросе прерывания от контроллера порта и действовать аналогично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amw 0 16 октября, 2008 Опубликовано 16 октября, 2008 · Жалоба За посыл в ядро посмотреть на isa драйвера спасибо. Касательно printk() знаю, только оно выводит в буфер а не на консоль, на консоль еще и приоритет должен быть достаточный и еще что-то...( в LDD 3ed это написано, главу непомню ). Если действительно нужно на консоль, то поменяйте уровень лога в самом syslogd при запуске, вернее klogd - потому как именно он отвечает за логирование из printk. Не помню какой приоритет по умолчанию, но поставте что-то типа -c 7. Это засыпет консоль сообщениями. Я обычно использую другую тактику. В отдельной консоли или xterm запускаю tail -F /var/log/messages В засимости от настроек и дистрибутива может использоваться syslog, messages, debug и др. файлы. А в самом printk указать приоритет. printk(KERN_INFO "Simply for info priority"); printk(KERN_CRIT "Critical (like kernel panic) priority"); printk(KERN_ERROR "For unrecoverable but not fatal errors priority"); printk(KERN_DEBUG "Debugging priority"); printk(KERN_WARNING "For warnings priority"); Константы KERN_* представляют собой строковые константы типа "<1>" "<2>" "<3>" "<4>" ... "<7>" Регистрируется ли модуль ядром. insmod выполняется, драйвер в ядре висит, успешно выгружается. Обработчик прерываний тоже успешно устанавливается ( $cat /proc/interrupts ). Сообщения тоже успешно выводит в буфер и я с помощью dmesg их читаю. Ну если Вы видите Ваши сообщения - то да. Тем более, что обработчик установился. Касательно отладчиков я имел ввиду не gdb и к ядру модули отладочные. Я имел ввиду что-то, что можно в шину воткнуть (осцилограф...) и посмотреть, идут ли сигналы, не сбиваются ли фронты. Или это бред??? Это не бред. Но с другой стороны, если у Вас серийная плата, то она по идее должна "хорошо" себя вести. (см. пред. пост :) ). В досе вызывается int 0x0D (irq5 в real mode), мне в линуксе надо делать int 37 (irq5 protected mode) правильно? И что эта команда делает?, прото передает управление обработчику прерывания и все? Железо никак не трогает? Вот тут самое интересное. Этот самый int 37, он кем предоставлятся? То есть фактический обработчик int 37 находится в BIOS, BIOS Вашей платы, или Вы должны туда подсунуть свою функцию? Это действительно программное прерывание? Или вывод IRQ платы "разведен" на это прерывание? Если это BIOS платы - то нужно убедится что BIOS вашего ПК при старте обнаружил и инициализировал BIOS платы. Надеюсь соответствующие сообщения предусмотрены в плате. А вот дальше когкретного совета нет (повторю, такого сам не делал). Однако по аналогии могу предложить поковырять драйвера VGA/VESA в ядре. Видеокарта предоставляет из своего BIOS набор программных прериваний, в том числе и для protected mode. И драйвер VGA/VESA в ядре их вызывает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nik.laus 0 20 октября, 2008 Опубликовано 20 октября, 2008 · Жалоба Этот самый int 37, он кем предоставлятся? То есть фактический обработчик int 37 находится в BIOS, BIOS Вашей платы, или Вы должны туда подсунуть свою функцию? Это действительно программное прерывание? Или вывод IRQ платы "разведен" на это прерывание? Если это BIOS платы - то нужно убедится что BIOS вашего ПК при старте обнаружил и инициализировал BIOS платы. Надеюсь соответствующие сообщения предусмотрены в плате. amw, а можно по конкретнее данную тему, где о ней можно почитать? (если можно и есть, ссылку на статью по данной теме..., я о ней ни малейшего представления не имею и даже ниразу не слышал, кроме этого форума) А вообще вроде там ничего такого нету... а что касается int 37 - "ну, это ,как-бы..." эмуляция 5 hardварного прерывания, внутри проца, если он в защищенном режиме работает... в реальном режиме это будет int 13 (8 зарезервировано, а не 32...) вот из этого я и исхожу... И действительно, в cat /proc/stat | grep intr появляется 5 прерывание (становится 1 после того, как было 0, и увеличивается на 1 кажный раз, когда я делаю int 37). Поэтому я думаю, что int 37 это тоже самое что и "железное 5тое", за исключением того, что это программный муляж. А плата генерит 5 irq, а биосом на плате вроде и не пахнет (только io ports) (в доке к чипу об этом даже не упоминается, а все остальные чипы на плате - простые наборы вентилей, выполняющих свою функцию, ниче умного, вроде...). Дайте ссылку, где про биос на плате и тому подобные темы почитать можно. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amw 0 20 октября, 2008 Опубликовано 20 октября, 2008 (изменено) · Жалоба amw, а можно по конкретнее данную тему, где о ней можно почитать? (если можно и есть, ссылку на статью по данной теме..., я о ней ни малейшего представления не имею и даже ниразу не слышал, кроме этого форума) Не обижайтесь за повторение, но... Я такого в Линукс не делал. Но делал нечто похожее, при написании собственного загрузчика. У меня была PCI плата с BIOS на ней (сами делали и плату и ее биос). Загружал Линукс. Тоже с платы (не ней была флеш/MMC). Суть сводилась к тому, штатными средтвами BIOS материнки инициализировался BIOS PCI платы (она была как Boot Device), регистрировался через PCI PnP BIOS функции собственный (встроенный в PCI плату) обработчик программного прерывания. Когда BIOS материнки вызывал загрузчик нашей платы, он (загрузчик) инитил Protected Mode, устанавливал IDT и Gate для него, и потом через инструкцию int 21h (выбирали от фонаря, но чтоб не пересечся с BIOS материнки, а int 21h - это DOS, которого у нас небыло) получали доступ к флеш/MMC. Оттуда грузили Линукс. И все. В линукс был другой драйвер и никаких int 21h он не использовал. Где почитать на эту тему в контексте Линукс - не знаю. Я использовал документы PnP BIOS, Phoenix BIOS specification. Но это про этап загрузки ПК, а не про Линукс. Нашел в сети, google помог. Мой случай пересекается _слегка_ с исходником в Линукс (2.6.26) arch/x86/pci/pcbios.c А вообще вроде там ничего такого нету... а что касается int 37 - "ну, это ,как-бы..." эмуляция 5 hardварного прерывания, внутри проца, если он в защищенном режиме работает... в реальном режиме это будет int 13 (8 зарезервировано, а не 32...) вот из этого я и исхожу... И действительно, в cat /proc/stat | grep intr появляется 5 прерывание (становится 1 после того, как было 0, и увеличивается на 1 кажный раз, когда я делаю int 37). Поэтому я думаю, что int 37 это тоже самое что и "железное 5тое", за исключением того, что это программный муляж. Так прерывание программное или аппаратное? А почему 37 а не 5? И откуда на этом прерывании обработчик? Он там вообще есть? Если нет - то установите свой. Тогда по int 37 должна вызваться Ваша функция -обработчик. Возмооожно я не понял что имеено Вам нужно? Я почему-то решил, что у Вас есть некий обработчик сидящий в BIOS то-ли Вашей, то материнской платы. Ноесли такого нет - то установите свой. request_irq() Вам в помощь. А плата генерит 5 irq, а биосом на плате вроде и не пахнет (только io ports) (в доке к чипу об этом даже не упоминается, а все остальные чипы на плате - простые наборы вентилей, выполняющих свою функцию, ниче умного, вроде...). Дайте ссылку, где про биос на плате и тому подобные темы почитать можно. Спасибо. Честно говоря, не понял смысла использования int 37. Если у Вас нет обработчика программного прерывания типа в BIOS, и нет аппаратного прерывания, то зачем оно Вам вообще? Заведите к примеру таймер, и занимейтесь pooling-ом. Аналогия с DOS не всегда уместна. PS: Посмотрел только что исходники ядра 2.6.26. Там все теперь по другому. Когда я года 4 назад делал проект (см. выше) то ядро было то-ли 2.6.12 то-ли еще старее. Там находил вызовы int 10h где-то в районе framebuffer и vga console. Изменено 20 октября, 2008 пользователем amw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nik.laus 0 7 ноября, 2008 Опубликовано 7 ноября, 2008 · Жалоба Добрый день снова! :) По поводу int 37 - оно в дос драйвере было... (int 0x0D) Нужно оно там было для того, чтобы проц запустил обработчик прерывания, свежеустановленный, наш. В конце обработчика есть команда записать в порт 20h 0x20 - команда pic1, которая что-то там делает, чтобы потом можно было снова это прерывание принимать... Но, в недавнем времени ситуация изменилась... При очередном... третьем или четвертом... пререписывании драйвера, оно мна начало давать прерывания... Ведут они себя немножко странно... Пробую и так и сяк и смотрю на них. Хочу добиться от них стабильности появления, ну и понять все тонкости... :05: То так ее инициализирую, то так... Смотрю на поведение... Int не использую, и так генерит... Всем БОЛЬШОЕ спасибо за помощь и внимание :) . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться