Драйвер расширяемого хост контроллера что это

Обновлено: 07.07.2024

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

Формально, порты USB 2.0 ещё встречаются на современном железе, но управляются чаще контроллерами версии 3.0, а это значит что без интеграции драйверов в дистрибутив Windows 7 уже не обойтись, ведь семёрка ничего не знает о USB-контроллерах третьего поколения.

Существует несколько специализированных утилит для интеграции драйверов USB 3.0 в установщик Windows 7 от Intel, ASRock, MSI и Gigabyte:

Конечно, можно ещё интегрировать драйвера USB 3.0 вручную, при помощи утилиты DISM или использовать популярную программу для кастомизации дистрибутивов nLite, но зачем усложнять, если всё за вас уже сделали. Если будет интересно, могу рассказать (напишите в комментариях), но полагаю что и этих вариантов будет достаточно.

Лично мне больше по душе варианты от Intel и gigabyte. Сложного тут ничего нет, главное скачайте с сайта Microsoft оригинальный образ Windows 7 (всякие сборки тут могут не прокатить) и по возможности обзаведитесь быстрой флешкой.

Как сделать установочную флешку Windows 7 с USB 3.0 на примере Windows 7 USB 3.0 Creator Utility

Важно! Windows 7 USB 3.0 Creator Utility от Intel работает только на Windows 8.1 и выше.

Ранее на сайте Intel была даже небольшая инструкция по работе с данной утилитой, скачать можно отсюда . Переписываем образ диска Windows 7 (предварительно скачиваем с сайта Microsoft) на флешку с помощью утилиты Rufus (о ней я уже рассказывал подробнее ).

Далее, запустив Windows 7 USB 3.0 Creator Utility остаётся только указать нашу флешку и ждать. Хочу заметить, что на медленных флешках процесс может затянуться на пару часов. Показателем что всё готово, в случае с Windows 7 USB 3.0 Creator Utility будет надпись «SUCCESS!».

Расписывать процесс интеграции драйверов в других утилитах я особого смысла не вижу, от вас требуются минимальные действия в указании где находятся образ диска и флешка на которую записать результат работы. Теперь можно без труда установить Windows 7 с флешки, подключенной к контроллеру usb3.0. Правда в моём случае все усилия были тщетны.

Расширяемый интерфейс хост-контроллера ( xHCI ) - это спецификация компьютерного интерфейса, которая определяет описание хост-контроллера на уровне регистров для универсальной последовательной шины (USB), который может взаимодействовать с устройствами, совместимыми с USB 1.x, 2.0 и 3.x. . Спецификация также называется спецификацией хост-контроллера USB 3.0 .

xHCI улучшает уже существующие архитектуры Open Host Controller Interface (OHCI) и Universal Host Controller Interface (UHCI), что наиболее заметно в обработке более широкого диапазона скоростей в рамках единого стандарта, в более эффективном управлении ресурсами в интересах мобильных хостов с помощью ограниченные ресурсы питания (например, планшеты и сотовые телефоны), а также упрощение поддержки смешивания низкоскоростных и высокоскоростных устройств.

СОДЕРЖАНИЕ

Архитектурные цели

XHCI является радикальным отходом от предыдущих поколений архитектур интерфейса хост-контроллера USB (то есть открытого интерфейса хост-контроллера (OHCI), универсального интерфейса хост-контроллера (UHCI) и расширенного интерфейса хост-контроллера (EHCI)) во многих отношениях. Ниже приведены ключевые цели архитектуры xHCI:

Эффективная работа - мощность в режиме ожидания и производительность лучше, чем у устаревших архитектур хост-контроллеров USB.
Модель программирования на уровне устройства, полностью совместимая с существующей моделью программного обеспечения USB.
Отделите интерфейс хост-контроллера, представленный программному обеспечению, от базовых протоколов USB.
Минимизируйте доступ к памяти хоста, полностью исключив их, когда USB-устройства бездействуют
Устранение записи регистров и минимизация чтения регистров для нормальной передачи данных
Исключите модель "Компаньон-контроллер"
Включите аппаратные режимы переключения при отказе в ситуациях с ограниченными ресурсами системы, чтобы устройства оставались доступными, но, возможно, в менее оптимальной точке мощности / производительности.
Обеспечение возможности для разных рынков дифференцировать возможности оборудования, например, мощность целевого хост-контроллера, производительность и компромиссы для конкретных рынков.
Определите расширяемую архитектуру, которая обеспечивает простой путь для новых спецификаций и технологий USB, таких как интерфейсы с более высокой пропускной способностью, оптическая среда передачи и т. Д., Не требуя определения еще одного интерфейса хост-контроллера USB.

