Usb host controller что это

Для каждого встроенного чипа ЦП обычно интегрируется один или несколько хост-контроллеров. Каждый хост-контроллер фактически является устройством PCI, которое монтируется на шине PCI. В системе Linux разработчик драйвера должен предоставить хост-контроль Контроллер предоставляет драйвер, а хост-контроллер представлен структурой usb_hcd. Структура определена в /include/linux/usb/hcd.h.

Каждый хост-контроллер USB поставляется с концентратором USB, который называется Root Hub. Этот корневой концентратор может быть подключен к дополнительным концентраторам, а USB-устройства могут быть установлены на каждом концентраторе. Вообще говоря, USB Hub также является устройством USB. Каждый корневой USB-концентратор может напрямую или косвенно подключить 127 устройств

OHCI и UHCI являются стандартами интерфейса USB1.1, в то время как EHCI является стандартом интерфейса, соответствующим USB2.0, а последний xHCI является стандартом интерфейса USB3.0.

OHCI (Open Host Controller Interface) - это стандарт, который поддерживает USB 1.1, но он не только для USB, но также поддерживает некоторые другие интерфейсы, например, он также поддерживает Firewire от Apple (Firewire, IEEE).
1394) интерфейс. По сравнению с UHCI аппаратное обеспечение OHCI является сложным, а аппаратное обеспечение делает больше, поэтому реализовать соответствующую программную задачу относительно просто. В основном используется для не x86 USB, таких как карта расширения, USB-хост управления встроенной платой разработки.
UHCI (Universal Host Controller Interface) - это стандарт интерфейса для USB1.0 и 1.1 под руководством Intel, который не совместим с OHCI. Программные задачи UHCI тяжелы и должны быть более сложными, но вы можете использовать более дешевые и простые аппаратные USB-контроллеры. Intel и VIA используют UHCI, а остальные поставщики оборудования используют OHCI.
EHCI (расширенный интерфейс хост-контроллера) - это стандарт интерфейса USB2.0, возглавляемый Intel. EHCI обеспечивает только высокоскоростные функции USB2.0 и использует UHCI или OHCI для обеспечения поддержки высокоскоростных или низкоскоростных устройств.
xHCI (расширяемый интерфейс хост-контроллера) - это новейший и самый популярный стандарт интерфейса USB 3.0, который значительно улучшил скорость, энергосбережение, виртуализацию и другие аспекты по сравнению с предыдущими тремя. xHCI поддерживает все типы USB-устройств (USB 3.0 SuperSpeed, USB 2.0 с низкой, полной и высокой скоростью, USB 1.1 с низкой и полной скоростью). Целью xHCI является замена предыдущих 3 (UHCI / OHCI / EHCI).

Как следует из названия, хост-контроллер используется для управления связью между устройством USB и процессором. О том, что ЦП будет делать с устройством, сначала будет уведомлять хост-контроллер вместо прямой отправки инструкций на устройство USB. После получения команды ЦП хост-контроллер направит USB-устройство для выполнения соответствующей задачи. Таким образом, после того, как ЦП передает команду хост-контроллеру, ему не нужно заниматься остальной работой, и ЦП переключается на другие вещи.

Хост-контроллер USB должен управляться драйвером хост-контроллера USB для работы. Драйвер хост-контроллера USB представлен как hc_driver. Каждый хост-контроллер в компьютерной системе имеет соответствующую структуру hc_driver, которая определена в /include/linux/usb/hcd.h.

Ниже мы анализируем драйвер хост-контроллера USB, используя usb 3.0 xHCI в качестве примера для объяснения.
xHCI управляется моделью драйвера платформы платформы, а также устройством и драйвером.
Сначала посмотрите на часть устройства
/driver/usb/dwc3/host.c

Вы здесь: Главная USB Хост USB «Расширенный» хост-контроллер — EHC

Регистры EHCI контроллера

Для начала хочется еще раз уточнить, что через данные регистры вы будете управлять вашим устройством, поэтому они очень важны — да и без них программирование EHCI невозможно.

Для начала вам надо получить адрес MMIO, который выдан данному контроллеру, по смещению +0x10 будет лежать адрес наших долгожданных регистров. Есть одно но: сначала идут Capability регистры, а только после них — Operational, поэтому по смещению 0(от предыдущего адреса, который мы получили по смещению 0x10 относительно начала MMIO нашего EHCI) лежит один байт — длина Capability-регистров.

