Обслуживание периферии в коде модулей ядра

Часть 48. Анализ оборудования

Comments

Серия контента:

Этот контент является частью # из серии # статей: Обслуживание периферии в коде модулей ядра

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Обслуживание периферии в коде модулей ядра

Следите за выходом новых статей этой серии.

Начиная с этой статьи мы возвращаемся к вопросам, уже изученным в первом цикле "Разработка модулей ядра Linux", чтобы взглянуть на них с другой точки зрения. Если ранее мы изучали различные аспекты реализации драйверов устройств с точки зрения ядра Linux, то в данном мини-цикле мы сосредоточимся на том, как в коде драйвера реализовать поддержку конкретного аппаратного изделия.

Рассмотрение поддержки аппаратных устройств в коде драйвера — это довольно сложная задача, так как существует огромное количество аппаратных устройств, и все они чрезвычайно разнородны, хотя и обладают какой-то спецификой, связанной с их родом применения. Тем не менее можно выделить несколько ограниченных сфер рассмотрения, общих для всего разнообразия аппаратных устройств и необходимых для успешной реализации драйверов:

  1. устройства на шине PCI;
  2. устройства на линии USB;
  3. обработка аппаратных прерываний.

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

Стоит ещё раз сказать, что обслуживание некоторых аппаратных расширений, созданных для решения специфических задач, невозможно описать в общем виде. В такой ситуации вам необходимо работать в постоянном контакте с разработчиком устройства для выяснения различных аспектов функционирования устройства. Но, чтобы это сотрудничество было успешным, вам необходимо потратить время на предварительное изучение группы вопросов, показанных выше. Но начнём мы с анализа оборудования - этапа, который должен предшествовать любой работе с аппаратным обеспечением.

Анализ оборудования

Целью такого анализа, выполняемого до начала разработки модуля драйвера, является уточнение специфических параметров оборудования. Результатом анализа, к которому можно будет неоднократно возвращаться в ходе работы над драйвером, должно стать представление о том, как ядро Linux "на самом деле" видит интересующее нас устройство. Полученное представление может существенно отличаться от описания, заявленного разработчиками этого оборудования, и зачастую первой задачей будет конфигурация системы, чтобы она смогла "корректно" увидеть поддерживаемое устройство.

Для этих целей используются команды lspci и lsusb, которые будут подробно рассмотрены в этой и последующих статьях.

Команда lspci перечисляет все устройства, распознанные на внутренней шине обмена PCI:

$ lspci 
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS,
        943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
        943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
        943/940GML Express Integrated Graphics Controller (rev 03)
...

Для каждого устройства указываются его производитель (Intel Corporation) и модель этого устройства в терминологии производителя (943/940GML Express Integrated Graphics Controller). Зачастую при работе с драйвером нас будут интересовать не текстовые описания производителя и модели, а их численные коды, что для того же набора устройств выглядит так:

$ lspci -n 
00:00.0 0600: 8086:27a0 (rev 03) 
00:02.0 0300: 8086:27a2 (rev 03) 
00:02.1 0380: 8086:27a6 (rev 03) 
...

Первый параметр (численный индекс производителя) называют VID (Vendor ID), а второй — PID (Product ID) или DID (Device ID). Мы ещё неоднократно будем о них говорить. Также довольно часто требуется выполнить диагностику устройств PCI по иерархии их подключения, как показано ниже.

$ lspci -t 
-[0000:00]-+-00.0 
           +-02.0 
           +-02.1 
           +-1b.0 
           +-1c.0-[08]----00.0 
           +-1d.0 
           +-1d.1 
           +-1d.2 
           +-1d.3 
           +-1d.7 
           +-1e.0-[02-06]--+-06.0 
           |               +-06.2 
           |               +-06.3 
           |               +-06.4 
           |               \-0e.0 
           +-1f.0 
           +-1f.1 
           \-1f.2

Для того, чтобы больше узнать о возможностях утилиты lspci, можно просто запустить её в недопустимом формате, как показано ниже.

$ lspci --help 
lspci: invalid option -- '-' 
Usage: lspci [<switches>] 
...
Resolving of device ID's to names: 
-n		Show numeric ID's 
-nn		Show both textual and numeric ID's (names & numbers) 
-q		Query the PCI ID database for unknown ID's via DNS 
...

У этой утилиты имеются чрезвычайно интересные опции, например, мы можем запросить диагностику высокой (-v) или самой высокой (-vv) степени детализации для любого устройства:

$ lspci -d14e4:169c -v 
02:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet 
(rev 03) 
        Subsystem: Hewlett-Packard Company Device 30aa 
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 
        Memory at e8110000 (32-bit, non-prefetchable) [size=64K] 
        ...