Архитектурные детали

Поддержка всех скоростей

Контроллеры OHCI и UHCI поддерживают только устройства со скоростью USB 1 (1,5 Мбит / с и 12 Мбит / с), а EHCI поддерживает только устройства USB 2 (480 Мбит / с).

Архитектура xHCI была разработана для поддержки всех скоростей USB, включая SuperSpeed (5 Гбит / с) и будущие скорости, в рамках одного стека драйверов.

Энергоэффективность

Когда USB был первоначально разработан в 1995 году, он был нацелен на настольные платформы, чтобы остановить распространение разъемов, которые появлялись на ПК, например, PS / 2 , последовательный порт , параллельный порт , игровой порт и т. важное соображение в то время. С тех пор мобильные платформы стали предпочтительной платформой, а их батареи сделали энергопотребление ключевым фактором. Архитектуры устаревших хост-контроллеров USB (OHCI, UHCI и EHCI) были очень похожи в том, что «расписание» для транзакций, выполняемых на USB, создавалось программным обеспечением в памяти хоста, и аппаратное обеспечение хост-контроллера постоянно считывало расписания, чтобы определить, какие транзакции необходимо запустить на USB и когда, даже если данные не были перемещены. Кроме того, в случае чтения с устройства, устройство опрашивалось каждый интервал расписания, даже если не было данных для чтения.

XHCI исключает расписания транзакций USB на основе памяти хоста, обеспечивая нулевую активность памяти хоста, когда нет перемещения данных USB.
XHCI снижает потребность в периодическом опросе устройств, позволяя устройству USB 3.0 или более поздней версии уведомлять хост-контроллер, когда у него есть данные, доступные для чтения, и перемещает управление опросом устройств USB 2.0 и 1.1, которые используют транзакции прерывания, с управляемого ЦП USB-драйвер к хост-контроллеру USB. Хост-контроллеры EHCI, OHCI и UHCI будут автоматически обрабатывать опрос для ЦП, если нет никаких изменений, которые нужно внести, и если ни одно устройство не имеет никаких прерываний для отправки, но все они полагаются на ЦП, чтобы установить расписание для контроллеров. Если какое-либо USB-устройство, использующее транзакции прерывания, действительно имеет данные для отправки, то хост-контроллер xHCI отправит прерывание, чтобы уведомить ЦП о том, что существует транзакция прерывания USB, которую необходимо обработать. Поскольку ЦП больше не должен управлять опросом шины USB, он может проводить больше времени в состояниях с низким энергопотреблением.
XHCI не требует, чтобы реализации обеспечивали поддержку всех расширенных функций управления питанием USB 2 и 3, включая состояния USB 2 LPM, USB 3 U1 и U2, HERD, LTM, Function Wake и т. Д .; но эти функции необходимы для реализации всех преимуществ xHCI.

Поддержка виртуализации

Унаследованные архитектуры USB-хост-контроллер демонстрируют некоторые серьезные недостатки в применении к виртуализированным средам. Унаследованные интерфейсы хост-контроллер USB определяют относительно простую аппаратную перекачку данных; где критическое состояние, связанное с общим управлением шиной (выделение полосы пропускания, назначение адресов и т. д.), находится в программном обеспечении драйвера хост-контроллера (HCD). Попытка применить стандартный метод виртуализации аппаратного ввода-вывода - репликацию регистров интерфейса ввода-вывода - к устаревшему интерфейсу хост-контроллера USB является проблематичной, поскольку критическое состояние, которым необходимо управлять на виртуальных машинах ( ВМ ), недоступно для оборудования. Архитектура xHCI переносит контроль этого критического состояния на оборудование, позволяя управлять ресурсами USB на всех виртуальных машинах. Функции виртуализации xHCI также обеспечивают:

прямое назначение отдельных USB-устройств (независимо от их расположения в топологии шины) любой виртуальной машине
минимизация взаимодействия между виртуальными машинами во время выполнения
поддержка общего доступа к USB-устройствам
поддержка PCIe SR-IOV (однокорневая виртуализация ввода-вывода )