Асинхронная очередь

Хост контроллер обрабатывает данную очередь только тогда, когда фрейм последовательный пустой, либо хост-контроллер обработал весь последовательный список.

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

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, но и поддержку хабов.

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

Изначально можно представить себе что USB 2.0 порт — это всего лишь 4 пина, по двум из которых просто передаются данные(Как, к примеру, COM-порт), но самом деле всё не так, и даже совсем наоборот. USB-контроллер в принципе не даёт нам возможности передавать данные как через обычный COM-порт. EHCI — довольно замысловатый стандарт, который позволяет обеспечить надежную и быструю передачу данных от софта до самого девайса, и в обратную сторону.

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

qTD(Queue Element Transfer Descriptor)

Данный TD имеет следующую структуру:

Next qTD Pointer — указатель на продолжение очереди для обработки(для Horizontal Execution), бит 0 Next qTD Pointer'а показывает, то, что дальше нет еще одной очереди.
qTD Token — токен TD, показывает параметры передачи данных:

Бит 31 — Data Toggle (об этом дальше)
Биты 30:16 — количество данных для передачи, после завершения транзакции их значение уменьшается на количество переданных данных.
Бит 15 — IOC — Interrupt On Complete — вызвать прерывание после завершения обработки дескриптора.
Биты 14:12 показывают номер текущего буфера, в который/из которого производиться обмен данными, об этом далее.
Биты 11:10 — допустимое количество ошибок. Данная таблица показывает, когда счетчик количества ошибок уменьшается:

Что такое 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:

Справа написано про очереди — о них чуть позже.

Архитектура ЭВМ

Компоненты ПК

Мини блог

«Расширенный» хост-контроллер — EHC

«Расширенный» хост-контроллер EHC (Enhanced Host Controller) был введен фирмой Intel для поддержки высокой скорости в USB 2.0. Его интерфейс — EHCI — описан в документе «Enhanced Host Controller Interface Specification for Universal Serial Bus», версия 1.0 опубликована в марте 2002 года. Контроллер EHC предназначен для работы с устройствами только на высокой скорости подключения к корневому хабу, при этом для устройств FS/LS, которые подключены через промежуточный хаб USB 2.0, контроллер EHC выполняет расщепленные транзакции. С теми портами корневого хаба, к которым непосредственно подключены хабы и устройства USB 1.x, работает контроллер-компаньон (UHC или OHC). Коммутацию портов и контроллеров осуществляет маршрутизирующая логика, входящая в состав корневого хаба USB 2.0. Обнаружением подключения устройств к корневому хабу занимается драйвер EHC через регистры EHC. Обнаружив подключение FS/LS-устройства, драйвер перекоммутирует данный порт на контроллер-компаньон, и с этого момента порт отдается в ведение компаньону и его драйверу. Компаньон и его драйвер могут и не «знать» о том, что они работают в составе контроллера USB 2.0. Для портов, остающихся в ведении EHC, эмулируется внешний хаб — ПО манипулирует портами, используя стандартные запросы к хабам USB.

Контроллер EHC имеет конфигурационные регистры PCI, операционные регистры ввода/вывода, отображенные на пространство памяти (memory mapped I/O) и использует область системной памяти для взаимодействия с драйвером. С точки зрения взаимодействия с драйвером EHC отчасти напоминает UHC, но высокая скорость передачи (480 Мбит/с) потребовала усиления интеллекта контроллера с целью уменьшения числа операций обмена между драйвером, памятью и контроллером. В EHC просматриваются многие идеи, заложенные в OHC. Структуры данных разработаны с учетом минимизации обращений к памяти. Все структуры должны размещаться в памяти так, чтобы они не пересекали границы четырехкилобайтных страниц памяти — это позволяет оптимизировать сосуществование OHC с виртуальной памятью, основанной на страничной переадресации, применяемой в процессорах x86.