Другой полезной командой, которой мы будем неоднократно пользоваться при анализе сменных устройств на линиях USB, является утилита lsusb.

$ lsusb 
Bus 001 Device 002: ID 0424:2503 Standard Microsystems Corp. USB 2.0 Hub 
Bus 001 Device 003: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB 
Bus 001 Device 005: ID 046d:080f Logitech, Inc. Webcam C120 
Bus 004 Device 002: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
...

Команда lsusb во многом похожа по своей функциональности на уже рассмотренную команду lspci:

$ lsusb -t 
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M 
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M 
    |__ Port 1: Dev 2, If 0, Class=HID, Driver=usbhid, 1.5M 
    |__ Port 1: Dev 2, If 1, Class=HID, Driver=usbhid, 1.5M 
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M 
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M 
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M 
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M 
        |__ Port 1: Dev 6, If 0, Class='bInterfaceClass 0xe0 not yet handled', 
		Driver=btusb, 12M 
...

Разобраться в деталях информации, выводимой утилитами lspci и lsusb, довольно сложно, но это и не входит в наши планы, так как показанные листинги будут использоваться при разработке аппаратных драйверов, а внутри контекста их содержание быстро станет простым и понятным.

Кроме названных утилит существуют и другие команды для анализа всего оборудования, установленного в системе (начиная с анализа изготовителя и состава BIOS). Но они используются настолько редко, что часто их названия отсутствуют в справочных руководствах, и о них помнят только опытные системные администраторы. Все эти команды чаще всего требуют прав root, кроме того, некоторые из них могут присутствовать в некоторых дистрибутивах Linux по умолчанию, но отсутствовать в других (тогда их можно установить с помощью доступного менеджера программных пакетов). В результате запуска подобных команд выводится большой объём информации, поэтому при их использовании рекомендуется перенаправить поток вывода в текстовый файл для последующего изучения.

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

$ time sudo lshw > lshw.lst
real	0m5.545s 
user	0m5.029s 
sys	0m0.193s 
$ cat > lshw.lst 
notebook.localdomain 
    description: Notebook 
    product: HP Compaq nc6320 (ES527EA#ACB) 
    vendor: Hewlett-Packard 
...

Примечание: Выполнение команды lshw может потребовать довольно много времени, но это не должно смущать.

Ещё несколько полезных команд из этой же группы:

$ lshal 
Dumping 162 device(s) from the Global Device List: 
------------------------------------------------- 
udi = '/org/freedesktop/Hal/devices/computer' 
  info.addons = {'hald-addon-acpi'} (string list) 
...
$ sudo dmidecode
# dmidecode 2.10 
SMBIOS 2.4 present. 
23 structures occupying 1029 bytes. 
Table at 0x000F38EB. 
...

Примечание: Команда dmidecode в своём выводе в том числе содержит подробную информацию о банках памяти, и в какие разъёмы установлены определённые модули оперативной памяти.

Для разработчиков блочных устройств представляет интерес пакет smartctl, имеющийся почти во всех дистрибутивах и предоставляющий детальную информацию по дисковому накопителю.

$ sudo smartctl -A /dev/sda 
smartctl 5.39.1 2010-01-28 r3054 [i386-redhat-linux-gnu] (local build) 
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net 

=== START OF READ SMART DATA SECTION === 
SMART Attributes Data Structure revision number: 16 
Vendor Specific SMART Attributes with Thresholds: 
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      
UPDATED  WHEN_FAILED RAW_VALUE 
  1 Raw_Read_Error_Rate     0x000f   100   100   046    
  Pre-fail  Always       -       49961 
  2 Throughput_Performance  0x0005   100   100   030    
  Pre-fail  Offline      -       15335665 
...

Ещё одна утилита hdparm используется при работе с блочными устройства (USB накопителями или RAM- дисками).

$ sudo hdparm -i /dev/sda 
/dev/sda: 
 Model=WDC WD2500AAKX-001CA0, FwRev=15.01H15, SerialNo=WD-WMAYU0425651 
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } 
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50 
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16 
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168 
...

Заключение

В этой вводной статье были рассмотрены инструменты для анализа оборудования, применяемые в процессе разработки аппаратных драйверов. Все эти (или другие подобные им) инструменты постоянно используются в ходе разработки драйвера аппаратного устройства на предмет контроля текущего соответствия одного (драйвера) другому (устройству). Поэтому прежде, чем переходить к активной фазе программирования драйвера, следует убедится, что у вас уже подготовлен набор подобных инструментов.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=857751
ArticleTitle=Обслуживание периферии в коде модулей ядра: Часть 48. Анализ оборудования
publish-date=02112013