Перейти к содержанию
    

Нужна помощь специалистов

Добрый день.

Нужен ваш совет.

 

У меня проблема. Пишу драйвер под linux (2.6.18) для платы, которуй сами и разработали (на чипе intel 82530 scc).

Есть драйвер под дос на паскале, и под дос плата работает. Я делаю теже шажи, пишу в теже регистры теже значения

в линукс, собираю модуль и у меня она не работает... проявляется это так: читать и писать в порты ввода/вывода я могу

и это работает, но плата прерываний не генерирует абсолютно : (((. Это мой первый драйвер (драйвер для паралельного порта, та который напаяны светодиоды, и который генерирует прерывания я не беру в расчет), поэтому здесь у меня

даже життейской мудрости нету, которую хотелось бы тоже обрести.

 

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

Средства диагностики какие-нибуть...

 

Забыл сказать, плата на isa шине, драйвер в ядре (не user space application) и естественно под дос это все работает :(((.

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

 

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

Вообщем, куда и что мне надо копать, учить???

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

По существу:

Регистрируется ли модуль ядром linux?

Отладочные средства ядра есть, например,

 kprintf

для вывода сообщений ядра на консоль.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня проблема. Пишу драйвер под 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 такое делает. Сам не применял ни разу.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приятно, что ответили. Спасибо 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, для этой симейки чипов... Будем ковырять и надеятся на успех :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я имел ввиду что-то, что можно в шину воткнуть (осцилограф...) и посмотреть, идут ли сигналы,

не сбиваются ли фронты. Или это бред???

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

 

В досе вызывается int 0x0D (irq5 в real mode), мне в линуксе надо делать int 37 (irq5 protected mode) правильно?

И что эта команда делает?, прото передает управление обработчику прерывания и все? Железо никак не трогает?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

За посыл в ядро посмотреть на 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 в ядре их вызывает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Этот самый 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, а можно по конкретнее данную тему, где о ней можно почитать? (если можно и есть, ссылку на статью по данной теме..., я о ней ни малейшего представления не имею и даже ниразу не слышал, кроме этого форума)

Не обижайтесь за повторение, но... Я такого в Линукс не делал.

Но делал нечто похожее, при написании собственного загрузчика.

У меня была 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.

Изменено пользователем amw

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

По поводу int 37 - оно в дос драйвере было... (int 0x0D)

Нужно оно там было для того, чтобы проц запустил обработчик

прерывания, свежеустановленный, наш. В конце обработчика есть

команда записать в порт 20h 0x20 - команда pic1, которая что-то

там делает, чтобы потом можно было снова это прерывание принимать...

 

Но, в недавнем времени ситуация изменилась... При очередном... третьем

или четвертом...

пререписывании драйвера, оно мна начало давать прерывания...

Ведут они себя немножко странно... Пробую и так и сяк и смотрю на них.

Хочу добиться от них стабильности появления, ну и понять все тонкости... :05:

То так ее инициализирую, то так... Смотрю на поведение...

 

Int не использую, и так генерит...

Всем БОЛЬШОЕ спасибо за помощь и внимание :) .

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...