В EHCI с точки зрения планирования транзакций передачи делятся на периодические (изохронные и прерывания) и асинхронные (управляющие передачи и массивы). Каждый из этих двух планов реализуется по-своему и может быть включен в работу и выключен. Контроллер начинает каждый микрокадр с выполнения периодических передач (если они разрешены), оставшееся от них время выделяется для выполнения асинхронных передач (аналогично UHC). За то, чтобы в микрокадре оставалось время для асинхронных передач, отвечает драйвер. Хост-контроллер аппаратно следит лишь за тем, чтобы транзакции не пересекали границу микрокадра: если контроллер «видит», что транзакция может не успеть завершиться к моменту EOF1, он ее не начнет. При этом возможна перестраховка, поскольку точное время исполнения транзакции заранее не известно (неизвестно, сколько придется вставить бит и каковы задержки в кабелях, хабах и устройстве).

Для всех передач с гарантированной доставкой (прерывания, управление и массивы) используются структуры данных qTD (Queue Element Transfer Descriptor), описывающие очереди буферов, обеспечивающие автоматическое упорядоченное исполнение потоков передач. В EHC под передачей понимается последовательность однотипных транзакций; ограничен лишь суммарный размер передаваемых блоков (20 Кбайт). Транзакции управления хост планирует как последовательность двух-трех «передач» (в терминах EHC). Драйвер может динамически (во время исполнения плана) добавлять новые передачи в очереди. Контроллер аппаратно поддерживает сигнализацию окончания блоков короткими пакетами: приняв короткий пакет, контроллер может пойти по альтернативной последовательности передач для данной очереди (то есть организуется условный переход). Для изохронных передач используются специальные структуры данных (iTD — Isochronous Transaction Descriptors для HS и siTD — Split-transaction IsochronousTransfer Descriptors для расщепления транзакций с FS-устройствами). Для изохронных передач на HS дескриптор может описывать передачу до 24 Кбайт данных, на FS — до 1023 байт.

Основой планирования периодических транзакций является список кадров (Frame List) на 1024, 512 или 256 вхождений. Базовый адрес и длина списка устанавливается программно, текущий элемент списка выбирается по счетчику кадров. Исполнение плана начинается в каждом микрокадре, таким образом, каждый текущий элемент списка выбирается 8 раз подряд, после чего контроллер переходит к следующему элементу. Элемент списка может указывать на iTD, siTD или заголовок очереди (QH), относящейся к прерываниям. Кроме того, он может указывать на специальные структуры (FSTN), используемые для обеспечения корректности отработки расщепленных транзакций около границы кадра. В элементе списка кроме собственно указателя имеется идентификатор типа структуры (Typ), на которую ссылается указатель (iTD, siTD, QH или FSTN), а также признак заглушкитерминатора (T). Все дескрипторы изохронных передач и заголовки очередей имеют «горизонтальный» указатель на следующую структуру, в котором также задается и тип (Typ) этой структуры, и признак заглушки-терминатора (T). Цепочка дескрипторов и заголовков очередей, начинающаяся от списка кадров, должна завершаться дескриптором (или заголовком), у которого установлен признак заглушки-терминатора (T). Только отработав такой дескриптор (или заголовок), контроллер приступает к исполнению плана асинхронных передач.

Для упрощения планирования расщепленных транзакций (они не должны пересекать границу кадра) контроллер организует фазовый сдвиг между кадрами шины (BFrame), которые видны хабам и устройствам по факту смены номера кадра в маркере SOF, и кадрами хоста (HFrame), которыми оперирует драйвер при построении планов и по которым выбираются периодические транзакции из списка кадров. Кадры шины отстают от кадров хоста на один микрокадр, более подробные пояснения (но не мотивы) приведены в спецификации EHCI. Для обслуживания расщепленных периодических транзакций имеется специальная структура (узел) FSTN, содержащая пару указателей: нормальный, обеспечивающий переход к следующей структуре (iTD, siTD, QH или FSTN), и обратный, который может указывать только на заголовок очереди. Нюансы планирования расщепленных транзакций здесь приводить не будем, с ними можно ознакомиться в спецификации EHCI.