Упрощенная архитектура драйвера

EHCI использует контроллеры OHCI или UHCI в качестве «сопутствующих контроллеров», где устройства USB 2 управляются через стек EHCI, а логика порта EHCI позволяет маршрутизировать низко- или полноскоростное USB-устройство к порту «сопутствующий» контроллер UHCI или OHCI, в котором низко- или полноскоростные USB-устройства управляются через соответствующий стек UHCI или OHCI. Например, плата хост-контроллера USB 2 PCIe, которая имеет 4 разъема USB «Standard A», обычно представляет для системного программного обеспечения один 4-портовый EHCI и два 2-портовых контроллера OHCI. Когда высокоскоростное USB-устройство подключено к любому из 4 разъемов, управление устройством осуществляется через один из 4 портов корневого концентратора контроллера EHCI. Если низкоскоростное или полноскоростное USB-устройство подключено к разъемам 1 или 2, оно будет направлено на порты корневого концентратора одного из контроллеров OHCI для управления, а низкоскоростные и полноскоростные USB-устройства подключены к разъемам. 3 или 4 будут направлены на порты корневого концентратора другого контроллера OHCI. Зависимость EHCI от отдельных хост-контроллеров для высокоскоростных USB-устройств и группы низкоскоростных и полноскоростных USB-устройств приводит к сложным взаимодействиям и зависимостям между драйверами EHCI и OHCI / UHCI.

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

Поддержка потоковой передачи

Поддержка Streams была добавлена в спецификацию USB 3.0 SuperSpeed, в первую очередь для обеспечения высокопроизводительных операций хранения через USB. Обычно между оконечной точкой USB и буфером в системной памяти существует соотношение 1: 1, и главный контроллер несет полную ответственность за управление всеми передачами данных. Потоки изменили эту парадигму, предоставив ассоциацию «конечная точка для буфера» «1 ко многим» и позволив устройству указывать хост-контроллеру, какой буфер перемещать. Передачи данных USB, связанные с конечной точкой USB Stream, планируются xHCI так же, как и любая другая массовая конечная точка, однако буфер данных, связанный с передачей, определяется устройством.

Поддержка xHCI USB Stream позволяет связать до 64 КБ буферов с одной конечной точкой.
Поддержка протокола xHCI Streams позволяет USB-устройству выбирать, какой буфер xHCI будет передавать при планировании конечной точки.

Масштабируемость

Архитектура xHCI была разработана с учетом высокой масштабируемости, способной поддерживать от 1 до 255 USB-устройств и от 1 до 255 портов корневого концентратора. Поскольку каждому USB-устройству разрешено определять до 31 конечной точки, xHCI, поддерживающий 255 устройств, должен поддерживать 7 906 отдельных конечных точек. Классически каждый буфер памяти, связанный с конечной точкой, описывается очередью блоков физической памяти, где очереди требуются указатель заголовка, указатель хвоста, длина и другие регистры для определения своего состояния. Существует много способов определить состояние очереди, однако, если предположить, что для каждой очереди будет 32 байта регистрового пространства, то для поддержки 7 906 очередей потребуется почти 256 КБ. Обычно к системе одновременно подключается лишь небольшое количество USB-устройств, и в среднем USB-устройство поддерживает 3-4 конечных точки, из которых только подмножество конечных точек активны одновременно. XHCI поддерживает состояние очереди в системной памяти как структуры данных контекста конечной точки. Контексты спроектированы таким образом, что они могут кэшироваться с помощью xHCI и «выгружаться» на страницы и выходить в зависимости от активности конечной точки. Таким образом, поставщик может масштабировать свое внутреннее пространство кэша контекста конечной точки xHCI и ресурсы в соответствии с практическими моделями использования, ожидаемыми для их продуктов, а не с архитектурными ограничениями, которые они поддерживают. В идеале пространство внутреннего кэша выбирается таким образом, чтобы при нормальных условиях использования не было подкачки контекста с помощью xHCI. Также активность оконечных устройств USB имеет тенденцию быть нестабильной. То есть в любой момент времени большое количество конечных точек может быть готово к перемещению данных, однако только подмножество активно перемещает данные. Например, конечная точка прерывания IN мыши может не передавать данные в течение нескольких часов, если пользователь находится вне своего рабочего места. Алгоритмы производителя xHCI могут обнаружить это условие и сделать эту конечную точку кандидатом для пейджинга, если другие конечные точки станут заняты.

