что такое usb хост контроллер
Как технология USB over IP позволила людям забыть о расстоянии
Источник изображения
Сегодня быстрым ростом количества устройств сети Интернет и интернета вещей уже никого не удивишь. Существует множество различных протоколов и технологий, на которых основана обработка и обмен информацией между устройствами и, собственно, сама связь этих устройств.
Некоторые технологии являются своеобразными канонами: используются уже не один десяток лет и постоянно совершенствуются. А есть и такие, которые либо уже вымерли, либо родились, но так и не попали в массы ввиду своего несовершенства, низкой релевантности в отношении требований рынка и прочего.
В этой статье речь пойдет о технологии, не относящейся ни к одной, ни к другой группе — USB over IP. Без нее компьютерные сети существовали бы без особых проблем, но она способна значительно упростить работу и снизить затраты на эксплуатацию у крупных предприятий, небольших организаций и даже обычных пользователей. К примеру, с помощью нее можно пробросить аппаратный USB-ключ защиты ПО внутрь облачной платформы или облака на базе VMware и использовать его так, словно он установлен на локальной машине. Но обо всем по порядку.
История появления технологии USB over IP
Сложно сказать, когда именно появилась технология проброса USB-девайсов через сеть в том виде, в каком ее используют сейчас. Вероятнее всего, с развитием возможностей программных компонентов Linux, ростом потребностей рынка и изобретательности энтузиастов.
В наши дни существуют два популярных инструмента для трассировки USB-устройств: usbip и usbip-win. Оба нацелены на совместное использование USB-устройств через IP-сеть за счет обработки USB I/O сообщений, их инкапсуляции в TCP/IP и последующей передачи между устройствами сети типа «клиент-сервер». В такой схеме устройства подключаются к серверу, и на нем же запускается необходимый демон.
На машине клиента, как правило, запускается любое приложение, которое не умеет работать с сетью, зато прекрасно справляется с USB-девайсами. Технология проброса как раз позволяет эмулировать локальное подключение USB-устройств на клиентской машине.
Кому это интересно и где применяется
Преимущества сетевого проброса USB-устройств:
Используемые технологии и оборудование
Способ обмена информацией у локальных и удаленных устройств отличается лишь тем, что для удаленных девайсов будет использоваться виртуальный драйвер шины: набор инструкций и данных, осуществляющий преобразование логической информации или данных в физические сигналы.
Подключение локальных и удаленных устройств
Когда приложения отправляют запрос на конечное устройство, USB PDD (USB Personal Device Driver) преобразует запросы ввода-вывода в серию команд понятных для USB, а затем отправляет их через драйвер шины (связующее звено между драйвером устройства и конечным устройством) в виде блоков USB-запросов на конечное устройство.
Способы проброса аппаратных ключей
Персональный драйвер устройства (PDD), как ни странно, отвечает за управление отдельными USB-устройствами. PDD отправляет запросы в виде специальных блоков запросов URB (USB Request Block), которыми он обменивается данными с ядром USB (USB Core) — отдельной подсистемой внутри ОС, выполняющей роль поддержки USB-устройств и контроллеров.
Модель обмена данными между USB-устройствами и конечным пользователем
Для реализации проброса протокола USB через IP-сеть была разработана сущность, называемая виртуальным интерфейсом хост-контроллера, или Virtual Host Controller Interface (VHCI). VHCI относится к виртуальному контроллеру и способен экспортировать виртуальные USB-устройства, не поддерживаемые физическими устройствами. В Linux контроллеры VHCI используются для доступа к USB-устройствам с удаленных машин, подключенных по уже известному нам протоколу USBIP.
VHCI является эквивалентом драйвера хост-контроллера (HCD) и отвечает за обработку URB-запросов. И VHCI, и HCD отвечают за обработку URB-запросов, полученных от ядра, и делят их на более простые запросы, именуемые Transfer Descriptions (дескрипторы передачи TD) для их дальнейшей передачи на хост-контроллер интерфейса, он же USB-контроллер (Host Controller Interface HCI). Данный интерфейс работает на уровне физических регистровых передач и обеспечивает коммуникацию с периферийными устройствами, подключенными к USB.
Теперь о том, как USB попадает в сеть. Блок запросов URB преобразуется в блок запроса USB / IP драйвером VHCI и отправляется на удаленный компьютер. Драйвер заглушки также добавлен как новый тип USB PDD. Драйвер-заглушка отвечает за декодирование входящих USB / IP-пакетов с удаленных машин, извлечение URB и последующую отправку их на локальные USB-устройства.
Модуль ядра vhci-hcd — это только виртуальный хост-контроллер, к которому вы можете подключить виртуальные устройства.
Как это устроено в Selectel
Рассмотрим работу с USB-концентратором на примере устройства DistKontrolUSB-16. Для того, чтобы пробросить USB-устройство с порта концентратора, необходимо:
Заключение
Описанная технология способна обеспечить необходимую масштабируемость и гибкость в современной, постоянно изменяющейся среде. Проброс USB-устройств через сеть также обеспечивает надежность за счет ограничения физического доступа к устройствам.
Отсутствует необходимость перемещать оборудование, а безопасность сети повышается за счет возможности использования алгоритмов шифрования и настройки прав доступа. Доступна планировка сценариев для каждого отдельно взятого устройства.
Снижение рисков и затрат на обслуживание, удобство совместного использования ресурсов между рабочими станциями — все это делает технологию usbip конкурентоспособной в отношении безопасной авторизации и передачи данных (с TOTP/HOTP, OCRA) и применимой для решения широкого спектра задач IT.
EHCI по-людски на русском языке
Введение
Всех приветствую. Сегодня хочу поделиться опытом и всё-таки по-моему внятно объяснить про такой, на первый взгляд, простой стандарт для USB 2.0 хост-контроллера.
Изначально можно представить себе что USB 2.0 порт — это всего лишь 4 пина, по двум из которых просто передаются данные(Как, к примеру, COM-порт), но самом деле всё не так, и даже совсем наоборот. USB-контроллер в принципе не даёт нам возможности передавать данные как через обычный COM-порт. EHCI — довольно замысловатый стандарт, который позволяет обеспечить надежную и быструю передачу данных от софта до самого девайса, и в обратную сторону.
Возможно, вам пригодиться эта статья, если, к примеру, вы не имеете достаточных навыков написания драйверов и чтение документации к хардвейру. Простой пример: хотите написать свою ОС для мини-ПК, дабы какая-нибудь винда или очередной дистрибутив линукса не загружали железо, и вы использовали всю его мощь исключительно в своих целях.
Что такое EHCI
Что же, давайте начнем. EHCI — Enhanced Host Controller Interface, предназначен для передачи данных и управляющих запросов USB-устройствам, и в другую сторону, а в 99% случаев — является связующим звеном, между каким-либо софтом и физическим устройством. EHCI работает как PCI-устройство, а соответственно использует MMIO(Memory-Mapped-IO) для управления контроллером(да-да, я знаю, что некоторые PCI-девайсы используют порты, но тут я всё обобщил). В документации от Intel описан лишь принцип работы, и никаких намеков на алгоритмы, написанные хотя бы на псевдокоде, нет вовсе. EHCI имеет 2 типа MMIO-регистров: Capability и Operational. Первые служат для получения характеристик контроллера, вторые же — для его управления. Собственно, прикреплю саму суть связи софта и EHCI контроллера:
Каждый EHCI контроллер имеет несколько портов, каждому из которых могут быть подключены какие-либо USB-устройства. Так же, прошу заметить, что EHCI является улучшенной версией UHCI, который так же был разработан Intel на несколько годов раньше. Для обратной совместимости любой UHCI/OHCI контроллер, который имеет версию ниже, чем EHCI, будет компаньоном к EHCI. К примеру, у вас есть USB-клавиатура(А большинство клавиатур года так до сих пор были именно такими), которая работает на USB 1.1(заметим, что максимальная скорость работы USB 1.1 — 12 мегабит в секунду, а FullSpeed USB 2.0 имеет пропускную способность аж в 480 мбит/сек), а у Вас имеется компьютер с USB 2.0 портом, при подключении клавиатуры к компьютеру хост-контроллер EHCI как ни как будет работать с USB 1.1. Данная модель показана на следующей схеме:
Так же на будущее хочу сразу предупредить, что Ваш драйвер может работать не правильно из-за такой вот нелепой ситуации: вы инициализировали UHCI, а после чего EHCI, при этом добавили два одинаковых устройства, поставили в регистр порта бит Port Owner Control, после чего UHCI перестал работать, из-за того, что EHCI автоматически перетягивает порт на себя, а порт на UHCI перестаёт откликаться, эту ситуацию надо отслеживать.
Так же, давайте рассмотрим схему, показывающую саму архитектуру EHCI:
Справа написано про очереди — о них чуть позже.
Регистры EHCI контроллера
Для начала хочется еще раз уточнить, что через данные регистры вы будете управлять вашим устройством, поэтому они очень важны — да и без них программирование EHCI невозможно.
Для начала вам надо получить адрес MMIO, который выдан данному контроллеру, по смещению +0x10 будет лежать адрес наших долгожданных регистров. Есть одно но: сначала идут Capability регистры, а только после них — Operational, поэтому по смещению 0(от предыдущего адреса, который мы получили по смещению 0x10 относительно начала MMIO нашего EHCI) лежит один байт — длина Capability-регистров.
Capability регистры
По смещению 2 лежит регистр HCIVERSION — номер ревизии данного HC, который занимает 2 байта и содержит BCD версию ревизии (что такое BCD можно узнать из википедии).
По смещению +4 лежит регистр HCSPARAMS, его размер — 2 слова, он содержит структурные параметры устройства и его биты показывают следующее:
Operation регистры
По смещению 0 лежит регистр USBCMD — командный регистр контроллера, его биты означают следующее:
По смещению +8 лежит регистр USBINTR — регистр включения прерываний
Чтобы долго не писать, и тем более, Вам долго не читать, значения битов данного регистра можно посмотреть в спецификации, ссылка на неё будет оставлена внизу. Сюда я просто записываю 0, т.к. абсолютно не имею желания писать обработчики, мапить прерывания и т.п., так что это я считаю почти что абсолютно бессмысленным.
По смещению +12(0x0C) лежит регистр FRINDEX, в котором просто лежит текущий номер фрейма, при чем, хочу заметить, что последние 4 бита показывают номер микро-фрейма, в старшие 28 — номер фрейма (так же значение не обязательно меньше размера frameList’а, если вам нужен индекс — лучше брать его с маской 0x3FF(или же 0x1FF, и т.п.).
Регистр CTRLDSSEGMENT лежит по смещению +0x10, он показывает хост-контроллеру старшие 32 бита адреса листа фреймов.
Регистр PERIODICLISTBASE имеет смещение +0x14, в него вы можете положить младшие 32 бита листа фреймов, заметим, что адрес должен быть выравнен по размеру страницы памяти (4096).
Регистр ASYNCLISTADDR имеет смещение +0x18, в него вы можете положить адрес асинхронной очереди, заметим, что он должен быть выравнен по границе 32 байта, при этом должен находиться в первых четырех гигабайтах физической памяти.
Регистр CONFIGFLAG показывает, настроено ли устройство. Вы должны выставить бит 0 после завершения настройки устройства, он имеет смещение +0x40.
Перейдем к регистрам портов. Каждый порт имеет свой командно-статусный регистр, каждый регистр порта располагается со смещением +0x44 + (PortNumber — 1)*4, его биты значат следующее:
Структуры передачи данных и запросов
Организация структуры для обработки запросов включает в себя очередь и трансфер дескрипторы(TDs).
На данный момент мы рассмотрим только 3 структуры.
Последовательный список
Последовательный(Периодичный, Pereodic) список устроен следующим образом:
Как видно на схеме, обработка начинается с получения нужного фрейма из фрейм листа, каждый его элемент занимает 4 байта и имеет следующую структуру:
Как видно на картинке, адрес очереди/трансфер дескриптора выровнен по границе 32 байта, бит 0 означает то, что хост-контроллер не будет обрабатывать данный элемент, биты 3:1 показывают тип того, что будет обрабатывать хост-контроллер: 0 — изосинхронный TD(iTD), 1 — очередь, 2 и 3 в данной статье я рассматривать не буду.
Асинхронная очередь
Хост контроллер обрабатывает данную очередь только тогда, когда фрейм последовательный пустой, либо хост-контроллер обработал весь последовательный список.
Асинхронная очередь представляет собой указатель на очередь, где содержатся другие очереди, которые нуждаются в обработке. Схема:
qTD(Queue Element Transfer Descriptor)
Данный TD имеет следующую структуру:
Next qTD Pointer — указатель на продолжение очереди для обработки(для Horizontal Execution), бит 0 Next qTD Pointer’а показывает, то, что дальше нет еще одной очереди.
qTD Token — токен TD, показывает параметры передачи данных:
Голова очереди
Голова очереди(Queue Head) имеет следующую структуру:
Queue Head Horizontal Link Pointer — указатель на следующую очередь, биты 2:1 имеют следующие значения в зависимости от типа очереди:
Endpoint Capabilities/Characteristics — характеристики очереди:
Переходим к самому интересному.
Драйвер EHCI
Начнем с того, какие запросы может выполнять EHCI. Есть 2 типа запросов: Control — а-ля команд, и Bulk — к конечным точкам, для обмена данными, к примеру, абсолютное большинство флешек(USB MassStorage) использует тип передачи данных Bulk/Bulk/Bulk. Мышь и клавиатура для передачи данных тоже используют Bulk — запросы.
Инициализируем EHCI и настраиваем асинхронную и последовательные очереди:
Собственно, код для сброса порта в изначальное состояние:
Control-запрос к устройству:
Код обработки очереди:
И теперь запрос к конечной точке(Bulk-запрос)
Думаю, что тема достаточно интересная, в интернете на русском документаций, описаний и статей на эту тему почти нет, а если есть — очень размыто. Если интересна тема работы с железом и разработки ОС, то есть много чего рассказать.
Два в одном: USB хост и составное USB устройство
Не так давно, была опубликована статья «Пастильда — открытый аппаратный менеджер паролей». Так как данный проект является открытым, то мы решили, что будет интересно, если мы будем писать небольшие заметки о процессе проектирования, о задачах, которые перед нами стоят и о трудностях, с которыми мы сталкиваемся.
Реализация USB хоста
Итак, во-первых мне нужно было реализовать на устройстве USB хост, чтобы оно могло распознавать и общаться с подключенной к нему клавиатурой. Так как в работе я использую связку Eclipse + GNU ARM Eclipse + libopencm3, то очень хотелось найти уже что-то готовое и желательно написанное с использованием библиотеки libopencm3. Желание мое было очень жирным, до последнего момента не верила, что мои поиски увенчаются успехом. Однако под конец рабочего дня, проскролив интернет до самого дна, я вдруг наткнулась вот на это. libusbhost? Серьезно? И это был не просто написанный на основе libopencm3 usb хост, он еще и был написан под STM32F4, под тот самый, который мы решили использовать в проекте. В общем, звезды сошлись и радости моей не было предела. Кстати, оказалось, что этот проект создавался как часть libopencm3, однако его так и не добавили в библиотеку.
Как библиотеку, libusbhost я не собирала, просто взяла необходимые мне исходники, написала драйвер для клавиатуры и, в общем-то все, погнали! Но обо всем по-порядку.
По аналогии с usbh_driver_hid_mouse.[ch], я написала драйвер для клавиатуры (usbh_driver_hid_kbd.[ch]).
Далее был реализован простенький класс, для работы с хостом:
Реализация составного USB устройства
Далее мне нужно было сделать так, чтобы наше устройство отображалось в диспетчере устройств и как клавиатура, и как дисковый накопитель. Тут вся магия в дескрипторах=) В этом документе, в главе 9, подробно описан USB Device Framework. Эту главу нужно очень внимательно прочитать и в соответствии с ней описать дескрипторы устройства. В моем случае получилось следующее:
Для работы с составным устройством был написан класс USB_composite, представленный ниже.
Как правило, функции control_request и set_config должны быть явно описаны для каждого устройства. Однако из этого правила есть исключение: Mass Storage Device. Итак, разберемся с конструктором класса USB_Composite.
Во-первых, мы инициализируем ноги USB OTG FS:
Во-вторых, нам нужно проинициализировать наше составное устройство, зарегистрировать USB_set_config_callback, о котором шла речь выше, и разрешить прерывание:
Так вот. Теперь, когда конструктор класса USB_Composite дописан, можно собрать проект, прошить устройство и увидеть, что «Запоминающее устройство для USB» больше не помечено предупреждением, а во вкладке «Дисковые устройства» можно обнаружить «ThirdPin Pastilda USB Device». И, казалось бы, все хорошо. Но нет=) Проблем стало больше:
1. Зайти на диск невозможно. При попытке сделать это все виснет, умирает, компьютеру очень плохо.
2. Распознавание устройства как дискового занимает более 2-х минут.
Об этих проблемах и о том, как их решить без вреда для здоровья написано здесь: USB mass storage device и libopencm3.
И, о, чудо! Никаких пятен=) Теперь все работает. У нас есть USB хост и составное USB устройство. Осталось только объединить их работу.
Объединение хоста и составного устройства
, Пастильда должна перехватить управление и отправить сообщение в ПК как клавиатура, после чего мы возвращаемся в режим трансляции и снова ожидаем комбинацию.
Код, реализующий все это, простой как палка:
, мы будем попадать в однострочное меню, а во флеше будет храниться наша зашифрованная база данных паролей.
Буду рада любым комментариям и пожеланиям.
И, конечно же, ссылка на github.
Поддержка USB в KolibriOS: что внутри? Часть 2: основы работы с хост-контроллерами
Прежде, чем объяснять код поддержки хост-контроллеров, необходимо рассказать о некоторых принципах работы железа, а также об используемых структурах данных. Как я выяснила при написании текста, одна статья обо всём уровне поддержки хост-контроллеров получилась бы слишком большой, поэтому вторая часть цикла — которую вы сейчас читаете — рассказывает о том, что необходимо знать для понимания кода, а описание действий, происходящие в коде, я отложу до следующей части.
Прерывания и потоки
Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару cli / sti без собственно спинлока, на многопроцессорных внутри cli / sti остаётся обычный спинлок. Кроме того, контроллер прерываний во время обработки одного прерывания блокирует остальные с тем же или более низким приоритетом.
По этим двум причинам в KolibriOS обработчики прерываний от хост-контроллеров USB передают основную часть работы в выделенный под USB поток ядра, а сами ограничиваются сообщением хост-контроллеру «спасибо, сигнал принят». Сам USB-поток имеет наивысший приоритет, чтобы задумавшиеся пользовательские приложения не мешали обработке. Все функции вышележащих уровней, которые вызываются из уровня поддержки хост-контроллера, работают в контексте потока USB и, как следствие, вполне могут использовать примитивы синхронизации. Приятным побочным эффектом является автоматическая сериализация вызовов: ни обработчик завершения второй передачи из очереди канала, ни функция DeviceDisconnected не будут вызваны, пока не закончит работу обработчик завершения первой передачи из очереди канала, что есть логичное требование к API.
Поток USB также иногда просыпается для обработки событий, отложенных по времени. Пример, о котором я позже расскажу подробнее: после события подключения устройства нужно выждать 100 миллисекунд перед дальнейшей обработкой. В этом случае поток проснётся при обнаружении подключения устройства и запланирует следующее пробуждение через 100 миллисекунд, уже не связанное с пробуждением из-за прерывания.
Структуры данных
В EHCI единица планирования — микрофрейм, который в 8 раз меньше фрейма. Тем не менее, прогулки по спискам каналов по-прежнему руководствуются номером фрейма. Поэтому в каждом канале прерываний есть битовая маска на 8 бит, в которой каждый бит соответствует одному микрофрейму внутри фрейма, нулевое значение бита приводит к немедленному продолжению прогулки по ссылкам. В некоторых каналах таких масок даже две, не пересекающихся по единичным битам, но об этом позже.
Поддержка изохронных передач находится на стадии разработки, поэтому пока я скажу только несколько слов про аппаратную часть. В OHCI изохронные передачи адресуются аналогично остальным: в ohci_pipe есть бит, отвечающий за формат структур данных передачи, изохронные и остальные используют разный формат. В UHCI и EHCI структуры данных для изохронных каналов как таковой нет, а структуры изохронных передач вставляются в таблицу адресов наравне со структурами каналов прерываний. Чтобы контроллер мог понять, указывает ли адрес на канал или на изохронную передачу (которых на самом деле есть два разных типа), два бита адреса отводятся под тип структуры, которая по этому адресу находится. Как следствие, число n для UHCI и EHCI равно 10, но не для поддержки интервалов опроса в секунду с лишним, а для того, чтобы после обработки фрагмента изохронной передачи у софта была секунда на запрос следующего фрагмента. В OHCI n=5.
Передачи и транзакции
Хотя протоколы архитектуры USB ниже передач почти неинтересны, но есть некоторые вещи, которые о них знать всё же необходимо при реализации уровней ниже уровня драйверов.
Размер передачи по шине USB практически неограничен; чтобы одно устройство не занимало шину слишком надолго, передачи разбиваются на транзакции. За одну транзакцию передаётся очередной фрагмент данных ограниченной длины. Максимальная длина транзакции — одна из характеристик канала. Для одного этапа передачи (я напомню, что управляющие передачи состоят из двух или трёх этапов, а остальные — из одного этапа) все транзакции, кроме последней, имеют максимальный размер; последняя транзакция передаёт оставшиеся данные и может быть короче остальных.
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, но и поддержку хабов.