Добрый день.
Нужен ваш совет.

У меня проблема. Пишу драйвер под linux (2.6.18) для платы, которуй сами и разработали (на чипе intel 82530 scc).
Есть драйвер под дос на паскале, и под дос плата работает. Я делаю теже шажи, пишу в теже регистры теже значения
в линукс, собираю модуль и у меня она не работает... проявляется это так: читать и писать в порты ввода/вывода я могу
и это работает, но плата прерываний не генерирует абсолютно : (((. Это мой первый драйвер (драйвер для паралельного порта, та который напаяны светодиоды, и который генерирует прерывания я не беру в расчет), поэтому здесь у меня
даже життейской мудрости нету, которую хотелось бы тоже обрести.

Есть вопрос, каким образом можно (нужно) это отлаживать, что-бы хотя-бы быть уверенным в том, где и что не работает...
Средства диагностики какие-нибуть...

Забыл сказать, плата на isa шине, драйвер в ядре (не user space application) и естественно под дос это все работает ((.
Модуль загружается работает, карточку инициализирует (или якобы инициализирует...), устанавливается обработчик прерываний, делается soft interrupt ( __asm__("int $37") )... а фреймы данных карта не получает...

Вот, прошу помощи специалистов. Кто в таких ситуациях как поступает и что порекомендуете...
Вообщем, куда и что мне надо копать, учить???

Заранее очень благодарен за ЛЮБЫЕ ответы.

Форум на русском языке, приятно читать текст грамотно написанный. На жаргон могут и не ответить

По существу:
Регистрируется ли модуль ядром linux?
Отладочные средства ядра есть, например, для вывода сообщений ядра на консоль.
Есть книги, в том числе и на русском, по написанию драйверов под linux. Посмотрите драйверы устройств шины ISA в исходных текстах ядра. Сильно помогает изучение исходных кодов драйверов.

На форуме есть ветка про плату на AT91SAM92xx с linux на борту (микроконтроллеры-> ARM), в которой обсуждаются разные аспекты. Может быть эта информация даст пищу для Ваших размышлений.

Есть хорошая книга 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 такое делает. Сам не применял ни разу.

Возможно такой драйвер уже есть в ядре?

Приятно, что ответили. Спасибо 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)? если стоит, то подскажите стоящую книгу, пожалуйста.

Если в моем русском есть ошибки, исправляйте!!! А жаргона вроде нет...

Оч большое спасибо за внимание!



Решил открыть ящик, посмотреть на схемы, оказалось там не i82530, а Z85C30[08PSC]...
В ядре есть драйвер от Alan'a Cox'a, для этой симейки чипов... Будем ковырять и надеятся на успех

НЕ бред. Смотрел шину SPI (всего 4 провода) в свое время. Для аппаратного просмотра состояния шины нужен как минимум осциллограф, лучше цифровой минимум на 2 канала. Если есть возможность, то лучшее решение - цифровой анализатор сигналов (Logic Analyzers). Анализатор представляет собой своеобразный цифровой осциллограф для наблюдения большого числа цифровых каналов одновременно на экране прибора. Имеется возможность наблюдать и обычную осциллограмму. Agilent выпускает такую аппаратуру, но она очень дорогая. Аппаратная часть работает правильно и Вы имеете возможность наблюдать правильную работу в ДОС. Подобный протокол на шине должен быть и для Вашего случая.


Возможно, имеет смысл посмотреть драйвер ядра для COM-порта, в плане того, что происходит при запросе прерывания от контроллера порта и действовать аналогично.

Если действительно нужно на консоль, то поменяйте уровень лога в самом syslogd при запуске, вернее klogd - потому как именно он отвечает за логирование из printk. Не помню какой приоритет по умолчанию, но поставте что-то типа -c 7. Это засыпет консоль сообщениями.
Я обычно использую другую тактику.
В отдельной консоли или xterm запускаю

В засимости от настроек и дистрибутива может использоваться syslog, messages, debug и др. файлы.
А в самом printk указать приоритет.

Константы KERN_* представляют собой строковые константы типа "<1>" "<2>" "<3>" "<4>" ... "<7>"

Ну если Вы видите Ваши сообщения - то да. Тем более, что обработчик установился.

Это не бред. Но с другой стороны, если у Вас серийная плата, то она по идее должна "хорошо" себя вести. (см. пред. пост ).

Вот тут самое интересное.
Этот самый int 37, он кем предоставлятся? То есть фактический обработчик int 37 находится в BIOS, BIOS Вашей платы, или Вы должны туда подсунуть свою функцию? Это действительно программное прерывание? Или вывод IRQ платы "разведен" на это прерывание?
Если это BIOS платы - то нужно убедится что BIOS вашего ПК при старте обнаружил и инициализировал BIOS платы. Надеюсь соответствующие сообщения предусмотрены в плате.
А вот дальше когкретного совета нет (повторю, такого сам не делал).
Однако по аналогии могу предложить поковырять драйвера VGA/VESA в ядре. Видеокарта предоставляет из своего BIOS набор программных прериваний, в том числе и для protected mode. И драйвер VGA/VESA в ядре их вызывает.

amw, а можно по конкретнее данную тему, где о ней можно почитать? (если можно и есть, ссылку на статью по данной теме..., я о ней ни малейшего представления не имею и даже ниразу не слышал, кроме этого форума)

А вообще вроде там ничего такого нету... а что касается int 37 - "ну, это ,как-бы..." эмуляция 5 hardварного прерывания, внутри проца, если он в защищенном режиме работает... в реальном режиме это будет int 13 (8 зарезервировано, а не 32...)
вот из этого я и исхожу... И действительно, в появляется 5 прерывание (становится 1 после того, как было 0, и увеличивается на 1 кажный раз, когда я делаю int 37). Поэтому я думаю, что int 37 это тоже самое что и "железное 5тое", за исключением того, что это программный муляж.

А плата генерит 5 irq, а биосом на плате вроде и не пахнет (только io ports) (в доке к чипу об этом даже не упоминается, а все остальные чипы на плате - простые наборы вентилей, выполняющих свою функцию, ниче умного, вроде...).

Дайте ссылку, где про биос на плате и тому подобные темы почитать можно. Спасибо.

Не обижайтесь за повторение, но... Я такого в Линукс не делал.
Но делал нечто похожее, при написании собственного загрузчика.
У меня была 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


Так прерывание программное или аппаратное? А почему 37 а не 5? И откуда на этом прерывании обработчик? Он там вообще есть? Если нет - то установите свой. Тогда по int 37 должна вызваться Ваша функция -обработчик.

Возмооожно я не понял что имеено Вам нужно? Я почему-то решил, что у Вас есть некий обработчик сидящий в BIOS то-ли Вашей, то материнской платы. Ноесли такого нет - то установите свой. request_irq() Вам в помощь.

Честно говоря, не понял смысла использования int 37.
Если у Вас нет обработчика программного прерывания типа в BIOS, и нет аппаратного прерывания, то зачем оно Вам вообще?
Заведите к примеру таймер, и занимейтесь pooling-ом. Аналогия с DOS не всегда уместна.

PS:
Посмотрел только что исходники ядра 2.6.26. Там все теперь по другому. Когда я года 4 назад делал проект (см. выше) то ядро было то-ли 2.6.12 то-ли еще старее. Там находил вызовы int 10h где-то в районе framebuffer и vga console.

Добрый день снова!

По поводу int 37 - оно в дос драйвере было... (int 0x0D)
Нужно оно там было для того, чтобы проц запустил обработчик
прерывания, свежеустановленный, наш. В конце обработчика есть
команда записать в порт 20h 0x20 - команда pic1, которая что-то
там делает, чтобы потом можно было снова это прерывание принимать...

Но, в недавнем времени ситуация изменилась... При очередном... третьем
или четвертом...
пререписывании драйвера, оно мна начало давать прерывания...
Ведут они себя немножко странно... Пробую и так и сяк и смотрю на них.
Хочу добиться от них стабильности появления, ну и понять все тонкости...
То так ее инициализирую, то так... Смотрю на поведение...

Int не использую, и так генерит...
Всем БОЛЬШОЕ спасибо за помощь и внимание .