Архитектура xHCI допускает большие максимальные значения для количества поддерживаемых USB-устройств, портов, векторов прерываний и т. Д., Однако реализация должна определять только количество, необходимое для удовлетворения ее маркетинговых требований. Например, поставщик может ограничить количество USB-устройств, которые он поддерживает для реализации xHCI на планшете, до 16 устройств.
В дальнейшем поставщик может воспользоваться преимуществами архитектурных функций xHCI для масштабирования своих внутренних ресурсов в соответствии со своими целевыми моделями использования. Например, если посредством тестирования удобства использования поставщик определяет, что 95% пользователей планшетов никогда не будут подключать более 4 устройств USB, а каждое устройство USB обычно определяет 4 конечные точки (или меньше), то внутреннее кэширование для 16 контекстов конечных точек обеспечит это при нормальных условиях. При этом не будет активности системной памяти из-за разбивки на страницы контекста конечной точки.

История

Спецификация Open Host Controller Interface (OHCI) была определена консорциумом компаний (Compaq, Microsoft и National Semiconductor) как открытая спецификация для поддержки устройств USB 1.0. Универсальный интерфейс хост-контроллера (UHCI) относится к спецификации, которую Intel изначально определила как собственный интерфейс для поддержки устройств USB 1.0. Спецификация UHCI в конечном итоге была обнародована, но только после того, как остальная часть отрасли приняла спецификацию OHCI.

Спецификация EHCI была определена Intel для поддержки устройств USB 2.0. Архитектура EHCI была смоделирована по образцу контроллеров UHCI и OHCI, которым требовалось программное обеспечение для построения расписаний транзакций USB в памяти, а также для управления полосой пропускания и распределением адресов. Чтобы избежать избыточных усилий отрасли по определению открытой версии интерфейса хост-контроллера USB 2.0, Intel сделала спецификацию EHCI доступной для отрасли без лицензионных сборов.

Модель лицензирования EHCI была продолжена для спецификации Intel xHCI, однако со значительным расширением вклада отрасли. Более 100 компаний внесли свой вклад в спецификацию xHCI. USB реализаторы Forum (USB-IF) также финансировали набор xHCI соответствия тестов , чтобы максимизировать совместимость различных реализаций xHCI.

Контроллеры xHCI 1.0 поставляются с декабря 2009 года. Ядра Linux с 2009 года содержат драйверы xHCI, но для более старых ядер драйверы доступны в Интернете. Драйверы Windows для XP, Vista и Windows 7 доступны у соответствующих поставщиков xHCI. Драйверы xHCI для встроенных систем доступны у MCCI , Jungo и других поставщиков программного обеспечения. IP-блоки xHCI также доступны от нескольких поставщиков для настройки в средах SOC. Контроллеры и устройства xHCI 1.1 начали поставляться в 2015 году.

История версий

В спецификации xHCI используются файлы «исправлений» для определения обновлений и уточнений к конкретному выпуску. Изменения в файлах исправлений накапливаются в каждом выпуске. Обратитесь к связанным файлам исправлений для получения подробной информации о конкретных изменениях. Большинство изменений, определенных в файлах исправлений xHCI, - это уточнения, грамматические или орфографические исправления, дополнительные перекрестные ссылки и т. Д., Которые не влияют на реализацию драйвера. Изменения, которые определены как архитектурные, используют флаг Capability, чтобы определить, поддерживается ли конкретная функция реализацией xHCI, и флаг Enable, чтобы включить эту функцию.

Пререлизы

Спецификация xHCI развивалась до нескольких версий до официального выпуска в 2010 году:

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

Прерывания и потоки

Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару cli / sti без собственно спинлока, на многопроцессорных внутри cli / sti остаётся обычный спинлок. Кроме того, контроллер прерываний во время обработки одного прерывания блокирует остальные с тем же или более низким приоритетом.

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

Структуры данных