Основой планирования непериодических транзакций является асинхронный список (asynchronous list), представляющий собой кольцо из заголовков очередей. В OHC регистр AsyncListAddr указывает на текущий элемент списка; к отработке этого элемента контроллер приступает, завершив отработку периодических передач в данном микрокадре (или сразу, если периодические передачи запрещены или отсутствуют). Далее, по мере отработки очередей, контроллер заносит в этот регистр адреса последующих указателей. Таким образом, обслуживание всех асинхронных очередей выполняется по кругу, без привязки к конкретным кадрам. Контроллер останавливает обход асинхронного списка, когда обнаруживает опустошение всех его очередей, для возобновления обхода требуется вмешательство драйвера. Нормальной дисциплиной обслуживания очередей является отработка одной шинной транзакции из очереди, после чего контроллер переходит к следующей очереди. Возможен и специальный режим парковки (Asynchronous Schedule Park Mode), в котором контроллеру разрешается выполнять подряд по несколько транзакций из одной очереди. Режим парковки распространяется на все очереди высокоскоростных асинхронных передач.

Дескриптор iTD описывает изохронную передачу, которая может выполняться за1–8 этапов (микрокадров, в которых происходит обращение к данному дескриптору). Каждому этапу в дескрипторе соответствует своя запись (transaction record), управляющая выполнением и отражающая состояние транзакции (активность, ошибки выполнения, необходимость прерывания по выполнению, реальная длина) и содержащая указатель на буфер данных. Каждый этап может выполняться за 1–3 транзакции в микрокадре (точка может быть широкополосной). Дескриптор содержит и описание конечной точки: адрес устройства и точки, направление, размер пакета. Контроллер формирует транзакции исходя из указанного размера пакета. Буферы для данных могут располагаться в разных физических страницах памяти, но логически они должны представлять собой непрерывную область в виртуальной памяти. Для хранения данных (максимум 8 этапов по три транзакции по 1024 байт — 24 576 байт) может потребоваться до 7 страниц по 4 кбайт; для всех этих страниц в дескрипторе имеются соответствующие указатели.

Дескриптор siTD описывает одну расщепленную транзакцию. Адресная часть содержит номер и направление конечной точки, адрес устройства, а также адрес и номер порта хаба, выполняющего трансляцию данной транзакции. В дескрипторе имеются поля битовых масок μFrame_S-mask и μFrame_C-mask, определяющих, в каких микрокадрах данного кадра должны выполняться транзакции SS и CS соответственно. Контроллер в дескрипторе отмечает микрокадры, в которых в действительности происходили транзакции CS. Дескриптор имеет обычный набор полей, управляющих выполнением и отражающих состояние транзакции (активность, ошибки выполнения, необходимость прерывания по выполнению, реальная длина). Кроме того, в siTD имеются специфические поля, управляющие текущей фазой (SS или CS), а также признак специфической ошибки расщепленной транзакции — пропуска микрокадра, в котором должна выполняться очередная транзакция CS. Этот пропуск может случиться, если контроллер не выпустит текущую транзакцию из-за нехватки времени в микрокадре. Блок передаваемых данных (до 1023 байт) может располагаться в одной или двух физических страницах памяти, и в дескрипторе для них имеются необходимые указатели. В siTD имеется специфический элемент — обратный указатель (Back Pointer) на siTD предыдущего кадра, который используется при планировании транзакций IN, завершающихся близко к границе кадра.

Элемент очереди-дескриптор передачи qTD, описывает одну передачу размером до 20 480 байт. Дескриптор привязан к своему заголовку очереди (QH); он содержит пару указателей на следующие элементы данной очереди:

основной, указывающий на дескриптор следующей передачи, которую требуется выполнить после нормального завершения текущей;
альтернативный, указывающий на дескриптор передачи, которую требуется выполнить в случае завершения текущей передачи по приему короткого пакета

Дескриптор имеет обычный набор полей, управляющих выполнением и отражающих состояние транзакции: активность, ошибки выполнения, необходимость прерывания по выполнению, используемый маркер (IN, OUT или SETUP). В дескрипторе указывается общая длина передачи. Буфер данных для передачи должен располагаться в непрерывной области виртуальной памяти; для описания буфера передачи максимальной длины имеется массив из пяти указателей физических страниц.

