Запись драйвера для моста PCI

Запись драйвера для моста PCI не является простой задачей. Большинству мостов PCI не нужны никакие специальные драйверы, и в целом при разработке аппаратных средств Вас убеждают использовать части моста, соответствующие спецификациям PCI и таким образом не нуждающиеся в специальных драйверах. Это не всегда возможно в определенных граничных случаях, как бы то ни было. Это обычно, потому что или аппаратные средства уже существуют или потому что прозрачный мост не обеспечивает необходимую функциональность.

Этот раздел объясняет, как записать, что драйверы для наиболее распространенных типов программируемого PCI соединяют мостом и объясняют некоторые различия между теми типами мостов и с аппаратной точки зрения и с точки зрения программирования.

Типы мостов PCI

Существует три основных типа мостов PCI: хост-контроллеры PCI, прозрачный PCI соединяет шиной мосты и непрозрачные мосты шины PCI. У каждого из них есть их собственные специальные выпуски.

Запись драйверов для хост-контроллеров

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

Базовый процесс следующие. Хост-контроллер имеет определенные свойства Open Firmware (или для Darwin/x86, эксперт по платформе представляет определенные свойства), которые идентифицируют физический адрес и размер его набора регистров. Необходимо отобразить этот диапазон в виртуальное адресное пространство ядра с помощью IOMemoryMap объект.

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

Следующие методы должны быть реализованы в драйвере хост-контроллера PCI:

start

Получает информацию о мосте (по мере необходимости) и отображает аппаратные средства моста в адресное пространство ядра.

configure

Конфигурирует контроллер с базовым адресом и размером шины PCI.

free

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

ioDeviceMemory

Возвращает указатель типа IODeviceMemory к экземпляру класса, содержащему информацию о базовом адресе и размере пространства памяти шины. Этот указатель создается в start подпрограмма.

firstBusNum

Возвращает первый номер шины PCI, живущий вне этого контроллера.

lastBusNum

Возвращает последний номер шины PCI, живущий вне этого контроллера.

getBridgeSpace

Возвраты IOPCIAddressSpace запись, представляющая мост. Эта запись содержит номер шины, номер устройства, и конфигурация располагает битовое поле с интервалами для самого моста. bits поле, содержащее битовое поле, должно быть установлено в 0 так как это не релевантно за исключением устройств, находящихся на шине PCI.

setConfigSpace

Устанавливает биты конфигурации устройства (устройство управления шиной включают, пространство памяти включают, и т.д.), использование записи к пространству конфигурации PCI, на основе информации, содержавшейся в IOPCIAddressSpace запись (номер шины, номер устройства и битовое поле).

configRead32, configRead16, и configRead8

Чтения 32, 16, или 8 байтов от адреса в пространстве конфигурации PCI.

configWrite32, configWrite16, и configWrite8

Записи 32, 16, или 8 байтов к адресу в пространстве конфигурации PCI.

callPlatformFunction

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

Для получения дополнительной информации необходимо учиться AppleMacRiscPCI драйвер и другие драйверы PCI, доступные от веб-сайта Apple С открытым исходным кодом, который может быть найден в http://www .opensource.apple.com, или контакт Техническая поддержка Разработчика Apple.

Запись драйверов для прозрачных мостов

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

Для простого создания драйвера для несовместимого прозрачного моста необходимо разделить стандартный Apple на подклассы прозрачный драйвер моста и изменить или расширить основной код инициализации. Если Вы делаете это, несомненно установят надлежащие пассивные параметры соответствия или использовать активное соответствие так, чтобы Ваш измененный драйвер соответствовал против только определенного рассматриваемого моста. Иначе, Ваш драйвер мог повредить нормальное функционирование других мостов PCI в системе. Для получения дополнительной информации на пассивном и активном соответствии, посмотрите, Открывают Firmware Matching или читают надлежащие части Основных принципов IOKit.

Запись драйверов для непрозрачных мостов

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

Драйверы для непрозрачных мостов очень специфичны для устройства. Они появляются каждой стороне как единственное устройство PCI, не мост. Никакая сторона не видит устройства на противоположной стороне моста. Они могут, однако, видеть диапазоны адресов, явно отображающиеся и выполняющие основную основанную на прерывании коммуникацию между этими двумя сторонами. Таким образом это возможно, до ограниченного уровня, до управляющих устройств через такой мост, хотя они обычно не используются таким образом.

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

Точно так же эти устройства часто имеют прерывания «дверного звонка» для основной коммуникации. Эти прерывания инициированы компьютером на одной стороне моста и замечены компьютером на другом. Ваш клиентский интерфейс должен отразить это и должен обеспечить доступ как надлежащий.

Во всех других отношениях, однако, непрозрачные мосты ведут себя как нормальные устройства PCI с точки зрения программного обеспечения. Таким образом, если необходимо записать драйвер для непрозрачного моста, необходимо считать Запись Драйвера для Устройства PCI для получения дополнительной информации.

Другие мосты

Существуют много других типов мостов PCI. Большинство из них попадает в одну из этих категорий:

За исключением специальных функций как извлечение и обнаружение устройств, устройства CardBus являются просто устройствами PCI, и мосты CardBus ведут себя как прозрачные мосты. Таким образом необходимо считать Драйверы Записи для Прозрачных Мостов и Записи Драйвера для Устройства PCI для получения общей информации, затем заглянуть IOPCCardFamily от веб-сайта Apple С открытым исходным кодом для CardBus-специфичных расширений.

Другие мосты, такие как те, которые включают ISA или другие шины, выходят за рамки этого документа. Для справки с такими мостами необходимо связаться с Технической поддержкой Разработчика Apple.

Отладка моста PCI

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

Для получения дополнительной информации о создании ядра с ddb поддержка, и для инструкций и уведомления относительно использования отладочных программ gdb и ddb, см. Руководство по программированию Ядра, доступное от Дарвинского раздела веб-сайта документации разработчика Apple, http://developer .apple.com/Documentation.