Для уровня поддержки хост-контроллеров важны следующие структуры: структура данных контроллера *_controller , структура данных канала *_pipe , структура данных неизохронной передачи *_gtd . Каждая из них состоит из двух частей: специфичной для хост-контроллера *hci_* и общей для всех контроллеров usb_* . Хост-контроллер требует выравнивания своих структур. Данные контроллера используют выравнивание на границу страницы, то есть 1000h байт. Выравнивание прочих данных разное для разных контроллеров.

В KolibriOS обе части каждой структуры располагаются в памяти последовательно. Память под обе структуры выделяется одним приёмом с учётом требуемого выравнивания. Первой в памяти идёт часть, отвечающая за общение с хост-контроллером, чтобы обеспечить выравнивание. Для адресации обеих частей используется один указатель, указывающий на границу между частями; по отрицательным смещениям находятся данные *hci_* , по неотрицательным — данные usb_* . Указатель на usb_controller постоянно размещается в регистре esi . Хэндл канала представляет собой указатель на usb_pipe ; одним из полей usb_pipe является указатель на соответствующий usb_controller .

Код, выделяющий память под структуры, должен знать размеры обеих структур и требуемое выравнивание. Для *_controller используется постраничный аллокатор, автоматически гарантирующий выравнивание на границу страницы. Аллокатор вызывается кодом, ответственным за usb_controller , размер структуры *hci_controller берётся из usb_hardware_func.DataSize ; как я упоминала в общем обзоре, usb_hardware_func описывает вещи, специфичные для хост-контроллера, остальному коду.
Для *_pipe и *_gtd выделять по странице на каждый экземпляр было бы крайне расточительно, а использовать общую кучу ядра для малых блоков — неудобно из-за требований выравнивания. Поэтому для них код использует аллокатор блоков фиксированного размера, который, выделив страницу, нарезает её на блоки заданного размера и отдаёт их один за другим. Если выделяемый размер кратен, например, 16 байтам, то все выделяемые блоки будут иметь адрес, кратный 16. Здесь аллокатору для каждого размера нужны отдельные данные; чтобы не включать их все в структуру usb_hardware_func , последняя содержит функции выделения/освобождения AllocPipe / FreePipe для пары структур *_pipe и AllocTD / FreeTD для пары структур *_gtd .

Хост-контроллер должен знать физические адреса всех структур, чтобы работать с ними. Адрес структуры *hci_controller заносится в ходе инициализации контроллера. Адреса структур данных неизохронных передач собраны в односвязный список с физическим адресом первого элемента внутри *hci_pipe и физическим адресом каждого следующего элемента внутри *hci_gtd .

Каналы сгруппированы в несколько списков. Внутри каждого списка есть три связи: физический адрес следующего канала для железа, виртуальные адреса следующего и предыдущего каналов для софта. Один список состоит из всех каналов для управляющих передач. Другой список состоит из всех каналов для передач массивов данных.
Списки каналов прерываний организованы в двоичное дерево так, как показано на рисунке, где кружки обозначают списки каналов прерываний, а стрелки — физические адреса следующих элементов. Хост-контроллер начинает каждую единицу времени (фрейм для UHCI и OHCI, микрофрейм для EHCI) с того, что берёт младшие n бит номера фрейма (именно фрейма, даже если это EHCI), берёт соответствующий элемент таблицы адресов, являющейся частью *hci_controller , и начинает идти по ссылкам на следующий элемент. Первый список, таким образом, будет обрабатываться один раз каждые 2 n миллисекунд. Дальше пары ссылок «склеиваются»: на следующий список ведёт две ссылки так, чтобы следующий список получал внимание контроллера дважды за полный цикл по таблице адресов, один раз каждые 2 n-1 миллисекунд. В конце располагается список, элементы которого обрабатываются каждую миллисекунду. Такая организация каналов прерываний позволяет реализовать каналы с интервалом обработки, выражающимся в миллисекундах степенью двойки. Спецификация USB разрешает делать реальный интервал опроса меньше запрошенного.

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

Поддержка изохронных передач находится на стадии разработки, поэтому пока я скажу только несколько слов про аппаратную часть. В OHCI изохронные передачи адресуются аналогично остальным: в ohci_pipe есть бит, отвечающий за формат структур данных передачи, изохронные и остальные используют разный формат. В UHCI и EHCI структуры данных для изохронных каналов как таковой нет, а структуры изохронных передач вставляются в таблицу адресов наравне со структурами каналов прерываний. Чтобы контроллер мог понять, указывает ли адрес на канал или на изохронную передачу (которых на самом деле есть два разных типа), два бита адреса отводятся под тип структуры, которая по этому адресу находится. Как следствие, число n для UHCI и EHCI равно 10, но не для поддержки интервалов опроса в секунду с лишним, а для того, чтобы после обработки фрагмента изохронной передачи у софта была секунда на запрос следующего фрагмента. В OHCI n=5.