Заголовок очереди QH создается для каждой сконфигурированной неизохронной конечной точки каждого устройства USB. Заголовки очередей непериодических конечных точек связаны между собой по горизонтали в кольцо, для чего в каждом заголовке имеется соответствующий указатель. Заголовок очереди несет исчерпывающее описание конечной точки: номер и направление точки, максимальный размер пакета, число пакетов в микрокадре (для широкополосных точек), адрес устройства, его скорость. Для FS/LS устройств имеется и информация для выполнения расщепленных транзакций: номер хаба и порта, выполняющего расщепление транзакций, маски микрокадров для транзакций SS и CS. В заголовке очереди имеется оверлейная область, в которую контроллер помещает необходимые ему поля qTD текущей транзакции. Продвижение по очереди осуществляет контроллер, помещая в оверлей следующий qTD после завершения отработки предыдущего.

Контроллер EHC вырабатывает прерывания для разных категорий событий, и категории могут быть селективно замаскированы:

по завершении передачи, в дескрипторе которой имеется соответствующий признак, а также по приему короткого пакета. Эти прерывания могут быть задержаны по времени до определенного задаваемого программно порога, что позволяет снизить частоту запросов прерывания от EHC. Без задержки частота запросов может достигать частоты микрокадров (для IBM PC это слишком часто); с задержкой они не смогут появляться быстрее, чем определяет значение порога;
по событию хост-контроллера: оборот по списку кадров, изменению состояния или перегрузке портов хаба, специальному разрешению программного изменения последовательности заголовков очередей, по ошибке системного подключения (переполнение или переопустошение буфера FIFO из-за занятости шины PCI).

Постановка запросов передач в очереди, как и включение изохронных передач в план, а также добавление/удаление очередей может выполняться драйвером динамически, во время работы хост-контроллера. Однако для сохранения целостности и связанности структур программа должна соблюдать определенные правила взаимодействия, чтобы не пытаться изменять структуры, которые в данный момент отрабатываются контроллером. Для этой синхронизации хост-контроллер использует специальные биты-признаки в своем регистре состояния и в структурах данных. Для «сбора урожая» — поиска отработанных передач — драйверу приходится просматривать во всех дескрипторах передач признаки активности. Такого сервиса, как очередь исполненных передач (как в OHC), контроллер EHC не предоставляет. Но по сравнению с UHC, конечно же, объем работ драйвера EHC сокращается, поскольку этот контроллер оперирует передачами, а не транзакциями. Однако у драйвера EHC появляется дополнительная довольно сложная задача — планирование расщепленных транзакций.

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

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

Хотя протоколы архитектуры 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 — структуры обычной и расщеплённой изохронных транзакций различаются.

Голова очереди

Голова очереди(Queue Head) имеет следующую структуру:

Queue Head Horizontal Link Pointer — указатель на следующую очередь, биты 2:1 имеют следующие значения в зависимости от типа очереди:

Endpoint Capabilities/Characteristics — характеристики очереди:

Биты 26:16 содержат максимальный размер пакета для передачи
Бит 14: Data Toggle Control — показывает, где хост-контроллер должен брать изначальное значение Data Toggle, 0 — игнорирует бит DT в qTD, сохраняет бит DT для головы очереди.
Бит 13:12 — характеристики скорости передачи:
Биты 11:8 — номер конечной точки, к которой выполняется запрос
Биты 6:0 — адрес устройства

Биты 29:23 — номер Хаба
Биты 22:16 — адрес Хаба

Переходим к самому интересному.

Самое читаемое

Арифметико логическое устройство (АЛУ)
Страничный механизм в процессорах 386+. Механизм трансляции страниц
Организация разделов на диске
Диск Picture CD
White Book/Super Video CD
Прямой доступ к памяти, эмуляция ISA DMA (PC/PCI, DDMA)
Карты PCMCIA: интерфейсы PC Card, CardBus
Таблица дескрипторов прерываний
Разъемы процессоров
Интерфейс Slot A

Capability регистры

По смещению 2 лежит регистр HCIVERSION — номер ревизии данного HC, который занимает 2 байта и содержит BCD версию ревизии (что такое BCD можно узнать из википедии).
По смещению +4 лежит регистр HCSPARAMS, его размер — 2 слова, он содержит структурные параметры устройства и его биты показывают следующее:

Бит 16 — Port Indicators — доступные световые индикаторы для подключенных USB-устройств.
Биты 15:12 — номер контроллера-компаньона, который присвоен данному контроллеру
Биты 11:8 — количество портов у компаньон-контроллера
Бит 7 — Port Routing Rules — показывает, как данные порты привязаны к компаньон-портам
Бит 4 — Port Power Control — показывает, надо ли включать питание каждому порту, 0 — питание подаётся автоматически
Биты 3:0 — количество портов у данного контроллера.
По смещению +8 лежит регистр HCCPARAMS — показывает параметры совместимости, его биты значат следующее:
Бит 2 — доступность асинхронной очереди,
Бит 1 — доступность периодической (последовательной) очереди
Бит 0 — 64-битная совместимость

Архитектура ЭВМ

Драйвер EHCI

Начнем с того, какие запросы может выполнять EHCI. Есть 2 типа запросов: Control — а-ля команд, и Bulk — к конечным точкам, для обмена данными, к примеру, абсолютное большинство флешек(USB MassStorage) использует тип передачи данных Bulk/Bulk/Bulk. Мышь и клавиатура для передачи данных тоже используют Bulk — запросы.

Инициализируем EHCI и настраиваем асинхронную и последовательные очереди:

Собственно, код для сброса порта в изначальное состояние:

Control-запрос к устройству:

Код обработки очереди:

И теперь запрос к конечной точке(Bulk-запрос)

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

Не так давно, была опубликована статья «Пастильда — открытый аппаратный менеджер паролей». Так как данный проект является открытым, то мы решили, что будет интересно, если мы будем писать небольшие заметки о процессе проектирования, о задачах, которые перед нами стоят и о трудностях, с которыми мы сталкиваемся.

Реализация USB хоста

Итак, во-первых мне нужно было реализовать на устройстве USB хост, чтобы оно могло распознавать и общаться с подключенной к нему клавиатурой. Так как в работе я использую связку Eclipse + GNU ARM Eclipse + libopencm3, то очень хотелось найти уже что-то готовое и желательно написанное с использованием библиотеки libopencm3. Желание мое было очень жирным, до последнего момента не верила, что мои поиски увенчаются успехом. Однако под конец рабочего дня, проскролив интернет до самого дна, я вдруг наткнулась вот на это. libusbhost? Серьезно? И это был не просто написанный на основе libopencm3 usb хост, он еще и был написан под STM32F4, под тот самый, который мы решили использовать в проекте. В общем, звезды сошлись и радости моей не было предела. Кстати, оказалось, что этот проект создавался как часть libopencm3, однако его так и не добавили в библиотеку.

Как библиотеку, libusbhost я не собирала, просто взяла необходимые мне исходники, написала драйвер для клавиатуры и, в общем-то все, погнали! Но обо всем по-порядку.

usbh_device_driver.h
usbh_config.h
usbh_hubbed.[ch]
usbh_lld_stm32f4.[ch]

По аналогии с usbh_driver_hid_mouse.[ch], я написала драйвер для клавиатуры (usbh_driver_hid_kbd.[ch]).

Далее был реализован простенький класс, для работы с хостом:

Реализация составного USB устройства

Далее мне нужно было сделать так, чтобы наше устройство отображалось в диспетчере устройств и как клавиатура, и как дисковый накопитель. Тут вся магия в дескрипторах=) В этом документе, в главе 9, подробно описан USB Device Framework. Эту главу нужно очень внимательно прочитать и в соответствии с ней описать дескрипторы устройства. В моем случае получилось следующее:

usb_config_descriptor: поле bNumInterfaces должно отражать столько интерфейсов, сколько реально реализовано. В нашем случае два: HID и MSD
usb_interface_descriptor: поле bInterfaceNumber обозначает номер интерфейса, но отсчет начинается с нуля, следовательно, номер первого интерфейса — 0.

Для работы с составным устройством был написан класс USB_composite, представленный ниже.

Функция hid_control_request нужна для общения Пастильды как клавиатуры с хостом (в данном случае, хост — это ПК). Вне класса данная функция вызывается через USB_control_callback.
Функция hid_set_config нужна для того, чтобы настроить конечные точки (endpoints) и зарегистрировать USB_control_callback, описанный в предыдущем пункте. Вне класса данная функция вызывается через USB_set_config_callback.

Как правило, функции control_request и set_config должны быть явно описаны для каждого устройства. Однако из этого правила есть исключение: Mass Storage Device. Итак, разберемся с конструктором класса USB_Composite.

Во-первых, мы инициализируем ноги USB OTG FS:

Во-вторых, нам нужно проинициализировать наше составное устройство, зарегистрировать USB_set_config_callback, о котором шла речь выше, и разрешить прерывание:

Во вкладке «Контроллеры USB»: как составное устройство,
В этой же вкладке, как «Запоминающее устройство для USB»,
Во вкладке «Клавиатуры», как «Клавиатура HID».

block_count: количество секторов памяти,
read_block: функция для чтения сектора,
write_block: функция для записи сектора.

Так вот. Теперь, когда конструктор класса USB_Composite дописан, можно собрать проект, прошить устройство и увидеть, что «Запоминающее устройство для USB» больше не помечено предупреждением, а во вкладке «Дисковые устройства» можно обнаружить «ThirdPin Pastilda USB Device». И, казалось бы, все хорошо. Но нет=) Проблем стало больше:

1. Зайти на диск невозможно. При попытке сделать это все виснет, умирает, компьютеру очень плохо.
2. Распознавание устройства как дискового занимает более 2-х минут.

Об этих проблемах и о том, как их решить без вреда для здоровья написано здесь: USB mass storage device и libopencm3.

И, о, чудо! Никаких пятен=) Теперь все работает. У нас есть USB хост и составное USB устройство. Осталось только объединить их работу.

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

Для уровня поддержки хост-контроллеров важны следующие структуры: структура данных контроллера *_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.

Интерфейсы

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

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

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

Структуры передачи данных и запросов

Организация структуры для обработки запросов включает в себя очередь и трансфер дескрипторы(TDs).

На данный момент мы рассмотрим только 3 структуры.

Последовательный список

Последовательный(Периодичный, Pereodic) список устроен следующим образом:

Как видно на схеме, обработка начинается с получения нужного фрейма из фрейм листа, каждый его элемент занимает 4 байта и имеет следующую структуру:

Как видно на картинке, адрес очереди/трансфер дескриптора выровнен по границе 32 байта, бит 0 означает то, что хост-контроллер не будет обрабатывать данный элемент, биты 3:1 показывают тип того, что будет обрабатывать хост-контроллер: 0 — изосинхронный TD(iTD), 1 — очередь, 2 и 3 в данной статье я рассматривать не буду.

Operation регистры

По смещению 0 лежит регистр USBCMD — командный регистр контроллера, его биты означают следующее:

Биты 23:16 — Interrupt Threshold Control — показывает сколько микро-фреймов будет использоваться на один обычный фрейм. Чем больше, тем быстрее, но если больше 8 — то микро-фреймы будут обрабатываться с той же скоростью, что и для 8.
Бит 6 — прерывание после каждой транзакции в асинхронной очереди,
Бит 5 — используется ли асинхронная очередь,
Бит 4 — использование последовательной очереди,
Биты 3:2 — размер FrameList'a (о этом — дальше). 0 означает 1024 элемента, 1 — 512, 2 — 256, 3 — зарезервировано
Бит 1 — устанавливается для выполнение сброса хост-контроллера.
Бит 0 — Run/Stop

Бит 15 показывает используется ли асинхронная очередь
Бит 14 показывает используется ли последовательная очередь,
Бит 13 — показывает, что обнаружена пустая асинхронная очередь,
Бит 12 установлен в 1, если при обработке транзакции произошла ошибка, тогда хост-контроллер остановит выполнение всех очередей.
Бит 4 установлен в 1, если произошла серьезная ошибка, хост-контроллер останавливает выполнение всех очередей.
Бит 3 FrameList (Регистр) Rollover — ставится в 1, когда хост-контроллер обработал весь frameList.
Бит 1 — USB Error Interrupt — генерировать ли прерывание при ошибках?
Бит 0 — USB Interrupt — выставляется после успешной обработки транзакции, если в TD был установлен IOC

По смещению +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, его биты значат следующее:

Бит 12 — питание порта, 1 — питание подаётся, 0 — нет.
Бит 8 — Port Rest — устанавливается для сброса устройства.
Бит 3 — Port Enable/Disable Change — выставляется при изменении статуса «включенности» порта.
Бит 2 — порт включен/не включен.
Бит 1 — Изменение статуса подключения, ставится в 1, к примеру, если вы подключили, или отключили USB устройство.
Бит 0 — статус подключения, 1 — подключено, 0 — нет.

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