Передачи и транзакции

Хотя протоколы архитектуры USB ниже передач почти неинтересны, но есть некоторые вещи, которые о них знать всё же необходимо при реализации уровней ниже уровня драйверов.
Размер передачи по шине USB практически неограничен; чтобы одно устройство не занимало шину слишком надолго, передачи разбиваются на транзакции. За одну транзакцию передаётся очередной фрагмент данных ограниченной длины. Максимальная длина транзакции — одна из характеристик канала. Для одного этапа передачи (я напомню, что управляющие передачи состоят из двух или трёх этапов, а остальные — из одного этапа) все транзакции, кроме последней, имеют максимальный размер; последняя транзакция передаёт оставшиеся данные и может быть короче остальных.

Размер данных, которые может описать одна пара структур *_gtd , также ограничен. Если все данные не умещаются в одну *_gtd , передачу нужно разбивать на несколько частей. Места разбиения нужно выбирать так, чтобы с точки зрения устройства происходящее оставалось одной передачей, то есть размер всех частей, кроме последней, должен делиться на максимальный размер транзакции.

UHCI — хронологически первый интерфейс, созданный Intel; в UHCI упор делается на простоту аппаратной реализации. Как следствие, UHCI-контроллер ничего не знает про передачи, а одна структура uhci_gtd описывает одну транзакцию. Для больших передач это приводит к большим накладным расходам на отдельную память для всех транзакций.
В OHCI и EHCI контроллер уже умеет самостоятельно разбивать длинные передачи на транзакции, здесь ограничения слабее. В ohci_gtd есть два поля для двух страниц данных, в лучшем случае получается 2000h байт, в худшем (если данные начинаются с адреса xxxxxFFFh ) — 1001h байт = 4 килобайта + 1 байт. В ehci_gtd помещаются уже пять страниц, что в худшем случае даёт ограничение 4001h байт. Если данных больше, то передачу по-прежнему нужно разбивать на несколько фрагментов.

В USB2 появились расщеплённые транзакции (split transactions). Спецификация USB2 добавила новую скорость передачи данных 480 мегабит/с (high-speed, HS), но по-прежнему поддерживает две скорости USB1, 12 мегабит/с (full-speed, FS) и 1.5 мегабит/с (low-speed, LS). На одной шине USB в каждый момент времени можно общаться только с одним устройством. В USB1 шина, управляемая одним хост-контроллером, была единой, и во время транзакции к LS-устройству она (способная на 12 мегабит/с) работала со скоростью 1.5 мегабит/с. В USB2 аналогичным образом замедлять HS-шину было бы непрактично, поэтому выделяется одна общая шина, которая всегда работает на high-speed, и несколько FS/LS-шин, к которым подключаются FS/LS-устройства. За связь между шинами отвечает хаб, к которому подключено низкоскоростное устройство; спецификация называет соответствующую часть хаба Transaction Translator (TT).

Пока хаб медленно общается с низкоскоростным устройством по низкоскоростной шине, высокоскоростная шина оказывается свободной, причём довольно надолго. Чтобы полученное время можно было использовать с толком, транзакция по HS-шине расщепляется на две: начальную (start-split transaction) и конечную (complete-split transaction).

Детали расщепления несколько различаются для периодических транзакций (передач по прерыванию и изохронных передач) и непериодических (управляющих передач и передач массивов данных). На рисунке выше показана схема происходящего внутри хаба для периодических расщеплённых транзакций. Хорошая новость: для непериодических транзакций дополнительные действия по поддержке минимальны — нужно правильно инициализировать структуру канала и при ошибке HS-шины очищать буфер хаба с данными, за остальным будет следить сам контроллер. Для периодических транзакций всё сложнее. Именно отсюда возникает вторая битовая маска в структуре канала прерываний, которую я ранее упоминала, — для каналов прерываний FS/LS-устройств первая битовая маска отвечает за микрофреймы, в которые нужно инициировать начальную расщеплённую транзакцию, вторая — за микрофреймы, в которые нужно инициировать конечную расщеплённую транзакцию. Отсюда же появляется второй тип изохронных транзакций в EHCI — структуры обычной и расщеплённой изохронных транзакций различаются.

EHCI и компаньоны

При проектировании хост-контроллера для USB2 Intel решила по возможности задействовать уже существующую базу в виде железа UHCI/OHCI и программной поддержки. В корневом хабе EHCI отсутствует Transaction Translator; вместо него каждый порт может быть подключён к контроллеру-компаньону, им может быть UHCI или OHCI. Компаньонов может быть несколько. Пока EHCI-контроллер не инициализирован, все порты подключены к компаньонам; код, умеющий программировать UHCI и OHCI, сможет работать со всеми устройствами и в такой конфигурации, естественно, на скорости USB1. После инициализации EHCI-контроллера каждому порту можно назначить владельца независимо от других. Контроллер, не являющийся владельцем, воспринимает порт в состоянии «нет устройства». Порты, на которых действительно нет устройства, а также порты с HS-устройствами назначаются контроллеру EHCI; порты с низкоскоростными устройствами назначаются контроллеру-компаньону.

Позднее Intel решила, что больше не хочет ставить UHCI рядом с EHCI. Чтобы не переделывать спецификацию и не заставлять всех переписывать драйверы, Intel не стала менять контроллер, но на пути от «настоящих» портов до контроллера поставила «виртуальный» хаб с официальным названием Rate Matching Hub (RMH), а контроллеру оставила только два порта, к одному из которых всегда подключён хаб. Назначение второго порта, к сожалению, мне выяснить не удалось. С программной точки зрения «виртуальный» хаб ничем не отличается от обычного, просто при написании своей реализации следует иметь в виду, что для доступа к устройствам на некоторых конфигурациях придётся реализовать не только поддержку EHCI, но и поддержку хабов.

Решение 1. Включите драйвер расширяемого хост-контроллера USB 3.0

В некоторых случаях драйвер хост-контроллера USB 3.0 может быть отключён. Соответственно, его необходимо активировать:

Щёлкните ПКМ по значку Windows в левом нижнем углу.
В открывшемся меню выберите Диспетчер устройств.
Далее разверните раздел Контроллеры USB и найдите драйверы с пометкой 3.0.
Нажмите по нему ПКМ и выберите Свойства.
Откройте вкладку Драйверы, и кликните на опцию Задействовать.
Обратите внимание, что данный параметр будет доступен, только если драйвер был отключён. В противном случае, ничего делать не надо.
Проверьте таким образом каждый из драйверов с пометкой 3.0 и 3.1.
Затем перезагрузите компьютер.

Решение 2. Обновите USB-драйверы

Снова откройте Диспетчер устройств, как описано выше.
Разверните раздел Контроллеры USB, и кликнув ПКМ по драйверу 3.0, обновите его.
Сделайте то же самое с каждым программным обеспечением с пометкой 3.0 и 3.1.
Если имеются приложения, отмеченные восклицательным знаком в жёлтом треугольнике, их также следует обновить.
По завершении перезагрузите систему.

Решение 3. Подключите ноутбук к розетке

Решение 4. Используйте разные порты подключения

Решение 5. Отключите режим энергосбережения USB через Диспетчер устройств

Откройте Диспетчер устройств и разверните раздел Контроллеры USB.
Нажмите ПКМ по драйверу 3.0/3.1 и выберите Свойства.
Перейдите на вкладку Управление электропитанием.
Снимите галочку с опции Разрешить отключение этого устройства для экономии энергии.
Сделайте то же самое для всех портов 3.0/3.1.

Решение 6. Включите контроллер xHCI в BIOS

Чтобы получить доступ к BIOS, перезагрузите компьютер и постоянно нажимайте F2, F8, F10, Del или другую кнопку на клавиатуре в зависимости от модели вашего устройства (подробнее можно узнать на сайте производителя материнской платы или ноутбука).

Зайдя в BIOS, нужно найти параметр xHCI Mode, он может находиться в разделах Advanced, Devices, Peripherals или подобных. Навигация по настройкам системы осуществляется с помощью клавиш со стрелками. Активируйте мод и перезагрузите компьютер в нормальном режиме.

Читайте также: